не понял
не понял
для сравнения запустите команду SAVE 64 TEST.BIN и гляньте на каталог
тороможу,
вроде как раз save странно себя ведёт, или я что-то забыл ?
SAVE 64 64
xkorvet copyКод:2800: 00 36 34 20 20 20 20 20 20 20 20 20 00 00 00 80 .64 ....
2810: 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 ........ ........
2820: 00 36 34 20 20 20 20 20 20 20 20 20 01 00 00 00 .64 ....
2830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
записал то-же файл на пустой образ с помощь http://www.moria.de/~michael/cpmtools/Код:2800: 00 36 34 20 20 20 20 20 20 20 20 20 00 00 00 80 .64 ....
2810: 02 00 03 00 04 00 05 00 06 00 07 00 08 00 09 00 ........ ........
2820: E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 ........ ........
2830: E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 E5 ........ ........
результат как у xkorvet
вторая трока в директории вроде как не осмысленна ?
может резерв на рост ?
зато при чтении файла с диска cpmtools создал файл длинной 16512
SAVE - это всего лишь самый простой способ создать файл.
Можете попробовать скопировать файл, который был добавлен с помощью xkorvet, утилитой power, она тоже добавит запись в каталог.
на мой взгляд - это выглядит как бага в цпмЦитата:
Сообщение от marinovsoft
или скорее резерв под новые записи.
я не выжу смысла во второй строке для 16к
там-же как-бы есть запись в директории котороя не указвает на полезную информацию.
т.к. вот cpmtools вообще неправильно копирует с такого диска ;)
может он не проверяет число блоков в записи на равенство нулю?Цитата:
вот cpmtools вообще неправильно копирует с такого диска
возможно багЦитата:
Сообщение от marinovsoft
но для меня аргумент - что с образом записаным xkorvet нормально работает cp/m
я не понмаю смысла такой записи (вход в директорию без ссылки на блоки)
Ты же вроде копал BDOS, судя по твоим базам?Цитата:
Сообщение от esl
Смотри процедуру по адресу D55A. get_next_extent. И ссылки на нее.
Когда BDOS записывает последовательный файл, производится постинкремент номера записи (Record в терминах CP/M - логический блок размером 128 байт). Если в результате инкремента текущий экстент каталога оказывается заполненым полностью, то он закрывается и формируется новый экстент. Ну а если в файл больше не писать, то при закрытии файла этот новый экстент оказывается пустым, но зарезервированным за этим файлом - поэтому он все равно запишется вместе с буфером каталога на диск.
Почему используется постинкремент - тоже вроде понятно. Первая запись имеет номер 0 и ее вначале надо записать, а потом уже увеличивать номер. Так что это не баг, а скорее особенность работы с последовательными файлами BDOS. Эмулировать ее в программах работы с дисками, я думаю, смысла никакого нет.
не, я дос не копал, и лаже исходники не смотрел, как-то не очень интересно ;)Цитата:
Сообщение от forth32
он же стандартен и менять его смысла нет
Цитата:
Сообщение от forth32
вопрос закрыт!
спасибо за как всегда экспертный ответ ;)
*Корректная работа с файлами с одинаковыми именами, но у разных пользователей.
*Корректная работа с каталогом, в котором номера записей однобайтные (для дисков с количеством блоков < 0x100).