2useven10 wrote: ↑Mon 17 Jul, 2017 15:06вполне можно нагрузить колени и таки
вставить подавление (да чужой) ошибки в код фар
В краткосрочной перспективе - да. У пользователей акрониса будет меньше испорченных файлов, а у нас меньше левых багрепортов.
В долгосрочной - не факт.
Не проявись этот баг в фаре, он бы проявился где-то ещё. Или не проявился бы и просто втихаря портил файлы. Изредка. Но, по закону Мёрфи, с максимальным ущербом.
В результате же этого обсуждения топикстартер разобрался и предотвратил маловероятное (но возможное) вырывание волос отовсюду в один прекрасный пятничный вечер в конце квартала, а если напишет в техподдержку акрониса - возможно, предотвратит ещё кому-нибудь и мир станет немного лучше.
Ради этого я, в принципе, не против раз в год-два кому-нибудь ещё подоказывать, что это не наш баг.
Со мной это было, поэтому я тоже скажу, хотя меня никто и не спрашивал, ибо я никакого отношения к разработке ФАРа не имею.
С точки зрения разработчика - его продукт должен иметь наибольшую беспроблемность, т.е. быть максимально совместимым со всеми драйверами, файловыми системами и пр. По-моему, это очевидно. От того, что ухудшенная (не избыточная) совместимость приведет к появлению глюков из-за несовместимости с чем-либо, 99% пользователей ФАРа легче не станет, потому что это будут "косяки ФАРа", я например, несмотря на больше 20 лет программерского опыта с разными языками-ос-архитектурами был уверен, что это именно косяк ФАРа. И если бы не 2useven10, который не поленился успешно повторить стабильно глючивший сценарий, за что ему еще раз спасибо, который я поленился повторять, считая глюк "плавающим", до сих пор был бы уверен что виноват фар. Мало кто, нарвавшись на глюк в ФАРе, сможет выяснить настоящую причину, и еще меньше - устранить ее. Поэтому вряд ли принципиальная позиция реально что-то изменит в лучшую сторону.
С другой стороны могу повторить сказанное мной парой постов выше - вставка избыточного позиционирования сразу после пересоздания файла не помогала, помогло уже непосредственно перед записью, т.е. вероятно, косяк еще зависел от задержки по времени между операциями, поэтому добавление избыточного позиционирования в случае чужих глюков проблему все равно может не решить, так что решение не однозначно.
Kirillony wrote: ↑Mon 17 Jul, 2017 15:38Acronis - всегда был глюкодромом, обжигался с ним не раз и зарёкся вообще когда-нибудь использовать
Да нет, старые версии были вполне неплохи, но с uefi+10+gpt работать перестали, а нынешний акронис - реально превратили в монстро-хрень, жалею что связался по старой памяти.
falcon111 wrote: ↑Mon 17 Jul, 2017 20:00вставка избыточного позиционирования сразу после пересоздания файла не помогала
file::SetPointer() не меняет позицию в файле, просто если новая позиция отличается от текущей, выставляется флаг m_NeedSyncPointer = true;. Так как с его точки зрения текущая позиция = 0, вызов EditFile.SetPointer(0) вообще не должен помогать.
Last edited by 2useven10 on Mon 17 Jul, 2017 20:52, edited 2 times in total.
Если меня еще кто спросит почему я с 2008-го пользуюсь Norton Ghost (сейчас 11.5.1.2266) буду давать ссылку на эту тему . Если и пользуюсь Acronis то только с LiveCD, что-то такое нехорошее я в нем когда-то почувствовал. А вообще любая лишняя сторонняя служба потенциальный источник проблем.
DrKnS wrote: ↑Mon 17 Jul, 2017 16:23и мир станет немного лучше.
Не понимаю почему это взаимоисключающие вещи...
1) делаем фар более устойчивым к чужим багам
2) если есть потребность в улучшении мира - репортите баг акронисам независимо от топикстартера.
Здравствуйте, столкнулся с такой проблемой, Про нажатии F3 на текстовом файле, вместо корректного отображения содержимого показывается сжеванный набор музыкальных, карточных и др. символов...
Это происходит после изменения файла по F4. Стоит что-либо записать в тестовый файл и сохранить его (в режиме F4), а затем просмотреть по F3, отображается каша символов, вместо текста, а то и вовсе, файл получается пустой или добавленная строка пустая!!!
Если изменить текстовый файл, например в блокноте виндовс, то F3 все показывает корректно!
Если кто-то сталкивался с подобным, сообщите что делать?
Far установлен на Win 10 у меня, последняя версия 64 bit с официального сайта. Я перепробовал все доступные версии, в том числе x86, и даже устанавливал Far 2, но проблема сохраняется.
На другом компе, на Win 7 такой проблемы у меня нет!
Скорее всего у вас для файла включается режим Dump.
Видимо файл не совсем 'текстовый' - в нём есть бинарные нули '\0'.
Этот режим сохраняется и потом файл открывается в таком виде даже если нули будут удалены.
Смените режим на Text через Shift-F4 (и выясните откуда в текстовом файле нули).
Last edited by 2useven10 on Mon 05 Mar, 2018 08:52, edited 1 time in total.
Это происходит не с одним текстовым фалом. а со всеми.
Я провел эксперимент. Создал новый текстовый файл (1.txt)
Вписал туда "qweqweqwe" и сохранил. По F3 показало все корректно (Shift+F4 показало режим - "Текст").
Снова открыл файл F4. Скопировал часть текста, сделал пару абзацев, вставил текст, сохранил.
Открыл F3 - уже крокозябы. Режим показывает "Дамп". При этом первая строка крокозяб сместилась вправо. При включении режима "Текст", показывает правильно, кроме первой строчки - она уехала вправо. При включении режима "Код", пустые пробелы до начала первой строки показаны нулями.
Нулевые символы берутся буквально при сохранение файла по F4. И только в фаре. Ни какие другие редакторы текста этого не делают. Подскажите, пожалуйста, как можно с ними "разобраться"? Спасибо!
Для начала проверьте голый Фар - без плагинов, в том числе без стандартных. Удостоверьтесь сначала, что F11 в панелях и в редакторе показывает пустое меню, затем повторите свои опыты.