Долгое время пользовался Far, не зная о подводных камнях. После того как ощутил дзен от пользования раскраской файлов через TimeStamp и Attributes, с ужасом обнаружил, что весь диск C: (D:, E: и т. д.) имеет рандомные ("испорченные") TimeStamp и un‑"NonIndexed", несмотря на «жёстко» установленный пункт в свойствах диска C: (D:, E: и т. д.) - никогда не индексировать весь том. Как выяснилось, это из‑за распаковок ZIP, 7Z, RAR: файлы становятся опять un‑NonIndexed. И неожиданно… при копировании с флешки!
На флэш‑накопителях чаще всего Fat32 или exFat, и в них нет атрибута NonIndexed, а Far, копируя с них "фотики, котики, мемасики", принудительно устанавливает атрибуты un‑NonIndexed.
К сожалению, считаю, что баг нельзя выпрямить Lua‑скриптом, т.к. слишком много возни: "узнать, какое событие, какой адрес, какой список и т.д.", - тем более что штатными средствами Lua ломает ещё TimeStamp (нет возможности вернуть прежний TimeChanged). Поэтому Lua‑скрипт сразу отпадает.
Поправил часть кода в основном в copy.cpp. Также рикошетом задеты config.cpp(.hpp) (хранятся дефолтные настройки пунктов) и farlang.templ.m4 (языковые, в нашем случае одна и та-же фраза "NonIndexed")
Код компилируется в VC2019 и собирается всё Ок. Проверил работу FAR'а несколько часов, пока всё Ок.
Интересный баг у проводника Винды: при копировании большой структуры папок-файлов обнаруживается нетипичное поведение TimeStamp у пустой папки - не такое, как у непустой. Явно косяк: как будто выполняются два разных C‑процедурных кода. В данном случае FAR работает более точно - одинаково для пустых и непустых вложенных папок.