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 7375

Summary: Editor does not refresh properly when the status of a file changed
Product: platform Reporter: Sophie Deng <sdeng>
Component: -- Other --Assignee: Sophie Deng <sdeng>
Status: CLOSED FIXED    
Severity: major CC: jtulach, markdey, rmatous, sdeng
Priority: P2    
Version: 3.x   
Hardware: Other   
OS: Other   
Issue Type: DEFECT Exception Reporter:

Description Sophie Deng 2000-08-13 19:08:01 UTC 
Editor refresh is not done properly when a file is changed outside of IDE.
I am implementing a filesystem module where each action to the file will
either changes the time stamp and/or the content of a file outside of IDE.
I expect Editor will refresh/reload accordingly when a file is changed but it
does not seem to be the case. Sometimes a "file is changed externally" dialog
pops up, sometimes it does not. Sometimes the "lock" method is called, and
sometimes it isn't. Furthermore I am not able to come out a pattern/rule of
when the above behavior will occur. I don't know if this is actually a problem
in Editor or in filesystem. Note that the refresh always works in Explorer,
because my action always fires the fileChanged event to ensure a refresh of the
file, however it does not help refreshing the Editor. This is a critical bug
for my module.
Comment 1 Jesse Glick 2000-08-14 11:08:59 UTC 
I don't know the details, but have you consulted FileEvent.isExpected and
confirmed that your filesystem fires events with this flag set appropriately?
Comment 2 Sophie Deng 2000-08-14 23:58:59 UTC 
It is working better on build1077. But I still see problems in some cases. It
seems like a performance issue. The refresh works if I do not execute my actions
one after one immediately. In the case that if the time stamp changes but the
content does not, the refresh problem occurs all the time. In such a case, it
usually works if I take a 7 or 8 seconds break before I executing the action.
Comment 3 Jaroslav Tulach 2000-08-22 15:57:59 UTC 
Sophie, I think the problem is in file
http://www.netbeans.org/source/browse/~checkout~/openide/src/org/openide/filesys
tems/AbstractFileObject.java?rev=1.34.8.2.2.1&content-type=text/plain

Please search for "500ms" to get to the right line.

I tried to remove the < 5000, but it does not work either (it thinks that the
file has been modified even it was not). So I do not know what to do.

1. we probably have to leave such code there with constant XXX where 0 < XXX <=
5000
2. can you please try to modify the code and play with this constant to see if
this is the real source of problems (I guess so, because you claim that after
six seconds everything works fine) and find out some acceptable value for it?

Please let me know about the result and also if you have any ideas, they are
welcomed, because I do not know what to do with it.
Comment 4 Jaroslav Tulach 2000-08-29 14:35:59 UTC 
Sophie suggested to change the constant to 1500ms. Seems to work.
Comment 5 Sophie Deng 2000-09-09 00:49:59 UTC 
The bug is fixed on Windows, but still in Linux.
Comment 6 Jaroslav Tulach 2000-10-13 08:43:59 UTC 
I have investigated the problem and it is caused by the filesystem
implementation returning different times from method lastModified(). Why it does
so (even the file is not modified) - I do not know.

But the solution should be to check the implementation of
AbstractFileSystem.Info.lastModified () method.

There is not too many things we could do with this bug in core/openide =>
marking fixed. ok?
Comment 7 Sophie Deng 2000-10-26 00:03:59 UTC 
> Some more findings: I used two cases, one work, the other does not to
> try to find out the difference btw them.
>
> Case 1:
>  - Check out a file if it is not already CheckedOut.
>  - Change the file
>  - Save the file (via Editor popup "Save" menu")
>  - Check in the file
>
> Case 2:
>  - Check out a file if it is not already CheckedOut.
>  - Change the file
>  - Check in the file
>
> Case 1 works fine, but Case 2 does not refresh. The only difference
> is that there is no explicitly Save done for Case 2. Note that
> MyAction programatically save the file before a checkin is performed.
> I have verified that the file does get save and
> CloneableEditorSupport.saveDocument is called. And the time stamps of the
> file does get changed, the original time stamp is eariler than the
> new time stamp.

To answer your question, the reason that MyFileSystem.lastModified()
method returns two different date is because "save()" is performed
(if the save cookie exists, save is perform using SaveCookie.save() method)
before the checkin is performed. That is the MyAction actually
changes the time stamp of the file twice, one when saving the file,
the other after file is checked in. What we are trying to do is to
save the file for the users before check in a file so that no data
will be lost. Why does the time stamp can only be changed once
within one action?
BTW, I verified if the file is not changed, the lastModified method
returns the same date. Furthermore, if I removed the save(), Editor
refreshs fine.
Comment 8 Jesse Glick 2000-12-05 15:48:59 UTC 
Who owns this bug now?
Comment 9 Jan Zajicek 2001-05-21 13:01:20 UTC 
Do you observe still the bug behaviour? Is this fixed, or waiting for some
patch? Please update status of this bug, thanks.
Comment 10 Sophie Deng 2001-05-24 20:20:33 UTC 
Looks like the bug has been fixed in Nb3.2.
Comment 11 Quality Engineering 2003-07-01 16:19:53 UTC 
Resolved for 3.4.x or earlier, no new info since then -> closing.