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 <[EMAIL PROTECTED]> 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 ------------------------------------------------------- This SF.net email is sponsored by Demarc: A global provider of Threat Management Solutions. Download our HomeAdmin security software for free today! http://www.demarc.com/info/Sentarus/hamr30 _______________________________________________ SourceJammer-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sourcejammer-devel
