Вид для печати
еще из пожеланий по улучшениюЦитата:
Сообщение от Eugene85
сейчас если пытаешься закинуть жменю файлов больше чем свободно места
те пишет что недостаточно места и все
а часто нужно закинуть жменю файлов сколько влезет до упора
можно было бы предлагать продолжить кидать пока не останется места
Да, а то если места не хватило, то отменяется копирование всех файлов. А лучше бы скопировать сколько влезло.Цитата:
Сообщение от NEO SPECTRUMAN
Вышла версия 6.45 beta плагинов inSCL/inTRD. Основные новшества такие:
- Опция "Defragment on delete".
- Частичная поддержка DirSys: при удалении и дефрагментации таблица поддерживается в актуальном состоянии.
- Плагины теперь самодостаточны: чтобы работало пакование образов в образы, класть плагины вместе больше не обязательно.
- Поддержка 2-хсимвольных расширений.
- И на закуску пасхалочка: если зайти в образ TRD, нажать F7, ввести "move" и нажать Enter, то
создастся директорияобраз дефрагментируется :)
Вложение 75113
Эврика! Исходники завезли :v2_dizzy_roll:
Правда, пока только двух плагинов. Ну, и на том спасибо :)
https://gitlab.com/spct/inTRD
Скажите а есть какой-то плагин который бы мог отсортировать TRD файлы (с размером 640кб) таким образом что чем больше 00-ей в файле (ну т.е пустого пространства) то отсортировать их от наименьшего заполнения к большему?
Либо может какой другой просто способ есть? Первое что приходит в голову это поиск по HEX значениям где я бы просто ввёл более 300-400 тысяч 00-ей но как мы знаем в поле "С текстом" можно ввести не более 256 байт.
Если бы передо мной встала такая задача, то я бы написал скрипт на Python, который перебирал бы все TRD-файлы, проверял в конце нули (либо опционально по последнему файлу в каталоге) и переименовывал бы их, добавляя к началу имени число этих нулей. Ну а уже после этого можно сортировать любыми подручными средствами.Цитата:
Сообщение от JeRrS
по количеству нулей результат не слишком однозначный получится. потому что свободное пространство может быть заполнено не нулями (например если файлы поудаляли), как и нули могут быть валидными данными (хотя маловероятно что в больших количествах).Цитата:
Сообщение от JeRrS
наверно лучше будет посмотреть на количество свободных блоков в системном секторе или прошерстить директорию и посчитать свободное пространство.
Serg6845, а в TRD файле эти так называемые свободные секторы как-то отмечаются? если да то какой это по счету байт в этом файле?
p.s: кажется понял, 2277-2278
сами по себе секторы - нет. в TRDOS нет никаких таблиц распределения секторов по файлам - просто запись в каталоге с указанием начального сектора и длины.Цитата:
Сообщение от JeRrS
да, они. но я уже не помню - меняется ли это значение при удалении файлов или только после команды MOVE. формат TRDOS вообще до предела примитивный... а TRD файл - просто посекторная копия диска.Цитата:
если да то какой это по счету байт в этом файле?
p.s: кажется понял, 2277-2278
нули могут быть частью данных. Часто диски, особенно с простыми защитами из 90-ых годов были записаны игнорируя стандартные поля типа N_FRE_SEC (кол-во свободных секторов, системный сектор.смещение=0xe5) и FR_S_NEXT/FR_T_NEXT. Поэтому если ориентироваться на них, можно испортить образ диска.
Если мешают нули в конце TRD, оптимальнее всего запаковать стандартным ZIP (только не 7z, т.к. его формат не понимает даже официальный unzip последней версии), он обычно поддерживатся большинством эмуляторов, так что не нужно даже распаковывать, чтобы открыть образ диска. А размер области с нулями хорошо сжимается, так что размер образа будет не хуже обрезанных образов.
Также нужно учитывать, что размер TRD задает формат диска. Поэтому обрезая его, можно сделать образ нечитаемым.