Page 1 of 2

Не все копируется в nul

Posted: Fri 08 Apr, 2016 09:18
by ELEA
Не знаю, БАГ это или нет, но замечено, что некоторые файлы просто не копируются в nul.
Иногда замеряю скорость чтения с дисков копируя файлы в nul.
Заметил, что некоторые файлы выдают ошибку "неверная функция".
Просто так они копируются, открываются, а в nul - никак. Видимо из-за особого содержания, но как связано не понятно.

Не все копируется в nul

Posted: Fri 08 Apr, 2016 10:11
by 2useven10
ELEA wrote: Не знаю, БАГ это или нет,
С таким репортом и не узнаете.
Прочтите и попробуйте ещё раз.

Не все копируется в nul

Posted: Fri 08 Apr, 2016 10:56
by ELEA
В общем я нашел причину. После любого переноса через FAT32 флешку - файл вылечивался. Подозрения пали на расширенные свойства/возможности NTFS.
Есть программа NTFS Stream explorer.
В ней можно смотреть различные параметры фалов, которые недоступны обычными средствами.
Там есть закладка "Стандартная информация", в ней есть - прочие атрибуты.
Среди данных атрибутов есть: "Не проверять скрамблером". Даже не подозревал о существовании такого атрибута.
Не знаю, что это за атрибут такой, но если его снять, то все работает как надо.
Если же на любой другой файл поставить этот атрибут - то его уже не скопируешь в nul, т.к. выдается ошибка про неверную функцию.
Если кто знает, что это за такой атрибут - поделитесь, хотелось бы знать. Спасибо.

Не все копируется в nul

Posted: Fri 08 Apr, 2016 11:25
by 2useven10
Этот атрибут (No scrub data) можно смотреть/менять в фаровском диалоге смены атрибутов файла (Ctrl-A).
Если выставлен и используется системная ф-я копирования файлов, действительно вылезает ошибка.

Не все копируется в nul

Posted: Fri 08 Apr, 2016 11:27
by ELEA
Точно, он называется "Нет данных очистки".

Не все копируется в nul

Posted: Fri 08 Apr, 2016 11:32
by DrKnS
Баг в системной функции копирования, известен достаточно давно, проявляется в т. ч. в тех ОС, где нет FILE_ATTRIBUTE_NO_SCRUB_DATA, если, например, копировать r/o файлы.

Не все копируется в nul

Posted: Fri 08 Apr, 2016 12:46
by HaRT
DrKnS wrote: Баг в системной функции копирования
А нет ли под рукой ссылки на более детальное описание?
В частности, интересно понять, как зависит от целевой ФС.

Не все копируется в nul

Posted: Fri 08 Apr, 2016 13:02
by DrKnS
У меня нет, но можно спрость @zg.

Не все копируется в nul

Posted: Fri 08 Apr, 2016 18:22
by 2useven10
-DEL-

Не все копируется в nul

Posted: Sun 18 Aug, 2019 06:15
by AlexRozen
Кстати, столкнулся с этим багом, причём атрибут на файлы выставляет фаровский же Archive Manager при распаковке файлов утилиты Crystal Disk Info из zip-архива с официального сайта. Проявилось на нескольких версиях (только что проверил версию 8.2.4).
Причём, в отличие от аналогичного случая, снять атрибут "по дереву" FAR-ом (и командой attrib по дереву и маске тоже) не помогает. Атрибута на файлах нет, а в nul они не копируются. Нужно снимать индивидуально на каждом файле по отдельности. Если скопировать всю папку на другой NTFS-том с выключенным "системным копированием", а потом включить его обратно, то проблемное поведение сохраняется.

Интересно, откуда Archive Manager этот атрибут выцарапывает и как и зачем так "зашкварно" выставляет? (ощущение, что он там еще что-то выставляет непознаваемое)

P.S. NTFS Stream Explorer показывает маску атрибутов 0x00180020 на "некопируемом" таком файле, а на ставшем копируемым после индивидуальной смены атрибутов маска 0x00000020 (просто "архивный")

Не все копируется в nul

Posted: Sun 18 Aug, 2019 10:16
by DrKnS
AlexRozen wrote: Sun 18 Aug, 2019 06:15NTFS Stream Explorer показывает маску атрибутов 0x00180020 на "некопируемом" таком файле
0x00180020 - это FILE_ATTRIBUTE_UNPINNED | FILE_ATTRIBUTE_PINNED | FILE_ATTRIBUTE_ARCHIVE, что выглядит достаточно дико.

В arclite есть такой прекрасный комментарий - some programs store posix attributes in high 16 bits.
Ваш архив, похоже, был создан одной из этих some programs.
Ниже по коду плагин корректно разделяет posix и win32 биты, получая что-то типа "A -rwxrwxrwx" (это функция отображения аттрибутов по Ctrl+A).
Однако при распаковке плагин себя подобным разбором не утруждает, берет значение как есть и пихает его в SetFileAttributes.

Это годами сходило с рук, т.к. в Windows не использовались старшие 16 бит аттрибутов и SetFileAttributes всю эту дичь молча игнорировала.
А потом появилась Windows 10 со всякими , и вот.

Исправлено в arclite 310.

Не все копируется в nul

Posted: Sun 18 Aug, 2019 11:24
by 2useven10
DrKnS wrote: Sun 18 Aug, 2019 10:16 Исправлено в arclite 310.
Не те атрибуты маскируются. Надо посиксные. Как-то так: { (value >> 16) & 0x3fff, value & 0xffff };

Не все копируется в nul

Posted: Sun 18 Aug, 2019 11:45
by DrKnS
2useven10 wrote: Sun 18 Aug, 2019 11:24Не те атрибуты маскируются.
1. Я логику не менял.
2. Што "не те"? Там же английским языком написано:
// p7zip - stores additional 0x8000 flag marker.
// macos - stores additional 0x4000 flag marker.

Какой смысл маскировать биты в старшем слове, если речь о 14 и 15?

Не все копируется в nul

Posted: Sun 18 Aug, 2019 12:40
by 2useven10
DrKnS,
1) если логику не менять, останется ошибка, так что утверждение странное.
2) зачем терять 2 старших бита 'виндовых' атрибутов (то что на момент написания arclite их было только 14 не повод).
3) 0x8000, 0x4000 - это маркеры создателя архива а не собственно posix атрибуты и их имхо надо (можно) убрать.

Не все копируется в nul

Posted: Sun 18 Aug, 2019 13:05
by DrKnS
2useven10 wrote: Sun 18 Aug, 2019 12:40 если логику не менять, останется ошибка, так что утверждение странное
Логику некто w17 скопировал из 7-zip.
Где именно "ошибка" - в копипасте или в 7-zip?
зачем терять 2 старших бита 'виндовых' атрибутов (то что на момент написания arclite их было только 14 не повод)
Затем что эти "2 старших бита" - это "маркеры создателя архива".
0x8000, 0x4000 - это маркеры создателя архива а не собственно posix атрибуты и их имхо надо (можно) убрать.
Posix-атрибуты - это старшее слово.

Старшее слово - это биты с 16-го (0x00010000) по 31-й (0x80000000).

0x4000 (0x00004000) - это 14-й бит младшего слова.

0x8000 (0x00008000) - это 15-й бит младшего слова.

Как предполагается убирать 14-й и 15-й биты младшего слова из старшего слова? Зачем? Кто все эти люди?