File Modified Attribute: Trustworthy?
Author
Can the File/Folder "Last Modified" date attribute be changed programatically?
This is related to this thread.
I'm writing a Backup Utility, and would like to know if it can just look at the Modified Date attribute, see if it has changed, and process that file, instead of generating a hash of the file, which means looking at all the contents of the file, which of course takes much much longer.
Quote:Original post by Prozak
Can the File/Folder "Last Modified" date attribute be changed programatically?
yep: SetFileTime
Also, copying a file only modifies it's creation time, not it's modification time unless you copy it to a UNC path (eg: \\some_machine\some_share) and it might be the same with network mapped drive.
hope that helps !
hope that helps !
Author
Quote:Original post by gumpy macdrunkenQuote:Original post by Prozak
Can the File/Folder "Last Modified" date attribute be changed programatically?
yep: SetFileTime
In that case I think I'll give the user the option between:
1 - Using a Hash table to know which files have been changed since the last backup. This method is more CPU expensive.
2 - Having a checkbox that enables the User to trust the Last Modified attribute date. This method instantly tells me when the file was last changed, but it has a resolution of 24h, meaning, if I did a backup at 8am, and then worked on the folder all day, the backup utility wouldn't store anything because the last backup still is of the same day as the changed files.
After having a second look at this I don't know if it wouldn't be more correct to implement option 1 only...
Quote:Original post by ProzakQuote:Original post by gumpy macdrunkenQuote:Original post by Prozak
Can the File/Folder "Last Modified" date attribute be changed programatically?
yep: SetFileTime
In that case I think I'll give the user the option between:
1 - Using a Hash table to know which files have been changed since the last backup. This method is more CPU expensive.
2 - Having a checkbox that enables the User to trust the Last Modified attribute date. This method instantly tells me when the file was last changed, but it has a resolution of 24h, meaning, if I did a backup at 8am, and then worked on the folder all day, the backup utility wouldn't store anything because the last backup still is of the same day as the changed files.
After having a second look at this I don't know if it wouldn't be more correct to implement option 1 only...
If you do include #2, then you could possibly check the 'archive' flag. This would mean that whenever it went to do a backup, it would first check the modified date but then also the archive flag (and if the modified date is today, but the archive flag is set, it would still backup the file).
Author
Quote:Original post by TheUnbelieverQuote:Original post by ProzakQuote:Original post by gumpy macdrunkenQuote:Original post by Prozak
Can the File/Folder "Last Modified" date attribute be changed programatically?
yep: SetFileTime
In that case I think I'll give the user the option between:
1 - Using a Hash table to know which files have been changed since the last backup. This method is more CPU expensive.
2 - Having a checkbox that enables the User to trust the Last Modified attribute date. This method instantly tells me when the file was last changed, but it has a resolution of 24h, meaning, if I did a backup at 8am, and then worked on the folder all day, the backup utility wouldn't store anything because the last backup still is of the same day as the changed files.
After having a second look at this I don't know if it wouldn't be more correct to implement option 1 only...
If you do include #2, then you could possibly check the 'archive' flag. This would mean that whenever it went to do a backup, it would first check the modified date but then also the archive flag (and if the modified date is today, but the archive flag is set, it would still backup the file).
Apparently the Archive flag is incoherent, and from what I've gathered, it's randomly turned on and off by various utilities, so relying on it for this purpose might prove hazardous. I can certainly set the Archive flag, but I'm unable to tell if third party utilities have altered it.
There's a compromise here:
If the file has been modified since the last backup, then compare it's hash to see if it's changed. That way, you can make sure that the file is really changed before you incorporate it into your archive, but you're not hashing each and every file available to you.
If the file has been modified since the last backup, then compare it's hash to see if it's changed. That way, you can make sure that the file is really changed before you incorporate it into your archive, but you're not hashing each and every file available to you.
Use 2 hashes - one taken of the last kilobyte of the file, and one taken of the whole file. When checking for modification, you only need to check the full hash if the mini hash hasn't changed. After all, why scan an entire 50MB file to find the differences if it's just a couple of lines appended at the end?
(For a little extra optimisation at virtually no development cost, you can make the hash of the part of a filetype most likely to change, eg. the first 256 bytes of an MP3 file, where the ID3 tag sits. You can even change this between versions of your software - it'll just fall back to the full hash, after all.)
Similarly, you can use the file size before your hashing - if the file size changes, you know the content's changed without having to go through the hash routine.
(For a little extra optimisation at virtually no development cost, you can make the hash of the part of a filetype most likely to change, eg. the first 256 bytes of an MP3 file, where the ID3 tag sits. You can even change this between versions of your software - it'll just fall back to the full hash, after all.)
Similarly, you can use the file size before your hashing - if the file size changes, you know the content's changed without having to go through the hash routine.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
