I am trying to create a file backup, but only want to overwrite files that have changed
How can i do this without using FSO ?
Printable View
I am trying to create a file backup, but only want to overwrite files that have changed
How can i do this without using FSO ?
This is what the Archive attribute was for.
XXCOPY TECHNICAL BULLETIN #06 offers one explanation.
The best way would be to generate a checksum value for each file, then check the checksum against the current file's checksum and see if they match...if not, they've changed.
Dilettante's suggestion, while the standard method, is open to outside intervention...meaning that some files might not be backed up when you run your backup code.
And regarding checksums (in case you need to ask), anything will do...CRC32 is usually what people use and more than enough, but MD5 is the best option...and there's free functions out there for calculating both :-)
Thanks guys found this little function that seems to do what i need:
Code:Public Function FileUpToDate(sPath As String, sDest As String) As Boolean
Dim a, b, c As Variant
FileUpToDate = Len(Dir$(sPath)) > 0
If FileUpToDate = False Then Exit Function
'Already False if not exist so just exit
'Here is where I need more code to compare file Tmie/Dates
a = FileDateTime(sPath)
b = FileDateTime(sDest)
c = DateDiff("s", a, b)
If c < 0 Then FileUpToDate = False Else FileUpToDate = True
End Function
The code you found will work, and won't need you to keep any data about each file, but my suggestion's still the best :-)
LOL! :bigyello:Quote:
Originally Posted by smUX
Why your suggestion's still the best while other way works and "won't need you to keep any data about each file"?:confused:
1) The archive bit of a file is not limited to the one program, any can change itQuote:
Originally Posted by anhn
2) The date is not a 100% reliable way of checking which file is the newer...all it takes is a clock to be wrong somewhere and it ruins the whole thing
3) Checksum is the only 100% reliable way of checking to see if a file has changed...although the date *may* be considered reliable enough as the likelihood of it going wrong is low
No way is 100% reliable.
Not everyone can change "the archive bit" of a file.
If everyone can change it then it is no longer 100% reliable.
If "although the date *may* be considered reliable enough as the likelihood of it going wrong is low" then why not use that?
Respect your "professinal way of using CRC" but you should not say "but my suggestion's still the best". I will never use that "best" suggestion.
It's the best because it's the most reliable, and yes it is the closest to 100% reliable (as you said, nothing is 100% reliable, there is a chance of two CRCs being the same, but there's more chance of me winning the lottery every week without ever playing even once :-)) but it does have the overhead of having to store the CRC data for each file which may be too much of an overhead :-)
It's your choice to "never use that best suggestion", just as it's my choice to suggest it :-P