wipe больших объемов

[johndoe71rus]

far2l_2.6.3.git20241005-x86_64.run
запущен от root в live lubuntu 22.04

удаление wipe больших объемов на диске ntfs. часто возникают ошибки

можно пропустить, затем возникает ошибка "нельзя удалить папка не пуста"
при пропусках папки переименовываются с добавлением 4 случайных символов в конце

их можно повторно выделить и снова задать wipe может пройти успешно, может на некоторых снова выдать ошибки в той же последовательности, сначала нет такого файла, затем папка не пуста.
При этом в выводе удаляемых файлов видно что было несколько попыток вайпа и папки переименовывались в процессе

Похоже что иногда возникает гонка, папку переименовали до того как вычистили ее содержимое.

[spnethw]

1. Нет ли среди уничтожаемых файлов символических ссылок? У меня воспроизводится что-то подобное только в этом случае. При вайпе перезатираются данные и меняется имя оригинального файла. Если он был уничтожен раньше, чем ссылка, то ссылки становятся невалидными, отсюда такое сообщение.
2. ntfs3 или ntfs-3g? Несмотря на то, что ntfs3 уже давно включен в ядро, он всё ещё проблемный и часто ведёт к повреждению данных (гуглябельно).

[johndoe71rus]

Символические ссылки с большой вероятностью нет. Это Мои документы с вин7. пользователь точно не делал ссылок. Копилось все десяток лет, набралось больше 50Гб с неизвестной глубиной вложенности. вот эта папка судя по названию вайпится в 3 раз

а может быть даже 4 или 5-я итерация судя по вложенным.
Сначала я предположил что это ошибки на диске, но тогда они повторяются при повторном вайпе и не удаляются. А здесь все удалилось за несколько итераций.
Когда возникает ошибка, Retry не работает, спкипаешь все. потом так же вылезает ошибка что папка не пуста, ее так же скипаешь все. но можно посмотреть что часть удалилась, размер папки уменьшился.

ntfs3 или ntfs-3g? не знаю. обычный live режим установочного образа lubuntu 22.04.5. могу уточнить.

[spnethw]

Что нарылось:
Метод bool FindFile::Get(FAR_FIND_DATA_EX &FindData), а точнее BOOL WINPORT(FindNextFile)(HANDLE hFindFile, LPWIN32_FIND_DATAW lpFindFileData), к которому он обращается, иногда возвращает то, что уже было удалено в процессе, и более не существует.

Любопытная деталь:
У меня баг проявляется только при использовании драйвера ntfs3 от Paragon, ныне включенного в ядро. При монтировании через ntfs-3g / fuse — всё работает. 👀

Ещё одна любопытная деталь:
На NTFS, созданных под Linux, у меня воспроизвести баг не получилось.
Не исключено, что проблема как-то связана с короткими 8.3 именами, которые Windows создаёт на NTFS в дополнение к длинным именам. Они не отображаются, но работают как хардлинки и учитываются тем же ls или stat.
Это зависит от версии Windows и того, была ли отключена/включена эта функциональность вручную.
Например, гугл говорит:

Since Windows 8 and Windows Server 2012 newly formatted volumes will have 8.3 name generation disabled by default.

(Причём если создать файл с длинным именем из-под Linux, парное 8.3 ему не будет создано, для таких файлов число хардлинков будет 1.)

@elfmz

[spnethw]

fakedisk.raw.zip
Образ ntfs, созданной под Win7.

Монтируем как-то так:
sudo mount -t ntfs3 -o loop -o uid=1000,gid=1000 ./fakedisk.raw /mnt/FakeDisk
или так:
sudo mount -t ntfs-3g -o loop -o uid=1000,gid=1000 ./fakedisk.raw /mnt/FakeDisk

И пробуем завайпить по Alt-Del папку "long-3" или папку "short-7".

@elfmz

[elfmz]

запустите фар2л с дебаглогами - в терминале:

export FAR2L_STD=debug.log
far2l

...далее воспроизведите баг, закройте far2l и скиньте или сами посмотрите получившийся debug.log
Я ожидаю там увидеть эти сообщения: https://github.com/elfmz/far2l/blob/master/far2l/src/delete.cpp#L793
.. вероятно от драйвера фс приходит ошибка переименования, но файл все же переименуется, в результате потом оно пытается удалить оригинальную копию которой уже нет. Интересует код ошибки из этих распечаток.

[spnethw]

Имеем (ntfs3):

[/mnt/FakeDisk/long-3]
 ├─Long Folder Name 1
 ├─Long Folder Name 2
 └─Long Folder Name 3

Пытаемся завайпить папку long-3.
Лог:

WipingRename: renamed '/mnt/FakeDisk/long-3/Long Folder Name 1' to '/mnt/FakeDisk/long-3/iR36'
WipingRename: renamed '/mnt/FakeDisk/long-3/Long Folder Name 2' to '/mnt/FakeDisk/long-3/WxJl'
WipingRename: renamed '/mnt/FakeDisk/long-3/Long Folder Name 3' to '/mnt/FakeDisk/long-3/fY7w'
opendir failed on /mnt/FakeDisk/long-3/Long Folder Name 3
apiGetFindDataEx: FAILED - /mnt/FakeDisk/long-3/Long Folder Name 3
WipingRename: error 2 renaming '/mnt/FakeDisk/long-3/Long Folder Name 3' to '/mnt/FakeDisk/long-3/G3kn'

Он прошёлся по всем вложенным папкам, успешно их завайпил. Но потом пошел ещё на одну итерацию.
Я там много отладочной печати дополнительно порастыкивал, почему-то в каких-то случаях FindNextFile продолжает возвращать результаты.

P.S. что любопытно -- если произвести какие-то действия, допустим перед вайпом переименовать папку "Long Folder Name 3" в "Long Folder Name X" и обратно (!) -- родительская папка long-3 вайпится успешно.

[elfmz]

вероятно надо вначале файловые пути пособирать а потом только их поудалять

[spnethw]

На ntfs-3g / fuse это не воспроизводится.
Не исключаю, что это какие-то косяки со стороны ntfs3. Я уже ловил с ним повреждения файловой системы Windows 7.