Hello, I'm new user of FreeFileSync. But I have a problem. I create a notepad
file "Test.txt". It looks like this:
[404, Invalid URL: http://www.il.pw.edu.pl/~s199513/test.jpg]
When I syncronise this file using FreeFileSync to the other directory, it copy
that file, but with different date (very strage date 2026). It looks like
this:
[404, Invalid URL: http://www.il.pw.edu.pl/~s199513/test1.jpg]
Can anyone knows what's wrong? Is that normal?
I have a Windows 7 32 bit. The date and time in system is correct.
Problem with date of file
- Posts: 3
- Joined: 2 Jul 2011
-
- Site Admin
- Posts: 7279
- Joined: 9 Dec 2007
FFS encodes additional information into a FAT/FAT32 file creation time in
order to solve daylight saving time and time zone problems. See
helpfile->daylight saving time.
order to solve daylight saving time and time zone problems. See
helpfile->daylight saving time.
- Posts: 3
- Joined: 2 Jul 2011
Yes, OK. I understand that there may be 1 hour difference or some time zone
problems. But there is 25 year difference :) It is very long time. And how can
I solve this problem? Now I'm trying to format the pen drive to NTFS file
system maybe it will help.
problems. But there is 25 year difference :) It is very long time. And how can
I solve this problem? Now I'm trying to format the pen drive to NTFS file
system maybe it will help.
- Posts: 3
- Joined: 2 Jul 2011
Sorry 15 year difference ;)
-
- Site Admin
- Posts: 7279
- Joined: 9 Dec 2007
> format the pen drive to NTFS
This will definitively help! All DST and timezone issues are due to an age-old
design mistake in the FAT specification. Simply not using FAT is probably the
best solution. The second option, is to keep using FAT and rely on FFS
handling this problem. The price is that it overwrites file creation time, but
at least the DST/time-zone issue will be gone.
This will definitively help! All DST and timezone issues are due to an age-old
design mistake in the FAT specification. Simply not using FAT is probably the
best solution. The second option, is to keep using FAT and rely on FFS
handling this problem. The price is that it overwrites file creation time, but
at least the DST/time-zone issue will be gone.
-
- Posts: 71
- Joined: 22 May 2006
I know that this is a very old topic but I was going crazy!! Now I know that
it's FFS fault for this creation-date-in-the-future problem!
Actually you are changing the CRT date on the "original" file too, and this
is not acceptable... :-(
Almost one year ago I was very happy to have found FFS as a replacement for
SyncToy, but know I must starting again looking for something else: I dont
like the new "grid" and this creation-date change is definitely driving me to
put FFS into the trashbin... I'm very sad this...
it's FFS fault for this creation-date-in-the-future problem!
Actually you are changing the CRT date on the "original" file too, and this
is not acceptable... :-(
Almost one year ago I was very happy to have found FFS as a replacement for
SyncToy, but know I must starting again looking for something else: I dont
like the new "grid" and this creation-date change is definitely driving me to
put FFS into the trashbin... I'm very sad this...
-
- Posts: 71
- Joined: 22 May 2006
Btw, do not tell me to format on NTFS: there are objects like smartphones that
cannot use NTFS on their storage!!!
cannot use NTFS on their storage!!!
-
- Site Admin
- Posts: 7279
- Joined: 9 Dec 2007
Sometimes something's got to give. The creation time is not relevant for
synchronization, and usually not even relevant for the user, since it does not
state when the data was created, but merely when the file carrying the data
was created.
See also:
[404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=3431083&group_id=234430&atid=1093083]
synchronization, and usually not even relevant for the user, since it does not
state when the data was created, but merely when the file carrying the data
was created.
See also:
[404, Invalid URL: https://sourceforge.net/tracker/?func=detail&aid=3431083&group_id=234430&atid=1093083]
-
- Posts: 71
- Joined: 22 May 2006
I have added my point of view on the link above, I know that you will never do
anything about the "new grid" and this CreationDate being modified but I will
keep asking for it... hoping that more people will complain about this logic.
Which is the latest version not changing the creation time, v3.3? I want to
fall back to that version...
anything about the "new grid" and this CreationDate being modified but I will
keep asking for it... hoping that more people will complain about this logic.
Which is the latest version not changing the creation time, v3.3? I want to
fall back to that version...
-
- Site Admin
- Posts: 7279
- Joined: 9 Dec 2007
I would have closed the ticket long ago if I considered the topic final. But I
understand your rant, I try to take something from it, but it would be much
more useful if it were constructive.
Anyway, design decisions are complex and it takes a few iterations to get
everything right.
Can't say much about the daylight saving time handling. According to changelog
it seems to be 3.14... but this version is really old.
understand your rant, I try to take something from it, but it would be much
more useful if it were constructive.
Anyway, design decisions are complex and it takes a few iterations to get
everything right.
Can't say much about the daylight saving time handling. According to changelog
it seems to be 3.14... but this version is really old.
-
- Posts: 71
- Joined: 22 May 2006
Well, you'right... I was a "bit" rude... but I really hate when a program is
changing my files without advising me so that I can take a decision! I
understand that you did it "for us" trying to solve a well known bug in the
FAT definitions (a bug that will obviously never be solved by Microsoft...)
but I still believe that your solutions is not the best one.
You already have a DB, right now only for "automatic" sync, I think that's the
best place to put these metadata for FAT/Fat32 sources! Here viewtopic.php?t=1822 you wrote
that using the DB for all sync types would be easy... :-) You may starting
with always using the DB! ...and then moving the metadata there... :-)))
PS: possibly with a v4.7... so to have the old grid... ;-)
Ciao!
changing my files without advising me so that I can take a decision! I
understand that you did it "for us" trying to solve a well known bug in the
FAT definitions (a bug that will obviously never be solved by Microsoft...)
but I still believe that your solutions is not the best one.
You already have a DB, right now only for "automatic" sync, I think that's the
best place to put these metadata for FAT/Fat32 sources! Here viewtopic.php?t=1822 you wrote
that using the DB for all sync types would be easy... :-) You may starting
with always using the DB! ...and then moving the metadata there... :-)))
PS: possibly with a v4.7... so to have the old grid... ;-)
Ciao!
-
- Site Admin
- Posts: 7279
- Joined: 9 Dec 2007
> starting with always using the DB!
Ha, people using "mirror" mode would hate me for that! ;) The DST problem is a
good example of a problem that can only be solved at another (lower) level. At
the application layer there is just no way to know whether a file time
reported by the OS is "correct" or not.
Ha, people using "mirror" mode would hate me for that! ;) The DST problem is a
good example of a problem that can only be solved at another (lower) level. At
the application layer there is just no way to know whether a file time
reported by the OS is "correct" or not.
-
- Posts: 71
- Joined: 22 May 2006
> people using "mirror" mode would hate me for that! ;)
...why... :-) They will have the move handling as a bonus! :-)
> At the application layer there is just no way to know whether a file time
reported by the OS is "correct"
I must admit that my programming time was too much long ago (...on RPG so not
dealing with these low-level problems... :-), and I may be wrong: if you
save on the DB the Source's FS (like if it's FAT or not), the Source
Creation Time, a flag DST active on record creation, wouldn't them let
you handle DST change at sync time?
...why... :-) They will have the move handling as a bonus! :-)
> At the application layer there is just no way to know whether a file time
reported by the OS is "correct"
I must admit that my programming time was too much long ago (...on RPG so not
dealing with these low-level problems... :-), and I may be wrong: if you
save on the DB the Source's FS (like if it's FAT or not), the Source
Creation Time, a flag DST active on record creation, wouldn't them let
you handle DST change at sync time?
-
- Site Admin
- Posts: 7279
- Joined: 9 Dec 2007
This is similar to what is happening right now, i.e. FFS saves the local<->UTC
time offset of modification time at the time of first comparison but stores it
in the "creation time" as kind of a hack. This doesn't solve the original
problem, namely "get correct modification time", but the weaker and sufficient
problem "keep times stable across sync sessions". Drawback of the DB file
compared to the hack is that it's not attached to indiviudal files: Doesn't
cover renaming or sync'ing a sub- or parent folder of base sync dirs. As I
said, the problem is not simple, even if it looks like it. There are a number
of subtleties that are easy to overlook.
Offering an option and letting the user decide is capitulation. I'm not there
yet ;)
time offset of modification time at the time of first comparison but stores it
in the "creation time" as kind of a hack. This doesn't solve the original
problem, namely "get correct modification time", but the weaker and sufficient
problem "keep times stable across sync sessions". Drawback of the DB file
compared to the hack is that it's not attached to indiviudal files: Doesn't
cover renaming or sync'ing a sub- or parent folder of base sync dirs. As I
said, the problem is not simple, even if it looks like it. There are a number
of subtleties that are easy to overlook.
Offering an option and letting the user decide is capitulation. I'm not there
yet ;)
-
- Posts: 71
- Joined: 22 May 2006
> Doesn't cover renaming or sync'ing a sub- or parent folder of base sync dirs
...that's something I wasn't thinking... :-(
How much space do you need for the metadata? I know that the following can
be really dangerous... :-) ...but...
I gave a look at the Directory entry definition on https://en.wikipedia.org/wiki/Fat32%23FAT32 looking for
an unused byte and seems that there are a few spare bits at offset 0x0C: if
I have understood it correctly MS is using only bits 3 and 4...
:-)
...that's something I wasn't thinking... :-(
How much space do you need for the metadata? I know that the following can
be really dangerous... :-) ...but...
I gave a look at the Directory entry definition on https://en.wikipedia.org/wiki/Fat32%23FAT32 looking for
an unused byte and seems that there are a few spare bits at offset 0x0C: if
I have understood it correctly MS is using only bits 3 and 4...
:-)
-
- Site Admin
- Posts: 7279
- Joined: 9 Dec 2007
I need 1 bit as an indicator that additional data is available, 7 bits to
store the UTC<->local offset and as much additional bits as possible as a hash
of modification time. Currently I'm using the complete range of 38 usable bits
of creation time.
This works quite nicely, with a few minor pathological cases of non-FAT
volumes pretending to be FAT or conversely FAT pretending to be NTFS.
store the UTC<->local offset and as much additional bits as possible as a hash
of modification time. Currently I'm using the complete range of 38 usable bits
of creation time.
This works quite nicely, with a few minor pathological cases of non-FAT
volumes pretending to be FAT or conversely FAT pretending to be NTFS.
- Posts: 3
- Joined: 8 Nov 2012
I wish I had known this issue before I backed up my Seagate External drive to my Morespace External. It changed the folder created date, hence all the file dates in every file I synced to a year 2052. This may not matter to most people but I do photography and I must manually alter the date on each file I submit for editorial purposes, included the created date to be accurate. I verified that this does not happen with snyctoy, which when I use it to sync a couple of files to the folder I previously synced with Sync toy only alters the date on the files it touches, not the entire folder (too bad as it sets it to the proper created date) being the day it was created or backed up. Unusual date tags anywhere will cause a company not to use an editorial image as they feel it may mean the exif was altered and you have to prove your information is correct.
My network "IT" sons feel it is a code error where the software reads the date code in a different order (month/day/year or day/month/year) then reading the digits in the wrong order and then changing the date to how the software reads it. It only happens on the created date with the software is making it's own new date... should be fixable. Both my drives are NTFS btw.
My network "IT" sons feel it is a code error where the software reads the date code in a different order (month/day/year or day/month/year) then reading the digits in the wrong order and then changing the date to how the software reads it. It only happens on the created date with the software is making it's own new date... should be fixable. Both my drives are NTFS btw.
-
- Site Admin
- Posts: 7279
- Joined: 9 Dec 2007
>Both my drives are NTFS btw
In this case the problems discussed in this thread are unrelated. Unless you happened to use FAT unknowingly.
In this case the problems discussed in this thread are unrelated. Unless you happened to use FAT unknowingly.
- Posts: 3
- Joined: 8 Nov 2012
LOL - I just rechecked my drives, and I must have read the properties on the same drive when I checked last time... the Morespace is indeed FAt 32.. Still would love the issue solved (. See below for a fix of the dates if you need one. Sorry to say they were both ntfs.
nope, i checked both are formatted in ntfs. I've sent in to support. Maybe they have an answer, but it is the exact issue for how it's showing.
Every file in folders I synced (added files only not the entire folder) were changed to 2/19/2052 8:09:52 AM. That's the creation date showing on all photos in the synced folder on my morespace drive, they show correct on the original folder 5/6/2010 3:44:48 PM created date on the Seagate drive. This happened to folders on both drives as I synced some files going from the morespace to the Seagate.
The Morespace I take with me on the road and when I have files I worked on the road I sync new files only to the Seagate drive. The seagate drive is permanently on my home desktop and when I alter any files I back it to my morespace one a week or so so I have copies. This is for my photos files mainly.
As I mentioned and one of the earlier fellows mentions, this changes the created date of ever photo in the folder I moved a couple files to, not just the 4 files that were added to the folder.
nope, i checked both are formatted in ntfs. I've sent in to support. Maybe they have an answer, but it is the exact issue for how it's showing.
Every file in folders I synced (added files only not the entire folder) were changed to 2/19/2052 8:09:52 AM. That's the creation date showing on all photos in the synced folder on my morespace drive, they show correct on the original folder 5/6/2010 3:44:48 PM created date on the Seagate drive. This happened to folders on both drives as I synced some files going from the morespace to the Seagate.
The Morespace I take with me on the road and when I have files I worked on the road I sync new files only to the Seagate drive. The seagate drive is permanently on my home desktop and when I alter any files I back it to my morespace one a week or so so I have copies. This is for my photos files mainly.
As I mentioned and one of the earlier fellows mentions, this changes the created date of ever photo in the folder I moved a couple files to, not just the 4 files that were added to the folder.
- Posts: 3
- Joined: 8 Nov 2012
For anyone that just wants a very fast easy way to change the date back to the true back up day this nifty little program does it quick (or alters a batch of exif dates you maybe didn't change the time on your camera when travelling etc). You can choose what dates you want to change (created, modified, etc) and pull all files you want changed in and do it in 1 second.
And don't trust me, i ran my own checks, maleware checker and virus scanned, on the file before opening but it was all good.
http://www.nirsoft.net/utils/bulk_file_changer.html
(scroll to the bottom and download the Download BulkFileChanger (in Zip file) only, you don't want the download manager and stuff advertised at the top of the page)
Careful it does try to get you to install other
And don't trust me, i ran my own checks, maleware checker and virus scanned, on the file before opening but it was all good.
http://www.nirsoft.net/utils/bulk_file_changer.html
(scroll to the bottom and download the Download BulkFileChanger (in Zip file) only, you don't want the download manager and stuff advertised at the top of the page)
Careful it does try to get you to install other
