View Issue Details

IDProjectCategoryView StatusLast Update
0003763Far ManagerCopy/Movepublic2020-01-18 19:19
Reporteralexfbg Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status newResolutionopen 
Platformx64OSWindows 
Product Version3.0 
Summary0003763: При операции Move опция Preserve timestamps НЕ работает для каталогов (работает только для файлов внутри каталогов)
DescriptionПри операции Move опция Preserve timestamps НЕ работает для каталогов (работает только для файлов внутри каталогов)
Steps To ReproduceШаги воспроизведения:
1) Подобрать несколько каталогов с подкаталогами и файлами в них для переноса
2) При переносе (F6-Move) включить опцию [x] Preserve timestamps

Ожидаемое поведение:
Все timestamps у всех каталогов и файлов будут сохранены (будут теми же, которые были до переноса)

Реальное поведение:
Для файлов timestamps сохраняются, а все каталоги и подкаталоги будут иметь все timestamps = времени переноса (создания этих каталогов на новом диске)
Tagstimestamps
Build

Activities

alexfbg

2020-01-16 23:38

reporter   bugnote:0016702

На всякий случай, речь идет о переносе каталогов между разными физическими (или просто логическими) дисками - не один диск.

DrKnS

2020-01-16 23:55

administrator   bugnote:0016703

Не повторяется.

alexfbg

2020-01-17 03:55

reporter   bugnote:0016704

Far Manager, version 3.0.0.5511 x64

Переношоу каталоги с диска Y: на диск A:
Оба диска сетевых (net use), хотя уверен, что разницы никако нет.

alexfbg

2020-01-17 03:58

reporter   bugnote:0016705

Проверил на локальных дисках - на локальных реально не воспроизводится (два разных диска, но оба физические). Возможно, как-то криво делается установка timestamp при создании каталогов? Т.к. код не смотрел - сложно комментировать. Соответственно, на обычных дисках это все пролетает на ура, а на сетевых обламывается.

alexfbg

2020-01-17 04:02

reporter   bugnote:0016706

Попробовал на одном сетевом диске создать каталог, а потом средствами FAR поменять у него timestamp. Получил забавную ошибку:

   ╔═══════════════════════════ Error ═══════════════════════════╗
   ║ Cannot set owner for ║
   ║ test ║
   ╟─────────────────────────────────────────────────────────────╢
   ║ No mapping between account names and security IDs was done. ║
   ╟─────────────────────────────────────────────────────────────╢
   ║ { Retry } [ Skip ] [ Skip all ] [ Cancel ] ║
   ╚═════════════════════════════════════════════════════════════╝

Однако, даже после нее (нажал retry, потом skip) - timestamp'ы изменились (поменял год на 2001, 2002, 2003).

На втором диске то же самое: ошибка, retry, skip - timestamp'ы изменены.

Оба диска - NAS, не NTFS, оба btrfs в разной реализации на разных аппаратных платформах.

Похоже, что в методике переноса или копирования файлов простановка timestamps делается как-то иначе и она отпадает или по ошибке, или просто не происходит. Вручную все меняется прекрасно, как показал эксперимент.

alexfbg

2020-01-17 04:07

reporter   bugnote:0016707

Проверил копирование и перенос (обе операции):
Физический локальный диск, NTFS -> NAS2, btrfs
Физический локальный диск, NTFS -> NAS1, btrfs
Даты каталогов и файлов сохранились.

Проверил перенос:
NAS2, btrfs -> физический локальный диск, NTFS
NAS1, btrfs -> физический локальный диск, NTFS
Даты каталогов и файлов сохранились.

Между NAS1 и NAS2 сейчас тоже работает.

Короче - чудеса.

В каких-то случаях проявляется (100%, т.к. переношу между дисками несколько дней данные, и вижу это). Но четких шагов воспроизведения сказать на данный момент не могу :\

alexfbg

2020-01-17 04:10

reporter   bugnote:0016708

Возможно, я действительно, неправ и это особенность этих ФС, как они проставляют Last Write Time / Last Access Time у каталогов в случае доступа к ним и/или создания файлов в них.

