Наблюдение:
Используем стандартный комплект поставки Far - Far.exе + те 16 плугинов что идут вместе с ним и чьи исходники обновляются из репозитария на SVN. Более никаких добавок! Эксперимент должен быть "чистым".
Провёл проверку применимости моего патча на разных вариантах Far 2.0.1073 и 2.0.1074. Итог любопытный: если для 2.0.1073 всё работает как часы, вне зависимости от применения исходникам патчей "Mantis#0000292: Операции над файлом без описания ведут к "обновлению" файла описаний" и "Mantis#0000999: Неправильный сдвиг окна редактора после поиска при выбраной опции Select Found", то в 2.0.1074 работает только не изменённый код! Вот замечания к моему проекту которые мне пришлось дать в пояснительной записке о причине использования "старого" варианта:
Цитата:
Визуально это проявляется как вот такое сообщение архиватора:
Цитата:
и создании файла !FN с нулевой длинной. Но, тут есть любопытный нюанс - данное явление, хотя и обладает 100% воспроизводимостью, проявляется только при запуске модифицированного Far 2.0.1074 исключительно в среде Take Command 9.02.157, а при запуске из стандартного системного командного процессора CMD.EXE всё работает нормально:
Цитата:
А раз так, то можно предположить, что с учётом изменений в 2.0.1074:
Цитата:
что возможная причина его возникновения как раз в том, убранные преобразования путей приводят к тому, что связка "Far.exe + командный процессор" не может правильно отработать команду, и в этом месте необходимо ещё раз все просмотреть в исходниках Far. Я к сожалению этого уже сделать не смогу - предыдущая резервная копия исходников сохранённая СУБД это 2.0.1066 SVN 3327. Но, сам факт наличия данного явления со 100% воспроизводимостью заставляет меня просить разработчиков о его устранении. Вдобавок к этому, выяснилось ещё одно интересное явление:
связка "MultiArc + InfoZip UnZip 6.0" не может распаковать архивы с именами вида "DivFix++_v0.32-Win32.zip" - распакуется если есть, только вложенный в них каталог типа "DivFix++_v0.32-Win32", а его содержимое из архива не распакуется. В 7Zip данной проблемы не наблюдаю, по крайней мере при использовании его GUI оболочки 7Zfm, следовательно тут можно предполагать и наличие проблемы InfoZip. Zip 3.1b / UnZIP 6.0.
P.S.
Всякие слова типа "Опять проблемы своей сборки решаешь" будут проигнорированы вместе с их авторами - т.к. данные проблемы выловлены, 100% воспроизводятся и требуют решения. А все беспочвенные заявления, не имеющие под собой реальной экспериментальной проверки в этом случае есть ничто иное, как публичная роспись в собственном бессилии и лени.
Используем стандартный комплект поставки Far - Far.exе + те 16 плугинов что идут вместе с ним и чьи исходники обновляются из репозитария на SVN. Более никаких добавок! Эксперимент должен быть "чистым".
Провёл проверку применимости моего патча на разных вариантах Far 2.0.1073 и 2.0.1074. Итог любопытный: если для 2.0.1073 всё работает как часы, вне зависимости от применения исходникам патчей "Mantis#0000292: Операции над файлом без описания ведут к "обновлению" файла описаний" и "Mantis#0000999: Неправильный сдвиг окна редактора после поиска при выбраной опции Select Found", то в 2.0.1074 работает только не изменённый код! Вот замечания к моему проекту которые мне пришлось дать в пояснительной записке о причине использования "старого" варианта:
Цитата:
Замечание: в сборке 2.0.1074 при проверке патча для решения проблемы Mantis#0000692: нельзя войти в архив ZIP выявлено, что любое изменение внесённое в код файлов dizlist.cpp, dizlist.hpp, editor.cpp приводит к неработоспособности пункта "Преобразовать в SFX" для Zip архивов если используем InfoZip. В случае с PKZip всё работает, но проблема остаётся не решённой. Поэтому я принял решение собрать сборку с использованием версии 2.0.1073 поскольку в ней решены сразу два вопроса: и проблема с описаниями в файлах FILE_ID.DIZ/Descript.ion и проблема Mantis#0000999: "Неправильный сдвиг окна редактора после поиска при выбранной опции Select Found" проявляющаяся в том, что если при поиске задать опцию "Подсвечивать найденное", то при длине строки больше 1/2 размера окна редактор сдвигает окно влево до последнего символа искомого слова.
Визуально это проявляется как вот такое сообщение архиватора:
Цитата:
C:\Temp\14\Far20\plugins\multiarc\Formats\unzipsfx.exe => !FN:.zip=.exe!
C:\Temp\18\3\freesoftlist.zip =>> !FN:.zip=.exe!
TCC: File verification failed "!FN:.zip=.exe!"
1 file copied
и создании файла !FN с нулевой длинной. Но, тут есть любопытный нюанс - данное явление, хотя и обладает 100% воспроизводимостью, проявляется только при запуске модифицированного Far 2.0.1074 исключительно в среде Take Command 9.02.157, а при запуске из стандартного системного командного процессора CMD.EXE всё работает нормально:
Цитата:
C:\Temp\14\Far20\plugins\multiarc\Formats\unzipsfx.exe
C:\Temp\18\3\freesoftlist.zip
1 file(s) copied.
Zip entry offsets appear off by 28672 bytes - correcting...
А раз так, то можно предположить, что с учётом изменений в 2.0.1074:
Цитата:
drkns 06.08.2009 19:14:43 +0200 - build 1074
1. Продолжение 1073: лишние преобразования путей при создании ссылок.
Там же - убрана мешанина из табов/пробелов и прочая косметика.
что возможная причина его возникновения как раз в том, убранные преобразования путей приводят к тому, что связка "Far.exe + командный процессор" не может правильно отработать команду, и в этом месте необходимо ещё раз все просмотреть в исходниках Far. Я к сожалению этого уже сделать не смогу - предыдущая резервная копия исходников сохранённая СУБД это 2.0.1066 SVN 3327. Но, сам факт наличия данного явления со 100% воспроизводимостью заставляет меня просить разработчиков о его устранении. Вдобавок к этому, выяснилось ещё одно интересное явление:
связка "MultiArc + InfoZip UnZip 6.0" не может распаковать архивы с именами вида "DivFix++_v0.32-Win32.zip" - распакуется если есть, только вложенный в них каталог типа "DivFix++_v0.32-Win32", а его содержимое из архива не распакуется. В 7Zip данной проблемы не наблюдаю, по крайней мере при использовании его GUI оболочки 7Zfm, следовательно тут можно предполагать и наличие проблемы InfoZip. Zip 3.1b / UnZIP 6.0.
P.S.
Всякие слова типа "Опять проблемы своей сборки решаешь" будут проигнорированы вместе с их авторами - т.к. данные проблемы выловлены, 100% воспроизводятся и требуют решения. А все беспочвенные заявления, не имеющие под собой реальной экспериментальной проверки в этом случае есть ничто иное, как публичная роспись в собственном бессилии и лени.