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

Здесь можно сообщить о найденных багах в Far.
ELEA
Posts: 3
Joined: Fri 08 Apr, 2016 09:14

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

Post by ELEA »

Не знаю, БАГ это или нет, но замечено, что некоторые файлы просто не копируются в nul.
Иногда замеряю скорость чтения с дисков копируя файлы в nul.
Заметил, что некоторые файлы выдают ошибку "неверная функция".
Просто так они копируются, открываются, а в nul - никак. Видимо из-за особого содержания, но как связано не понятно.
2useven10
Posts: 5204
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 310 times

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

Post by 2useven10 »

ELEA wrote: Не знаю, БАГ это или нет,
С таким репортом и не узнаете.
Прочтите и попробуйте ещё раз.
ELEA
Posts: 3
Joined: Fri 08 Apr, 2016 09:14

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

Post by ELEA »

В общем я нашел причину. После любого переноса через FAT32 флешку - файл вылечивался. Подозрения пали на расширенные свойства/возможности NTFS.
Есть программа NTFS Stream explorer.
В ней можно смотреть различные параметры фалов, которые недоступны обычными средствами.
Там есть закладка "Стандартная информация", в ней есть - прочие атрибуты.
Среди данных атрибутов есть: "Не проверять скрамблером". Даже не подозревал о существовании такого атрибута.
Не знаю, что это за атрибут такой, но если его снять, то все работает как надо.
Если же на любой другой файл поставить этот атрибут - то его уже не скопируешь в nul, т.к. выдается ошибка про неверную функцию.
Если кто знает, что это за такой атрибут - поделитесь, хотелось бы знать. Спасибо.
2useven10
Posts: 5204
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 310 times

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

Post by 2useven10 »

Этот атрибут (No scrub data) можно смотреть/менять в фаровском диалоге смены атрибутов файла (Ctrl-A).
Если выставлен и используется системная ф-я копирования файлов, действительно вылезает ошибка.
ELEA
Posts: 3
Joined: Fri 08 Apr, 2016 09:14

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

Post by ELEA »

Точно, он называется "Нет данных очистки".
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

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

Post by DrKnS »

Баг в системной функции копирования, известен достаточно давно, проявляется в т. ч. в тех ОС, где нет FILE_ATTRIBUTE_NO_SCRUB_DATA, если, например, копировать r/o файлы.
User avatar
HaRT
Moderator
Posts: 10822
Joined: Tue 30 Aug, 2005 17:21
Has thanked: 221 times
Been thanked: 358 times

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

Post by HaRT »

DrKnS wrote: Баг в системной функции копирования
А нет ли под рукой ссылки на более детальное описание?
В частности, интересно понять, как зависит от целевой ФС.
Фар есть инструмент, а не нянька. © 2009 DrKnS
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

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

Post by DrKnS »

У меня нет, но можно спрость @zg.
2useven10
Posts: 5204
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 310 times

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

Post by 2useven10 »

-DEL-
AlexRozen
Posts: 7
Joined: Sun 18 Aug, 2019 05:51
Has thanked: 1 time

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

Post by AlexRozen »

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

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

P.S. NTFS Stream Explorer показывает маску атрибутов 0x00180020 на "некопируемом" таком файле, а на ставшем копируемым после индивидуальной смены атрибутов маска 0x00000020 (просто "архивный")
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

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

Post 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.
2useven10
Posts: 5204
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 310 times

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

Post by 2useven10 »

DrKnS wrote: Sun 18 Aug, 2019 10:16 Исправлено в arclite 310.
Не те атрибуты маскируются. Надо посиксные. Как-то так: { (value >> 16) & 0x3fff, value & 0xffff };
Last edited by 2useven10 on Sun 18 Aug, 2019 12:47, edited 2 times in total.
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

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

Post 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?
2useven10
Posts: 5204
Joined: Mon 07 Sep, 2009 10:40
Has thanked: 18 times
Been thanked: 310 times

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

Post by 2useven10 »

DrKnS,
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.
User avatar
DrKnS
Posts: 6114
Joined: Thu 04 Aug, 2005 06:44
Location: Kyiv
Has thanked: 12 times
Been thanked: 426 times

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

Post 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-й биты младшего слова из старшего слова? Зачем? Кто все эти люди?
Post Reply

Return to “Глюки и баги”