Тут такое дело, товарищ юнга поднял знамя, выпавшее из моих ослабевших рук (к сожалению, не метафора) и выкатил сборки, включающие все накопленные изменения для hdfmonkey. Там далеко не всё, как я бы хотел сделать, но на безрыбье…

В своё время, написал десяток тестов, но, естественно, это капля в море. Если у кого есть время и желание – потестируйте и отпишитесь. Как я понимаю, на SC AlanBell67 выложил какую-то новую UIщину, которую можно использовать вместо HDFMGooey (ссылку не привожу, они огородились, кто туда ходит и так уже видел), что и спровоцировало этот виток активности. Я таким не пользуюсь, поэтому сам потестировать толком не могу.

https://codeberg.org/chwe/hdfmonkey/releases

Changelog, так сказать. И репозиторий: https://codeberg.org/chwe/hdfmonkey

Что изменилось из-за FatFs:

  • не всегда можно включить FAT32 при создании новых образов. Если образ слишком маленький, FatFs не даст использовать FAT32 или FAT16. Это сделано для стандартизации с другими реализациями FAT внутри FatFs. Кому неудобно, читайте документацию для FatFs и разговаривайте с Elm Chan’ом, я тут сделать ничего не могу, да и не вижу смысла.


Что добавлено и исправлено:

  • FatFs обновлён до R0.16 patch 2
  • команда put может читать файлы со stdin, укажите - как имя файла
  • команда mkdir принимает параметр -p, после чего создаёт полную цепочку директорий, если они ещё не существуют
  • команда get понимает маски файлов, не забывайте экранировать их от вашего shell
  • команда rebuild позволяет изменить размер образа, на который копируется («дорогой» resize)
  • команда rm может удалять более одного файла за вызов
  • новая команда free для просмотра свободного места на образе
  • образы более 4Gb должны обрабатываться корректно (в оригинале было переполнение int, теперь там нормальный off_t)
  • для платформы win32 обрабатываются маски файлов, поведение стало 100% идентичным и для win32 и для POSIX (copy *.* path/to/files/)
  • исправление от jjjs для работы с полностью поломанными FAT32 дисками, где, ну всё совсем, не так как надо. IMHO – выкинуть и пересоздать, см. rebuild выше


Принципиальный момент, который я не делал и делать не собираюсь, пока кто-то в деталях не расскажет, чем и как это в реальной жизни помогает. Обращаю внимание, в реальной жизни в 2026 году. Кому делать нечего, тот и на ассемблере всё может переписать, если есть желание, для «ускорения», но это не наш путь:

  • SPARSE файлы для MS Windows.


Так как команда rebuild теперь умеет менять размер образа, на который копируются данные, я не вижу смысла делать образы с большим запасом свободного места. Я лично использую образы наименьшего возможного размера.

На данный момент это сделано в отдельной сборке, которая hdfmonkey-s.exe. Но, я лично считаю принудительное включение sparse для win32 баловством, которое стоит выкинуть для упрощения сопровождения. Файлы должны создаваться наиболее естественным образом для каждой платформы. Для POSIX систем sparse это то, что происходит само собой, а для win32 это нечто неожиданное и странное. Я считаю, что в контексте ZX Spectrum, где вся TOSEC коллекция занимает 8G (и это со всякими opus и прочими mgtшками), а в год нового выпускают какие-то жалкие сотни килобайт возня со sparse файлами того не стоит. Раз в пять лет запускайте новую команду rebuild Если вы считаете иначе – протестируйте hdfmonkey-s.exe и обязательно напишите, где и как вам sparse файл помогает. И обязательно расскажите, а как вы избегаете превращения sparse файла в обычный.