Bug 47430 - the immutable bit is copied from the original resource to the ouput directory
Summary: the immutable bit is copied from the original resource to the ouput directory
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.0   Edit
Hardware: Macintosh Mac OS X - Carbon (unsup.)
: P3 normal (vote)
Target Milestone: 3.0 M7   Edit
Assignee: Kent Johnson CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2003-11-25 11:10 EST by Pieter Verhaeghe CLA
Modified: 2004-02-11 12:24 EST (History)
2 users (show)

See Also:

Attachments
Patch against org.eclipse.jdt.core v_396 (2.03 KB, patch)
2003-12-25 14:35 EST, Boris Pruessmann CLA 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Pieter Verhaeghe CLA 2003-11-25 11:10:35 EST 
eclipse version: 3.0M5

This behaviour is introduced by the fix of bug #41056.

When a resource file is locked (i.e., the immutable bit is set) in the source folder, then the 
immutable bit is also set in te output folder. So, a rebuild of the project fails, since it can't clean 
the output folder.

If you use the Perforce SCM, then all files that are not open for edit, have the immutable bit set, so 
all non *.java resources in the source directory that are not 'open for edit' have this problem.

commenting line 157 of the file plugins/org.eclipse.core.resources.macosx/src/core.c (source 
distribution of M5) solves the problem.
(Maybe a more general solution is to make always all files in the output folder not readonly)
Comment 1 Andre Weinand CLA 2003-11-26 13:06:33 EST 
I will look into the problem...
Comment 2 Andre Weinand CLA 2003-12-02 05:49:16 EST 
Hmmh, this looks like an ugly problem...

I don't think we should change the behavior of CoreFileSystemLibrary.internalCopyAttributes to 
ignore the immutable bit. This would break the semantics of internalCopyAttributes. In addition, 
when copying a readonly file with Unix "cp", the native behavior is to preserve the readonly state. 
So I don't see why Eclipse should clear the readonly bit when copying files.

On the other hand I understand that the current behavior is unsatifactory:
- you checkout a resource file -> Perforce makes it readonly
- you build -> the readonly file is copied to the out folder and its readonly state is preserved
- you start to edit the file -> the readonly bit is cleared on the source side
- you trigger another build -> the file is copied but the copy fails because the destination is still 
readonly.

May be the build can better handle this situation since it understands why the copy fails (or could 
clear the readonly bit first).

In any case, a workaround would be to use a post build Ant script to clear the readonly state on 
resource files.

John, any comments?
Comment 3 John Arthorne CLA 2003-12-04 10:53:46 EST 
I agree that preserving permission bits for the generic copy command is
desirable.  It sounds like the java builder should call
IResource.setReadOnly(false) wherever they are currently calling
IResource.setDerived(true).
Comment 4 Boris Pruessmann CLA 2003-12-25 14:35:19 EST 
Created attachment 7275 [details]
Patch against org.eclipse.jdt.core v_396

Got a little annoyed by the problem... 

Patch adds setReadOnly calls to all places where JDT calls setDerived (as
suggested) on a copied resource. Also verified that problem with Perforce is
gone.
Comment 5 Boris Pruessmann CLA 2004-01-20 09:39:44 EST 
Any news on this bug? It totally prevents usage of Eclipse on MacOS in combination with Perforce...
Comment 6 Philipe Mulet CLA 2004-01-20 09:48:43 EST 
Ok will schedule it for M7.
Comment 7 Philipe Mulet CLA 2004-01-20 09:49:15 EST 
Kent, if simple enough, we may consider it for 2.1 stream as well.
Comment 8 Kent Johnson CLA 2004-01-26 14:46:54 EST 
Now set any copied resource to NOT readOnly.
Comment 9 David Audel CLA 2004-02-11 12:24:39 EST 
Verified for 3.0M7