Re: [SourceJammer-devel] Argh I hate SJ and DST!

[Robert M. <rob...@ya...>]

Here's a discussion of a remarkably similar problem in an Eclipse bug submission:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=5337

The upshot is that the culprit is FAT 32. Marc, is it possible that you're file system is
formatted to use FAT 32, as opposed to NTFS?

--Rob


--- Robert MacGrogan <rob...@ya...> wrote:
> Somehow Yahoo ate my first attempt to answer this message.
> 
> I delved into the SJ code to find where's it's doing this date comparison. Here's what it does:
> 
> 1) Info about the local file is stored in the .source.jam file when you add, check in, check
> out,
> or get the file. 
> 
> 2) The date that is stored comes from getting the lastModified() value from the java.io.File
> object. This value is actually a long, not a Date. I assume it is equivelent to Date.getTime().
> 
> 3) When the local/remote sync color is set, the current properties of the local file are
> compared
> to the stored values. SJ gets lastModified() again and compares this to the stored
> lastModified()
> value. If they are not equal, you get the out-of-sync color.
> 
> You would not think that the lastModified() value of a file would change just because you go
> into
> or out of DST. Why would it? The real question, of course, is how should SJ be comparing these
> values to avoid this problem? Any ideas?
> 
> --Rob
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com