This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 59265 - Detection of externallyModified is not correct
Summary: Detection of externallyModified is not correct
Status: RESOLVED INVALID
Alias: None
Product: platform
Classification: Unclassified
Component: Text (show other bugs)
Version: 4.x
Hardware: PC Windows XP
: P3 blocker (vote)
Assignee: Petr Nejedly
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-05-26 03:53 UTC by ericarseneau
Modified: 2008-12-22 17:51 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ericarseneau 2005-05-26 03:53:22 UTC
CloneableEditorSupport has a timestamp that should not be set the way it is.
There are problems with the way the detection of externally modified is done.
The lastSaveTime is not correct, especially considering it is set using the
System.currentTimeMillis() in some cases.  There should be a fileTimestamp or
something.  What SHOULD be done is, grab the time stamp of the file when the
document is read, prior to saving get the timestamp of the file at that point
and compare the two.  If same then ok, if not same then externally modified.  Or
on some kind of refresh action compare the time stamp of the file with the one
saved here.  The KEY is not to modify the timestamp fetched unless the value
came from the file not from anything computed here.
Comment 1 Martin Roskanin 2005-05-30 09:43:00 UTC
Reassigning to openide
Comment 2 Petr Nejedly 2005-05-30 12:54:56 UTC
First, please try to describe what problem it cases.
The scheme, as implemented now, works OK for several years and both  correctly
reports external modification, does automatic background reload for clean
buffers and so on.
Comment 3 ericarseneau 2005-07-30 23:12:08 UTC
It turns out the issue was that I had two listeners registered on a document and
the state between the two listeners was causing changes to document at same
time, which was not intended.

I have fixed the problem on my end, and now the problem is gone.

There was a separate issue logged to indicate that there was a deadlock issue
when this type of thing happens, but its a separate bug.

Apologies for pointing finger in wrong direction.