Created attachment 5713 [details]
Patch on org.netbeans.modules.vcscore.VcsAction.java revision 1.64

Well, the patch is O.K., but I wonder why is it needed?

1) Why it is a problem, that there is an attempt to save read-only
files? They are read-only, thus can not be modified. When they are not
modified there is no attempt to save them. Can you please describe the
conditions when the problem arise?

2)  the lock() method in VcsFileSystem.java 
    may conclude that a file is not writable, while the EDIT 
    command is still busy making the file writable...
Yes, I'm not sure I can block the lock() method for a long time.
Execution of the EDIT command may take a lot of time. Thus currently
lock() keeps failing as long as the file is not writable. Maybe we
should assure, that the EDIT command will be executed just once and
not in every attempt to call lock().

Downgrading to P3, it does not have a destructive impact.

Please elaborate more on what situation/testcase cause a problem.
Thanks.

The situation is this:
We have a DataObject that is modified, and an attempt is 
done to write the associated FileObject.  At that time the 
file is still read-only.

The EDIT command attempts to save the read-only files 
prior to execution, which results in a loop causing a 
stack overflow.
This happens as follows:
The attempt to write the FileObject triggers a call to the 
lock() method of the VcsFileSystem. This, in turn, 
triggers the execution of the EDIT command, by means of a 
call to VcsAction.doEdit().  This method first tries to 
save the file. This results (for our DataObject) the 
FileObject to be saved. This triggers a call to the lock() 
method on the file system, triggering execution of the 
EDIT command, and so on, until we get a stack overflow.

With regard to 'blocking' the lock() call: doesn't the code
in my proposed patch just do that?
And if the EDIT command's effect would be to make the file 
writable, then for that file it will only be executed on 
the first call to lock(). This makes sure that for 
subsequent calls to lock() the EDIT command is no longer 
executed.

I apologize for my ignorance, but how can read-only file get modified
? I probably don't get something obvious here ... :-)

It is not the read-only file that is modified. What *is* 
modified is the DataObjectthat is associated with the 
file. That DataObject has a SaveCookie; the SaveCookie 
takes care of writing to the FileObject.

O.K. now I get it. Thanks for the description. I will test, whether
the blocking of lock() for a long time will not cause any problems in
the IDE and integrate the patch.

I was now in attepmt to commit your patch, but I was curius why there
was already the code, that waited for the command to finish. And I've
found version 1.11 of VcsAction, where the code was commented with the
message "Do not wait for EDIT command to finish, since it leads to
deadlock."

I've fixed the first part of the issue - there will be no attempt to
save the file before the Edit command.

I'll fix the second part later, the lock() method should remember all
running EDIT and LOCK commands and do not execute them if one is
already running for the given file. It will NOT wait for them to
finish. This should not cause any problems.

Fixed in dev build on Jun 5.
VcsFileSystem.lock() method remembers all running EDIT and LOCK
commands and takes care of not executing a command if one is already
running for the given file.

Reopening, since this behavior is not really solving the original
problem. The problem is, that you want to write to a file, but it's
read-only. The EDIT command gets executed, but lock() doesn't wait for
it and you get the IOException. But you don't know, that the command
finish after some time and you can write then.

So, I can implement the blocking lock(), that's not a problem, but I'm
afraid of consequences it may have on the rest of the system. This
behavior caused some deadlock in the past, but unfortunately I do not
have the thread dump. Thus I'll implement the blocking lock() and test
it as much as possible to verify, that it does not cause any problems.

Set target milestone to TBD

Fix of this is not so trivial and will need further investigation. So
rescheduling to future.

Since this blocks issue #31913, I'm increasing the priority.
The fix is not hard. After the fix of issue #31643 the deadlock I was
worry about should not occur.

So, I'm going to fix it in the main trunk...

The bug is fixed in the main trunk:

/cvs/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v 
<--  VcsFileSystem.java
new revision: 1.217; previous revision: 1.216

The FileObject.lock() and UserQuestionException.confirmed() will wait
till the command that change the writable state finish.

Created attachment 9635 [details]
The contextual diff, that fix this problem.

Created attachment 9637 [details]
The binary patch. Copy to <NB-install>/modules/autoload/patches/org-netbeans-modules-vcscore/ folder.

Created attachment 9701 [details]
Full Thread Dump on 1 CPU kernel

Oupsss:-\
Please, ignore my previous attachment/comment !!!
______________________________________________________________________
... it would had come to different issue #31913 :-(
Sorry for confusing you

should we consider fixing this for 3.5?  It's P2 but filed before the
cut-off day

Probably yes. This is also necessary for fix of issue #31913.
I'll attach text and binary patch...

Well, the diffs & patch is already there, I've overlooked them.
So see the attachments above.

The patch is OK and solves our issue.

approved for 3.5

Thanks for the review and approval. The problem is fixed in release35
branch:

/cvs/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v 
<--  VcsFileSystem.java
new revision: 1.207.2.8; previous revision: 1.207.2.7

I see this as fixed and verify it. If you Frank encounter the problem
again, reopen the bug with further elaboration. Verified in Sun ONE
Studio 5.0 Standard Edition build #030528.