Hi,
We've got some Java projects that are being developed on both Unix and
NT and we're struggling with JBuilder 2.0 and its "File has been
externally updated, reload buffers?" messages. Has anyone found a fix?
Is it a bug in JBuilder? i.e should I save my hair and not spend any
more time investigating/trying to fix this problem?
More info:
Our NT machines access files from Unix using Samba (1.9.18) shares.
We're using TimeServ on NT to ensure that time is synchronised with the
Unix fileserver.
A simple way of reproducing the problem is:
1) From Unix, touch all the files associated with a Java project.
2) From NT, load the project into JBuilder, and the "reload buffers"
message often appears immediately for several files (seemingly at
random).
3)Answering yes, doing a save all, exiting, then restarting JBuilder is
to no avail. The messages just reappear on startup.
The only workaround (of sorts) we've found is:
Use Windows Explorer to move the project directory elsewhere and then
copy it back to its original position, then reload the project into
JBuilder.
Some time ago, Ray Burns <burns@mmsi.com> wrote:
Re: How to stop "File has been externally updated, reload buffers?"?
> What I think is going wrong
> ----------------------------
>
> Since Unix filesystems are easily capable of storing dates with an
odd
> number of seconds (the FAT file system isn't, I don't know about
NTFS),
> for 50% of the files, the NT and DOS date formats will result in
different
> numbers.
>
> My guess is that JBuilder is making one call requesting the DOS date
> format and another requesting the date in NT format, then comparing
> the two. This would result in two different dates for the same file,
and
> hence the "File has been externally modified, reload buffers?"
> bug.
>
> Another possibility is that JBuilder is always using NT calls which
> request the full NT format, but one of the calls generates the
> SMBgetattrE request which truncates the last bit of the seconds
> value, so even though NT is returning the value in 100ns units
> the precision is only to the nearest 2 seconds. Of course the NT
> call which uses SMBtrans2-findfirst always gets exactly the
> right value, so they don't match.
Samba provides various configuration options to alleviate timestamp (and
granularity) problems (some specifically to solve similar problems with
Visual Studio). I've tried experimenting with
dos filetimes
dos filetime resolution
fake directory create times
share modes
but with no success.
Thanks for any help!