alexfbg

2020-01-17 14:16

reporter   bugnote:0016709

Похоже, я понял в чем моя ошибочная интерпретация. Timestamp'ы проставляются на каталоги по списку (дереву) после полного завершения операции? И тогда нет смысла смотреть даты на каталогах, если операция перемещения длительная (20-100 часов). Т.е. оценить корректность можно только в случае ее полного завершения (по моей текущей гипотизе: после ее завершения проходится по всему дереву и проставляются даты каталогов). Это у меня пока единственное объяснение тому, что происходило (происходит). (Соответственно, я на длительных операциях проверял даты каталогов в процессе пока операции еще не были завершены - и видел даты создания текущие; а на мелких тестах из пустых каталогов все происходило мнговенно, и я видел уже конечный результат)

DrKnS

2020-01-17 15:03

administrator   bugnote:0016710

Да, после завершения.

alexfbg

2020-01-17 22:40

reporter   bugnote:0016711

Насколько разумно/корректно так делать? Ведь можно потерять данные [о датах].
Например, перезагрузка системы. Или слет/убийство процесса. Или (гипотетически) нехватка памяти для ведения списка. И еще варианты.

При переносе в пределах одного логического диска я могу понять с чем это может быть связано, но в случае с разными - это возможность потерять информацию об этом. Данные не потеряются (часть останется неперенесенная, часть перенесенная), а вот даты всех каталогов окажутся новыми.

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

alexfbg

2020-01-17 22:41

reporter   bugnote:0016712

Вообще, мне кажется фундаментально/теоретически несовсем корректно разделять на две несвязанные операции (и разнесенные сильно по времени) "создание каталога" и простановка ему даты/времени/атрибутов.

DrKnS

2020-01-17 22:55

administrator   bugnote:0016713

Last edited: 2020-01-17 22:55

View 2 revisions

> несовсем корректно разделять на две несвязанные операции (и разнесенные сильно по времени) "создание каталога" и простановка ему даты/времени/атрибутов

Когда вы что-то пишете в каталог, его времена записи/доступа меняются (что логично).
Поэтому "создать, проставить и потом в него переносить" не получится - ставить времена надо после полного завершения работы с каталогом.
Возможно, определение момента перехода к следующему подкаталогу или файлу не совсем тривиально (особенно учитывая общую упоротость реализации копирования в Far), поэтому сделано в самом конце. Или так просто так было проще / быстрее.

alexfbg

2020-01-18 15:46

reporter   bugnote:0016714

Как минимум Creation Time можно поставить в момент создания.
Last write time, Last Access Time - с этим да
Change time (?)

DrKnS

2020-01-18 19:19

administrator   bugnote:0016715

Creation можно поставить сразу, да, но это лишнее обращение к ФС, что по сети может быть достаточно дорого.

Issue History

Date Modified Username Field Change
2020-01-16 01:58 alexfbg New Issue
2020-01-16 01:58 alexfbg Tag Attached: timestamps
2020-01-16 23:38 alexfbg Note Added: 0016702
2020-01-16 23:55 DrKnS Note Added: 0016703
2020-01-17 03:55 alexfbg Note Added: 0016704
2020-01-17 03:58 alexfbg Note Added: 0016705
2020-01-17 04:02 alexfbg Note Added: 0016706
2020-01-17 04:07 alexfbg Note Added: 0016707
2020-01-17 04:10 alexfbg Note Added: 0016708
2020-01-17 14:16 alexfbg Note Added: 0016709
2020-01-17 15:03 DrKnS Note Added: 0016710
2020-01-17 22:40 alexfbg Note Added: 0016711
2020-01-17 22:41 alexfbg Note Added: 0016712
2020-01-17 22:55 DrKnS Note Added: 0016713
2020-01-17 22:55 DrKnS Note Edited: 0016713 View Revisions
2020-01-18 15:46 alexfbg Note Added: 0016714
2020-01-18 19:19 DrKnS Note Added: 0016715