Closed minch-dev closed 2 years ago
Basically as far as I understand this is the bug in NTFS journaling system itself. I've already seen this behaviour before, when you delete some file and rename some other file to the name of a deleted one the creation date for some reason is getting rewritten by the deleted file's creation date. Indeed that's some really strange behaviour and for an old and proven system like NTFS filesystem is it's pretty unexpected to have programming errors like this at all.
Fixed, also added .lnk files support while I was at it.
And just when I thought the issue is fixed, NTFS strikes back with the same issue again.
Oh, basically it's a "feature" of NT based systems, wow, nice. https://web.archive.org/web/20140528165711/https://support.microsoft.com/?kbid=172190
These paired operations can cause tunneling on "name." delete(name)/create(name) delete(name)/rename(source, name) rename(name, newname)/create(name) rename(name, newname)/rename(source, name)
https://devblogs.microsoft.com/oldnewthing/20050715-14/?p=34923
Fixed with the help of timestamps and random numbers, let's hope it's a final fix.
For some really unobvious reason the
rename
cmd directive changes the file's creation date to... ehm... ~batch file's creation date~ the previous file's date of the same name that gets deleted at the beginning of the batch script. That must be the strangest bug I've ever encountered and something you wouldn't expect from some basic function like this.