Не все копируется в nul
Не все копируется в nul
Не знаю, БАГ это или нет, но замечено, что некоторые файлы просто не копируются в nul.
Иногда замеряю скорость чтения с дисков копируя файлы в nul.
Заметил, что некоторые файлы выдают ошибку "неверная функция".
Просто так они копируются, открываются, а в nul - никак. Видимо из-за особого содержания, но как связано не понятно.
Иногда замеряю скорость чтения с дисков копируя файлы в nul.
Заметил, что некоторые файлы выдают ошибку "неверная функция".
Просто так они копируются, открываются, а в nul - никак. Видимо из-за особого содержания, но как связано не понятно.
Не все копируется в nul
В общем я нашел причину. После любого переноса через FAT32 флешку - файл вылечивался. Подозрения пали на расширенные свойства/возможности NTFS.
Есть программа NTFS Stream explorer.
В ней можно смотреть различные параметры фалов, которые недоступны обычными средствами.
Там есть закладка "Стандартная информация", в ней есть - прочие атрибуты.
Среди данных атрибутов есть: "Не проверять скрамблером". Даже не подозревал о существовании такого атрибута.
Не знаю, что это за атрибут такой, но если его снять, то все работает как надо.
Если же на любой другой файл поставить этот атрибут - то его уже не скопируешь в nul, т.к. выдается ошибка про неверную функцию.
Если кто знает, что это за такой атрибут - поделитесь, хотелось бы знать. Спасибо.
Есть программа NTFS Stream explorer.
В ней можно смотреть различные параметры фалов, которые недоступны обычными средствами.
Там есть закладка "Стандартная информация", в ней есть - прочие атрибуты.
Среди данных атрибутов есть: "Не проверять скрамблером". Даже не подозревал о существовании такого атрибута.
Не знаю, что это за атрибут такой, но если его снять, то все работает как надо.
Если же на любой другой файл поставить этот атрибут - то его уже не скопируешь в nul, т.к. выдается ошибка про неверную функцию.
Если кто знает, что это за такой атрибут - поделитесь, хотелось бы знать. Спасибо.
Не все копируется в nul
Этот атрибут (No scrub data) можно смотреть/менять в фаровском диалоге смены атрибутов файла (Ctrl-A).
Если выставлен и используется системная ф-я копирования файлов, действительно вылезает ошибка.
Если выставлен и используется системная ф-я копирования файлов, действительно вылезает ошибка.
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Не все копируется в nul
Баг в системной функции копирования, известен достаточно давно, проявляется в т. ч. в тех ОС, где нет FILE_ATTRIBUTE_NO_SCRUB_DATA, если, например, копировать r/o файлы.
- HaRT
- Moderator
- Posts: 10822
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
Не все копируется в nul
А нет ли под рукой ссылки на более детальное описание?
В частности, интересно понять, как зависит от целевой ФС.
Фар есть инструмент, а не нянька. © 2009 DrKnS
Не все копируется в nul
Кстати, столкнулся с этим багом, причём атрибут на файлы выставляет фаровский же Archive Manager при распаковке файлов утилиты Crystal Disk Info из zip-архива с официального сайта. Проявилось на нескольких версиях (только что проверил версию 8.2.4).
Причём, в отличие от аналогичного случая, снять атрибут "по дереву" FAR-ом (и командой attrib по дереву и маске тоже) не помогает. Атрибута на файлах нет, а в nul они не копируются. Нужно снимать индивидуально на каждом файле по отдельности. Если скопировать всю папку на другой NTFS-том с выключенным "системным копированием", а потом включить его обратно, то проблемное поведение сохраняется.
Интересно, откуда Archive Manager этот атрибут выцарапывает и как и зачем так "зашкварно" выставляет? (ощущение, что он там еще что-то выставляет непознаваемое)
P.S. NTFS Stream Explorer показывает маску атрибутов 0x00180020 на "некопируемом" таком файле, а на ставшем копируемым после индивидуальной смены атрибутов маска 0x00000020 (просто "архивный")
Причём, в отличие от аналогичного случая, снять атрибут "по дереву" FAR-ом (и командой attrib по дереву и маске тоже) не помогает. Атрибута на файлах нет, а в nul они не копируются. Нужно снимать индивидуально на каждом файле по отдельности. Если скопировать всю папку на другой NTFS-том с выключенным "системным копированием", а потом включить его обратно, то проблемное поведение сохраняется.
Интересно, откуда Archive Manager этот атрибут выцарапывает и как и зачем так "зашкварно" выставляет? (ощущение, что он там еще что-то выставляет непознаваемое)
P.S. NTFS Stream Explorer показывает маску атрибутов 0x00180020 на "некопируемом" таком файле, а на ставшем копируемым после индивидуальной смены атрибутов маска 0x00000020 (просто "архивный")
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Не все копируется в nul
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
Не те атрибуты маскируются. Надо посиксные. Как-то так: { (value >> 16) & 0x3fff, value & 0xffff };
Last edited by 2useven10 on Sun 18 Aug, 2019 12:47, edited 2 times in total.
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Не все копируется в nul
1. Я логику не менял.
2. Што "не те"? Там же английским языком написано:
// p7zip - stores additional 0x8000 flag marker.
// macos - stores additional 0x4000 flag marker.
Какой смысл маскировать биты в старшем слове, если речь о 14 и 15?
Не все копируется в nul
DrKnS,
1) если логику не менять, останется ошибка, так что утверждение странное.
2) зачем терять 2 старших бита 'виндовых' атрибутов (то что на момент написания arclite их было только 14 не повод).
3) 0x8000, 0x4000 - это маркеры создателя архива а не собственно posix атрибуты и их имхо надо (можно) убрать.
1) если логику не менять, останется ошибка, так что утверждение странное.
2) зачем терять 2 старших бита 'виндовых' атрибутов (то что на момент написания arclite их было только 14 не повод).
3) 0x8000, 0x4000 - это маркеры создателя архива а не собственно posix атрибуты и их имхо надо (можно) убрать.
Last edited by 2useven10 on Sun 18 Aug, 2019 12:41, edited 1 time in total.
- DrKnS
- Posts: 6114
- Joined: Thu 04 Aug, 2005 06:44
- Location: Kyiv
- Has thanked: 12 times
- Been thanked: 426 times
Не все копируется в nul
Логику некто w17 скопировал из 7-zip.
Где именно "ошибка" - в копипасте или в 7-zip?
Затем что эти "2 старших бита" - это "маркеры создателя архива".зачем терять 2 старших бита 'виндовых' атрибутов (то что на момент написания arclite их было только 14 не повод)
Posix-атрибуты - это старшее слово.0x8000, 0x4000 - это маркеры создателя архива а не собственно posix атрибуты и их имхо надо (можно) убрать.
Старшее слово - это биты с 16-го (0x00010000) по 31-й (0x80000000).
0x4000 (0x00004000) - это 14-й бит младшего слова.
0x8000 (0x00008000) - это 15-й бит младшего слова.
Как предполагается убирать 14-й и 15-й биты младшего слова из старшего слова? Зачем? Кто все эти люди?