Orion9
|
 Posted: Wed Sep 03, 2025 14:04 Post subject: |
 |
|
Продолжение к вышестоящему посту.
Сейчас вижу, что есть некоторые недоработки, но в целом код рабочий. Это нормально, изначально не ставил задачи сделать всё идельно, хотелось просто посмотреть, что из этого выйдет.
Вообще, хотелось бы иметь инструмент, помогающий при работе с такими программами, как BadNTFS, и чтобы этот инструмент сразу был интегрирован в ТС и чтобы не возникало необходимости прибегать к сторонним утилитам типа DiskView, WinContig или того же Defraggler. Сейчас подсказка выводит информацию в таком виде:
| Code: | File: autorun_20250805.zip
Volume: e:\
Sector: 512 bytes
Cluster: 8 sectors
Free: 1288683 Total: 15728698
Fragments: 4 Clusters: 87 Size: 347,64 Kb
-------------------------------------------------
N VCN LCN Clusters Size
-------------------------------------------------
1 0 15 327 813 9 36 Kb
2 9 14 170 518 15 60 Kb
3 24 14 102 396 32 128 Kb
4 56 12 671 977 31 124 Kb
5 87 0 |
Напоминает вывод консольной утилиты от Руссеновича Contig, но у Руссеновича не выводятся сведения о логическом номере кластера - LCN, хотя именно они в первую очередь и нужны при работе с плохими секторами на диске.
Немного об ограничениях. Про буфер уже говорилось. FRAG_BUFFER = 32 может получить информацию только о 2047 записях, т.к. размер буфера ограничен 32Кб. Когда буфера не хватает, функция возвращает код ERROR_MORE_DATA, соответственно в кастомном поле возможно пометить такие фрагменты знаком ">", указывающим, что фрагментов на самом деле больше, т.е. например ">2047". В подсказке это помечается в поле кластеров:
| Code: | Fragments: 2047 Clusters: >239430 Size: 7,93 Gb |
Чтобы получить правильные сведения о всех фрагментах, необходимо делать повторные вызовы, смещая стартовую точку, но я не стал этим загоняться. Как правило, сильно фрагментированных файлов не так много, и информацию он них можно получить в любой программе-дефрагментаторе, в том же Defraggler.
Еще один момент. Информация о VCN и LCN сохраняется в 64-битный юнион LARGE_INTEGER, который, по идее, надо было собрать назад функцией MakeInt, имеющейся в Autorun, но я не стал этим заморачиваться, считывая пока только старшую часть юниона. Это, как я понял, ограничивает LCN до 4Тб и на очень больших разделах может привести к неправильному отображению чисел.
Иногда в поле попадают такие записи, как "1/3" или "10/42" и т.д. Первое число - количество фрагментов на разделе. Второе - в файловой записи. Вероятно, это следствие работы программ-дефрагментаторов, которые после дефрагментации файла по какой-то причине не вносят изменения в запись, например:
| Code: | Fragments: 1/3 Clusters: 9066 Size: 35,41 Mb
-------------------------------------------------
N VCN LCN Clusters Size
-------------------------------------------------
1 0 19 686 209 3792 14,81 Mb
2 3792 19 690 001 4832 18,87 Mb
3 8624 19 694 833 442 1,72 Mb
4 9066 0 |
Файл занимает одну сплошную область от 19 686 209 до 19 695 275, но, видимо, раньше он состоял из 3-х фрагментов, сведения о которых так и остались в его записи.
Ну вот пока и все. Для использования в наборе можно использовать поле "Frag", например [=tc.size.bkMGT2]\n[=autorun.Frag]. Для поиска или подсветки файлов можно создать шаблоны поиска, например: autorun.FragNum > 1000 или autorun.FragEntry = 1 |
|
Rules
Search
FAQ
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
