X2.55 Synchronize panes too critical

[JRz]

Nikos,

Discovered a problem with synchronizing panes (F9). Sometimes the modified timestamp on a file gets shifted by 2 seconds. This is a known 'feature' of windows (actually: it's a FAT/NTFS issue; the same Fat/NTFS anomalies as we saw with daylight saving time).

The Synchronize Panes function is mislead by this difference and reports new files based on this two second difference. It seems you've got different files but they are the same none the less.

Some programs let you specify to ignore such two second differences. I'd like this to be an option in X2 as well.

The problem simply cannot be avoided because on a FAT file system the modified timestamps are less accurate than on NTFS (resolution is about 2 seconds for FAT and 10 milliseconds for NTFS !). So this will happen whenever you shift files around from and to FAT/NTFS partitions.

For reference see the article from MSDN (under Remark) :

http://msdn.microsoft.com/library/defau ... letime.asp

[fgagnon]

oooh, good research (and/or extra-keen awareness)
That explains the many mysterious small time diff's I've seen with copied/reorganized files between drives & machines.

& I second the motion about maiking x2 be able to ignore 2-second time differences when comparing files.

[JRz]

oooh, good research (and/or extra-keen awareness)

I like to be thorough if I can. Never like it myself when a user comes to me stating only: 'it doesn't work!'

And maybe by giving Nikos a little nudge in the right direction gets me the option more quickly, no??

[nikos]

i thought i had that covered already!
what are the 2 drives in question? (any floppies/networks)

[JRz]

i thought i had that covered already!
what are the 2 drives in question? (any floppies/networks)

Sorry, forgot to mention that And it's even the fun part

Both folders were on the same local NTFS drive!! I'll give you the full story. Some of it may be relevant, I couldn't say, so here it is:

- Using Visual Source Safe I got the latest version of a project (name it 'set A') to a local NTFS drive
- archived the project from VSS to an NTFS network drive (all files compressed in one file, maybe that's where the 'FAT-like' timestamps are introduced??)
- restored the archive in another VSS database
- again got the latest version and put that on the same local NTFS drive in a different folder ('set B')

Now some files show the 2 second shift in the modified timestamp on set B (2 seconds newer than those in set A)

I suspect the timestamps get rounded off to the nearest 2 second interval available at some point (the smallest granularity on FAT file systems). Not all files show the effect because some have timestamps which nicely fit into the 2 second intervals I presume.

What puzzles me is where this shift is introduced. I think it might be in the way M$ has implemented the VSS algorithms, but then again, wouldn't you expect to get the same results from this algorithm every time (expecially since both VSS databases are on the same drive on the server and the local files are also on the same drive).

I hope this clarifies something. It's got me puzzled

If you need more info let me know....

[nikos]

i'm sure there's a perfect explanation, if we were to follow each step of the state-space map of VSS and bill gates' head

but now i understand why the problem is caused in x2
when x2 compares folders, one of which is on NTFS and the other is e.g. a floppy, then it accepts differences up to 2 seconds as "identical". When both folders are NTFS, then it uses a stricter "perfect match only" approach. There's the problem!

perhaps i should just compare everything with the +/- 2 second rule active

[JRz]

perhaps i should just compare everything with the +/- 2 second rule active

Yes you should, because the +/- 2 second differences will show up also when you copy a file from NTFS to FAT and back again (This is what caused it in my case, although somewhat obscured by the fact that no direct FAT filesystem was visited in the process )

I'm glad my explanation helped