Delphi overwrite file and wrong modified date time

Question

I'd like to get a file last modified time in Delphi.

Normally something like FileAge() would do the trick, only the problem is: if I overwrite *File A* with File B using CopyFile, File A's modified date is not updated with current overwrite time as it should(?)

I get that: CopyFile also copy file attributes, but I really need to get the modified date that also works when a file is overwritten.

Is there such function? My whole application relies on modification time to decide whether or not I should proceed with files!

---

EDIT Just to clarify: I'm only monitoring the files. It's not my application who's modifying them.

Mufi

don't use CopyFile,delete file A and create file B again. – Secessionist

I would use Windows Shell way with using of SHFileOperation. – Burbot

I can't, I'm only monitoring the files. It's not me who's modifying them, but I still need to track changes :( – Mufi

What does the create time returns for overwritten files? – Kyleekylen

Your question edit is then against the initial question. So you're just monitoring files and once you detect file change, you want to change the file's modified date ? – Burbot

@TheVedge: I tried that: creation date is only good when creating a file, not overwriting it – Mufi

@TLama: No, I want to get the modified file's date, not change it – Mufi

Now I see. You're trying to monitor changes based on the modified date/time value and some foreign app uses CopyFile which doesn't update this value. This way is not safe if you're going to monitor changes by that. Imagine, that I can modify just this date/time in my file manager without actually changing the file content. In that case your application might be mislead by that. – Burbot

@TLama: Exactly yes. I explained the reason why I chose this approach here, I'm hoping to be able to have both the ability to catch large changes and reliably get the modification time at the same time. – Mufi

@TheVedge CreateTime get's totally wrong in this case -> support.microsoft.com/kb/172190/en-us (btw still the same with W7) – Franconian

Answer 1

The documentation for CopyFile says:

File attributes for the existing file are copied to the new file.

Which means that you cannot use base your program on the last modified attribute of the file, or indeed any attribute of the file. Indeed there are all sorts of ways for the last modified attribute of the file to change. It can in fact go backwards in time.

Instead I suggest that you use ReadDirectoryChangesW to keep track of modifications. That will allow you to receive notifications whenever a file is modified. You can write your program in an event based manner based on the ReadDirectoryChangesW API.

If you can't use ReadDirectoryChangesW and the file attributes, then you'll have to base your decisions on the contents of the file.

Satisfactory

Yes, I'm well aware of that and I specifically mentioned it in my question. I also do use ReadDirectoryChangesW (nice catch), but this doesn't scale: if a user is copying (or overwriting) a large folder (1000s files), the only way to catch all changes is to scan the folder itself instead of dealing with files one by one. That's why I was/am relying on the file modification to catch changes in the event of a large change. – Mufi

Overwriting a folder containing 1000 files is not an extreme/unusual case. I have to handle this! – Mufi

I don't know what you mean when you say that ReadDirectoryChangesW does not scale. If you would rather carry on using the last modified attribute, as you seem to indicate in that comment, then I don't really see the point of the question. – Satisfactory

According to my tests ReadDirectoryChangesW will not catch every change if a user is overwriting a large folder containing 1000s files, that's what I meant by scaling. – Mufi

Of course no I don't want to keep using the last modified attribute since clearly it's not reliable at all, but I do want to rely on something that can track (relatively) large changes, thus my question. – Mufi

@Mufi If you have problems with ReadDirectoryChanges then you should ask about that (and post some code too) – Franconian

@SirRufo: I don't have issues with ReadDirectoryChanges, I actually use it just fine, I just said that using it to track individual files doesn't scale. That's why I relied on file modification date attribute, which lead me to the issue that I discovered, thus my question if there's a reliable way to get file modified time – Mufi

@Mufi I think ReadDirectoryChanges is flaky for network volumes when connections may be lost. But I don't see why it can't work reliably for large volumes of files. – Satisfactory

@DavidHeffernan: Regarding ReadDirectoryChangesW, if there are too many changes in a short period of time (which inevitably happen if you overwrite a folder containing a lot of files, for instance), I start getting ERROR_NOTIFY_ENUM_DIR (which means: A notify change request is being completed and the information is not being returned in the caller's buffer. The caller now needs to enumerate the files to find the changes). In my experience, too many change notifications not dealt with fast enough leads to this. – Mufi

As I said, using ReadDirectoryChangesW to track folder changes and scanning the modified folders is immune to the problem above, but now I see that I can't rely on file modification attribute either, which brings me back to square one :( – Mufi

I'm still reading this article (which also link to this post) that mention Change Journal, I'm still reading this, but for anyone being in the same situation (ie. ReadDirectoryChangesW lost notifications), this may help – Mufi

OK, I posted a question about change journal (which probably is the way to go to avoid the file modif. mess), if anyone can help, please share the wisdom! – Mufi