» WinRAR (часть 2)

Хардлинков нет на fat

А на деле вот (правда ещё времён NT 3.1) список недопустимых для имён NTFS символов - KB100008:

Цитата:

Соглашения именования в NTFS

Имена файлов могут состоять не более чем из 255 символов, включая любое расширение. В именах сохраняется регистр введенных символов, но сами имена не зависят от регистра. NTFS не различает имена в зависимости от регистра. В именах могут быть использованы любые символы за исключением указанных ниже.

? " / \ < > * | :
                

В настоящее время из командной строки можно задать имя файла длиной не более 253 символов.

пробел среди запрещённых не значится, и то, что конкретные программы Микрософт не соблюдают спецификации сих же собственной ОС не означает что надо идти по их пути помогая им консервировать их грубые ошибки - у них и так иконостас как новогодняя ёлка от них блестит, а исправлять им некогда - срочно надо очередную глупость реализовать ибо в Тридевятом Царстве на ними ещё куры не смеялись. Походу когда сию публику проектировали на их долю мозги выделяли по остаточному принципы. Ничем иным наблюдаемое не объяснить...


Добавлено:
Inoz2000

А что, кроме FAT ничего на свете нет? Но и на FAT пробела в списке не допустимых для имён файлов-каталогов нет. Наличие грубой ошибки в коде Explorer.exe тянущейся ещё с времён WinNT 3.50 не основание её беречь, холить и лелеять.

Victor_VG

Цитата:

пробел среди запрещённых не значится

Вы посмотрите внимательнее, сколько там пробелов между этими запрещёнными символами

Цитата:

правда ещё времён NT 3.1

Так это же при царе Горохе было В предыдущем сообщении я дал более актуальную ссылку.

pikorembo

В том тексте список мелкомягкие не просто так убрали - боятся что начнут требовать исправления багов.

pikorembo

Цитата:

Может быть, рассмотреть этот вопрос шире, не только применительно к формату UUE?

В случае uue, который передается как текстовый файл, пробелы в конце являются вероятным следствием проблем при передаче. Но у других архивных форматов пробелы сами по себе не возникнут, и если они есть в архиве, значит они скорее всего были и у файлов перед упаковкой. Значит зачем-то это пользователю было нужно.

Цитата:

https://support.microsoft.com/en-us/kb/320081

А здесь: https://msdn.microsoft.com/en-us/library/windows/desktop/aa365247%28v=vs.85%29.aspx
можно прочесть следующее:
For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system.

WinRAR ведь создает файлы с пробелом в конце с помощью того же Windows API и документированного префикса "\\?\". Никакого хакерства, штатные средства, описанные в документации. Многие программы умеют создавать подобные файлы, работать с ними, удалять их.

Хочу настроить в планировщик задание бэкапа одной папки. Как это можно сделать? Раньше через командную строку делал, теперь не получается.

К примеру нужно заархивировать папку c:\test и архив расположить в d:\bcp.rar, при этом старый архив просто затереть новым. Сделать нужно все в фоне, не мешая пользователю.

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

Какой должна быть строчка с параметрами для планировщика?

TemaZosin

От него зависит, ибо планировщики-то разные. Но в качестве инструмента я бы использовал связку nnbackup + rar + nncon ибо спокойнее - там вроде почти всех блох ребята повыловили.

pikorembo

Цитата:

Точно так же, как и с другими символами недопустимыми в Windows

Пробел в имени файла под Windows допустим. И неважно, в конце имени или нет, один пробел или больше. Более того, любая нормально написанная windows-программа спокойно откроет такой файл так же, как любой другой.

Ну а если программа на таком имени спотыкается, значит у её разработчика руки растут оттуда, откуда у остальных людей ноги.

EugeneRoshal

Цитата:

Но у других архивных форматов пробелы сами по себе не возникнут

Тогда обратное предложение. Нужно добавить эвристику в алгоритм декодирования UUE. Если в строке данных мы видим пробелы за пределами обозначенного количества байт, значит была ошибка при передаче UUE. Следовательно требуется отсечение концевых пробелов в имени файла. В противном случае высока вероятность того, что пользователь намеренно оставил концевые пробелы в имени файла, и отсекать их не требуется. Но здесь есть одна загвоздка: если файл нулевой длины и финальная строка данных состоит из пробела вместо грависа. В этом случае принимаем решение по количеству пробелов в финальной строке.

Цитата:

Тогда обратное предложение. Нужно добавить эвристику в алгоритм декодирования UUE

А надо ли ?

Мне вот что интересно: сколько жалоб на эту проблему Евгений получил за 20 лет существования WinRAR (с июня 1995 года) ? Если ни одной, то может это и не проблема вовсе ?

Benchmark

Цитата:

