Здравствуйте, Maniacal, Вы писали:
M>Здравствуйте, Carc, Вы писали:
C>>А что сама C-шная rename вызывает?
C>>В Винде есть несколько вариантов переименования\перемещения.
C>>См. на MoveFileEx + флаг MOVEFILE_COPY_ALLOWED
M>В disassembly дебаггер что-то не очень стремится нутро CRT показывать даже после включения загрузки символов, но тут проблема не в rename явно, а в fopen. Если создавать файл, который недавно был в файловой системе, то дата создания берётся от удалённого файла. Если хотя бы одну букву поменять в имени, то всё нормально. С костылями я смогу это обойти или через WinAPI тоже, напрямую задавая дату создания. Но коллеги не оценят, если догадаются заглянуть в код. Всё лицо разобьют себе фейспалмом. Не в тех годах я уже такими костылями заплатки в коде делать. Хотелось по-человечески. И главное разобраться за что. Косвенно где-то всплывают наводки, что это последствия зашитого в API функционала по сохранению даты создания файла при его копировании в другое место. Но тут и место то же, и файл не копируется, а создаётся новый.
Дык «другой бы спорил» ©
Ясен пень, что rename это в первую очередь некая абстракция, и не хочется от нее отступать. (кроссс-платформ!!?!)
А зачем дизасм? CRT как линкуется? Динамически или статически? Если статитечски, то можно посмотреть что получим в Map-файле!?!
Как вариант, и именно чтоб капитал пробрести и невинность соблюсти, можно сначала писать не в только что удаленный файл (ну тот, который удалили\переименовали в архив или типа того), а в некий temp-файл (с каким-нить временным случайным именем).
А когда запись заканчивается, и файл закрывается, то переименовывать его в то саоме, первое имя, которое удаляли\переименовыввали.
Только сдается мне это все равно костыли. Чего там сама NTFS надумает, так оно и будет.
Можно конечно еще посмотреть на
SetFileTime, но опять же WIndows Specific...