А надо ли ?

Вы сначала поймите смысл не только первых 2-х предложений, которые процитировали, но и остального текста. Может быть, тогда ответ на ваш вопрос найдётся сам собой

pikorembo
Есть хороший анекдот в тему.

Приходит один человек к врачу, причудливо изгибается и говорит:
- Доктор, мне почему-то становится больно каждый раз, когда я так делаю.
Врач на него удивленно смотрит, а затем отвечает:
- А вы так больше не делайте.

Так вот, возвращаясь к WinRAR. Если выяснится, что за 20 лет его существования почему-то только один юзер pikorembo придумал причудливую, почти экзотическую ситуацию, или оказался единственным, кто столкнулся с ней, стоит ли ради этого что-то менять в коде ?

pikorembo
Соглашусь с Benchmark, для эвристики нужно иметь какое-то представление о реальном проявлении обсуждаемой ситуации. Почему добавляются пробелы. Могут ли вместо них быть символы табуляции или какой-то другой мусор. Делать эвристику на основании одного случая, который я даже и живьем не видел - неразумно. А других жалоб пользователей на такую ситуацию я не помню.

Если считаете, что вероятность намеренных концевых пробелов выше вероятности случайных пробелов, я могу вернуть работу с uue как было. Uue вообще редко используется с архиваторами, а ситуацию с концевыми пробелами в uue я до сих пор живьем не встречал, ни со случайными, ни с умышленными.

EugeneRoshal

Я так же впервые услышал про это от pikorembo. За почти сорок лет работы с ЭВМ, что говорит о "100%-й повторяемости" данного случая - ни на OS/360 - OS/370, ни на Минск-22/32/БЭСМ-6/Эльбрус, DEC PDP-11, на на микроЭВМ и рабочих станциях IBM, SUN, DEC, HP, SGI, Intergraph разных классов и под разными ОС начиная с CP/M - MP/M -DOS, NetWare, Vines и кончая всеми версиями Windows начиная с 1.0 по сегодняшние её версии, OS/2, UNIX (SCO, AIX, SUN, BSD, ...) и Linux таких событий ни я сам, ни один из моих коллег что-то не припомним.

Значит можно высказать предположение о том что это случайная ошибка, например из-за неверных приёмов работы оператора в источнике данных. Иначе это можно объяснить только тем, что на машине источнике файлы имеют именно такие имена, но на приёмной стороне это вызвало проявление скрытых унаследованных ошибок в ПО Микрософт которые в общем-то известны ещё со времён Windows 3.0 где они впервые были допущены а после перешли в разряд know errors и не исправляются под предлогом "обратной совместимости", но многими пользователями они подсознательно игнорируются в силу их привычности.

Benchmark

Цитата:

сколько жалоб на эту проблему Евгений получил за 20 лет существования WinRAR (с июня 1995 года) ? Если ни одной, то может это и не проблема вовсе ?

Железная логика! Если ни одной жалобы не поступило, значит "это и не проблема вовсе" Интересно, а сколько поступило жалоб на ошибку, которая была исправлена в последней бете:

Цитата:

комментарий архива не зашифровывался, если он добавлялся в архив с зашифрованными заголовками командой "c" без указания ключа -hp

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

EugeneRoshal

Цитата:

я даже и живьем не видел

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

Цитата:

других жалоб пользователей на такую ситуацию я не помню.

А теперь попробуйте догадаться, сколько человек обнаружило эту проблему, но не сообщило вам. Впрочем, я понимаю ваше нежелание заниматься мелкими фиксами.

pikorembo

Цитата:

Пройдитесь по темам на ру-борде — везде, где вставлен UUE-код, он копируется с пробелами в конце.

UUE на ру-борде встречается, в основном, в варезнике. Думаю, у тамошних обитателей не отвалятся руки, если они скопируют код без пробелов или сами уберут несколько пробелов в конце.


Цитата:

подобная проблема раньше встречалась в почтовых программах

Может лучше пользоваться нормальными современными почтовыми программами ? В них подобной проблемы в принципе нет.


Цитата:

теперь попробуйте догадаться, сколько человек обнаружило эту проблему

И сколько же ? Телепаты в отпусках.

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


Цитата:

Цитата: комментарий архива не зашифровывался, если он добавлялся в архив с зашифрованными заголовками командой "c" без указания ключа -hp

Наверное, десять тысяч человек отписалось по этой проблеме, что автор наконец решился её исправить.

pikorembo

Чёткие статистические данные с методикой проверки их получения и подтверждённые факты где? Будут представлены - это основание к действию, нет - предложение отклоняется без объяснения причин.

ТЗ на любую разработку чётко оговаривает что, за какие деньги и в какие сроки должно быть представлено к приёмо-сдаточным испытаниям и любое отклонение от его рамок запрещено. Это законы любой разработки и эмоциями или личными побуждениями их не отменить, не изменить, и не обойти.

Benchmark

Цитата:

UUE на ру-борде встречается, в основном, в варезнике.

По себе людей не судят. Если вы подсели на халявку, то это не значит, что других тем на форуме не существует. Кстати, если вы не знали, на Марсе есть жизнь в Интернете существует много сайтов с подобной проблемой.

Цитата:

Может лучше пользоваться нормальными современными почтовыми программами ? В них подобной проблемы в принципе нет.

Так пользуйтесь на здоровье, кто вам мешает? Только не забудьте сообщить остальному миру, чтобы он тоже пересел на ваш софт. И будет всем счастье Кстати, что в вашем понимании "нормальная современная почтовая программа"?

Цитата:

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

Давайте уберем из популярного Total Commander'а функцию удаления файлов? Ведь так приятно юзать командную строку с командой del Если кто-то будет возмущаться, скажем, что Benchmark просил не разваливаться

Цитата:

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

Особенность не форума, а реализации программы Windows Clipboard (эта её "особенность" появилась ещё в Windows 3.0) вставляющей в копируемые с MIME type=Text/Plain данные концевые пробелы для того, чтобы различать переносы и разрывы строк. По крайней мере такой ответ в 89-м на вопрос "Почему и зачем Windows Clipboard дополняет строку концевым пробелом?" дали сотрудники Микрософт. Тот же Vault в UNIX таких "полезных преобразований не делает", а из Win программ XRayz ClipCache при копировании если такая настройка включена убирает из строк "премиальные" пробелы.

pikorembo

Цитата:

в Интернете существует много форумов с подобной проблемой

Цитата:

подобная проблема раньше встречалась в почтовых программах

Выше уже отвечено:

Цитата:

архиватор не обязан решать проблемы древних почтовых программ или не менее древних форумных движков

Benchmark
Сказал — как отрезал. Есть, сэр!

pikorembo

Цитата:

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

Так я ведь и сделал в обновленной сборке beta 3 для uue пропуск пробелов в конце. Вопрос в том, насколько востребованно при этом еще учитывать возможность намеренных пробелов в конце и делать для этого отдельную эвристику.

pikorembo

Кстати, иные ошибки не так то просто и выловить. К примеру скрытые ошибки в библиотеке clinck #344 и #345 мне несколько месяцев кровь портили пока из-за нового сбоя, уже в другом месте не поймал где именно первопричина всех сбоев находится...

EugeneRoshal

А Fast Drag & Drop будет?
Распаковка прям в папку минуя temp.

http://www.bandisoft.com/bandizip/help/fastdnd/

Ar0ma

Хорошо бы, но в случае многотомного архива это по моему проблематично.

Ar0ma

Цитата:

А Fast Drag & Drop будет?
Распаковка прям в папку минуя temp.

Я пытался сделать, чтобы если этот fast режим не сработал, автоматически использовался стандартный режим. Но мне это не удалось. То есть, при сбое fast режима придется выводить сообщение и просить пользователя выполнить drag&drop повторно, а это не совсем хорошо. А сбоить fast режим будет регулярно, так как работать он будет только со стандартными дисками, но не с прочими приемниками d&d. Пока я не решил, стоит ли это реализовывать в таком виде.

где-нибудь написано, как архивировать папки по маске (из консоли) или задача до сих нерешаема?
например, есть на диске папки:
name_a_1
name_a_2
name_b_1
name_a_11
name_b_12
name_b_2
name_a_12
name_b_3

надо заархивировать name_a_1 и name_a_2 - одной командой, не зацепив вложенные name_a_11 и name_a_12.
варианты типа "rar a newarc.rar name_a_*" или "rar a -r newarc.rar name_a_*" - сделают не то, что хотелось

say24
По крайней мере в нарисованном вами примере папки name_a_11 и name_a_12 в name_a_1 и name_a_2 и так отсутствуют. Папки name_b_1 присутствуют целых 3 раза на одном уровне (в корне), что в исправной файловой системе на диске недопустимо.

Pasha_ZZZ
ну недоправил примерчик, но смысл-то - ясен:
рекурсия цепляет всё подряд, в т.ч. вложенное, а без неё - вообще ничего не архивируется

задача - выбрать по маске из текущего каталога, вроде "C:\name_a_*"
в жизни - примерчики посложнее, но смысл один: папки - по шаблону

say24
У меня консольный действует так (если не включать рекурсию):
Цитата:

rar a archive.rar folder

- архивирует весь каталог folder с подкаталогами
Цитата:

rar a archive.rar folder\

- архивирует только каталог folder без подкаталогов