Community
Participate
Working Groups
Build Identifier: I20100608-0911 I am working for a while with eclipse, and I notice that when I edit file and saves them eclipse changes these file permission to rw for user only. i googled it and search in forums and didn't find a way to fix it, nor in the prefrences in eclipse i work with perlEPIC on CVS Centos 5.4 with sun-jdk Reproducible: Always Steps to Reproduce: 1.edit a file 2.save 3.check the permission's on that file again. it shows -rw------- .
>1.edit a file With which kind of editor? Is the file shared with CVS? If so, are you using Watch/Edit? Does it also happen for an unshared file using the (default) text editor?
It happens on perl epic editor and it happened before with aptanta on HTML editing. Tried with default text editor and it didn't reproduced on non share file. I am working with CVS, the file are shared with CVS I use CVS without Watch/Edit
>Tried with default text editor and it didn't reproduced on non share file. How about a shard file & Text Editor?
shared file with default text editor changes the permission to -rwx------ on my case
>shared file with default text editor changes the permission to -rwx------ on my >case - can you tell us how you get the shared file (check out from CVS)? - what's the permission before you start to open the file? - does the file permission change on save or even already when you start to type?
-can you tell us how you get the shared file (check out from CVS)? cvs checkout <module> once and then cvs -w up -A -d -P - what's the permission before you start to open the file? the permissions are different each time, some were 644 , some 464, and others 775 i guess it is the same for other permission types - does the file permission change on save or even already when you start to type? only on save. opened and untouched files have the original permissions
Not sure if it's related but please note that some of the methods modifying resource attributes are not symmetric. For example calling Resource.setReadOnly(true) on Unix clears write permission for user, group and others whereas Resource.setReadOnly(false) only sets it for user. Finer granularity attributes access has been added on bug 297228 but method Resource.setReadOnly(boolean) didn't change the behavior.
>cvs checkout <module> once >and then >cvs -w up -A -d -P So, you are not using the Eclipse CVS client to check out the stuff but you then edit it via Eclipse?
Shouldn't the permissions be the same directly after check out to a new location? AFAIK CVS does not store (and then restore) the permissions.
my company is small and we work on one branch so the checkout was done once outside. I then started to work with eclipse. I updated and commited via eclipse but encountered the permissions issue so next time I updated outside eclipse in order to stay with the company standard flags. I wish I could do it all from eclipse (of course...)
I see. But you do use the standard Eclipse CVS team client?
I use the standard eclipse CVS team client
I have the feeling that this bug corresponds to the issue I am having, although that only refers to cvs update, not file save. Since 3.6, if you do a cvs update, the file permissions of all files that are updated change to -rwx------, no matter what they were and no matter what file permissions the files on the cvs server have. Prior to 3.6 there was no problem. reproducible: always. Version: Helios Release Build id: 20100617-1415 The issue is also reported on http://www.eclipse.org/forums/index.php?t=msg&goto=543210& It is annoying, because e.g. a webserver can't read the files anymore, unless you chmod them manually after each cvs update.
In the case above, described in Comment 13, the file permission issue can be solved by enabling this workspace preference: Team->When editing file in non-shared projects, automatically make files writable if prompting is not possible If this feature were documented, or if a prompt had been displayed asking whether we want user-only permission on cvs-updated files in the first place, this would have saved some time and effort. Please document this feature (e.g.: what is a non-shared project, what is meant by 'prompting is not possible'). I think prompting 'is possible' in this case.
I am the writer from the Forum Message http://www.eclipse.org/forums/index.php?t=msg&goto=543210 I use OpenSUSE Linux and Eclipse for PHP Developers Version: Helios Release Build id: 20100617-1415 > Team->When editing file in non-shared projects, automatically make files > writable if prompting is not possible I have make a test with the workspace preference above. It has not solved the problem. File Permission in Repository -r--r--r-- 1 germund cvs 2468 28. Jun 15:52 BorderContainer-01.html,v File Permission before test -rw-r--r-- 1 germund germund 1884 12. Sep 09:57 BorderContainer-01.html Make change on File in another workspace and commit with linux cvs client. File Permission after Team Syncronize... / Update -rw------- 1 germund germund 1883 12. Sep 10:25 BorderContainer-01.html
I have a similar problem I reported at bug #259643 (but noone seems to care about it): I just checked 3.6.1 and it is even worse than 3.5, it now removes read permission of group/others. here is how to reproduce (I used a fresh installation of eclipce classic 3.6.1): I created a new project, and shared it into a CVS repository. I enabled watch/edit in the new project's properties/CVS panel. I created a new file called test.sh, the new file had read permission for owner/group/others, and write permission for owner only. I granted execute permission to everyone in the file's properties panel. I checked it back, the permissions looked OK. I committed the new file into CVS. All the group and other permissions are gone (only owner read and execute remained).
I have this problem too. I am using Eclipse PDT (20100617-1415 in Ubuntu 10.04 64-bits). I get my files from a CVS server using the built-in CVS in Eclipse. When I commit, most commited files have their permissions changed to -rwx------, only readable/writable by me. The suggested option mentioned in a previous comment ("When editing file in non-shared object, automatically make files writable if prompting is not possible") is enabled in Eclipse but it does not prevent the problem. My CVS server is a Linux server. After some tests, I found that only those files with CSV keywords (I use $ Id $ in most files) get their permissions changed. However, not all files with the Id CSV keyword are affected. I found that the affected files in the CVS repository (the "filename,v" file) have execute permissions enabled like -r-xr-xr-x. I don't know why those files in the CVS repository have the exec permission enabled but if I change them to -r--r--r-- the problem goes away. I have a debug log of the CVS commits when the file permissions are changed and when the file permissions are not changed. The only difference are lines (when the file permissions are changed) like... Update-existing doc/ /home/BASE-cvs/cvsroot/innovaman2/doc/todo.txt /todo.txt/1.19/// u=rwx,g=rx,o=rx And (when the file permissions are not changed, after disabling execute permission in the repository) like... Update-existing doc/ /home/BASE-cvs/cvsroot/innovaman2/doc/todo.txt /todo.txt/1.20/// u=rw,g=r,o=r I'll attach the log file. Other notes regarding my setup: * The Eclipse workspace in a remote directory mounted using SSHFS (options rw, nosuid, nodev, max_read=65536, user=mvaldez). * The CVS repository has been used by both Windows and Linux CVS clients in the past. * Both the client and the server are 64-bits Linux (server is Slackware, client is Ubuntu). I don't know if this information may help somebody to figure out what is the problem. Thanks in advance. Mvaldez
Created attachment 182546 [details] CVS log Eclipse CVS log when the file permissions are changed and when they are not, on the same files.
I've got the same pb. On every CVS update, the updated or merged files are rw---- into my file system. version: eclipse 3.6.1 on Debian
@MValdez Thanks. Your logfile helped me fix the problem at my company. As I read from various sources, the correct permissions on all ,v files in the repository should be -r--r--r--. For some obscure reason, many of the ,v files in our repository had a plethora of different permissions. Once I reset all ,v files to -r--r--r--, the problem described in this bug ceased to occur. Still, it remains curious that the commandline CVS client left the permissions of local files unchanged when committing/updating, while Eclipse reset the permissions to -rwx------. It's definitely undesirable behavior.
I use Eclipse IDE for Java Developers Version: Helios Service Release 1 Build id: 20100917-0705 but I do not use CVS. I believe it is not a problem of CVS. When I create a new class the new file is created with umask 600. When I save an existing file, with umask 640, the umask is not changed by eclipse. The same behavior is when I build my project. All the files (property files or image files) which are copied by eclipse to the class directory have 600 as umask. The class files which are created by the the eclipse compiler are created with the correct umask.
This is not a CVS problem. I see the same problems in an unmanged project also. In fact the group and other permission resetting is happening when ever Eclipse is updating any of the resource attributes. The typical scenarios are making a file writable (when the user try to edit a read only file) or renaming a file. I am working on the fix and will attach my proposed patch soon.
I tracked down the problem. The group and other permissions are getting resetted when ever some resource attribute updatation is happening in Eclipse. The typical steps involved in resource updation are ... * get ResourceAttributes with Resource.getResourceAttributes() * change ResourceAttributes as required * update ResourceAttributes with Resource.setResourceAttributes(ResourceAttributes attributes) Here Resource.getResourceAttributes() is using org.eclipse.core.internal.utils.FileUtil.fileInfoToAttributes(IFileInfo fileInfo) to get the attributes, which has the following code ..., public static ResourceAttributes fileInfoToAttributes(IFileInfo fileInfo) { ResourceAttributes attributes = new ResourceAttributes(); attributes.setReadOnly(fileInfo.getAttribute(EFS.ATTRIBUTE_READ_ONLY)); attributes.setArchive(fileInfo.getAttribute(EFS.ATTRIBUTE_ARCHIVE)); attributes.setExecutable(fileInfo.getAttribute(EFS.ATTRIBUTE_EXECUTABLE)); attributes.setHidden(fileInfo.getAttribute(EFS.ATTRIBUTE_HIDDEN)); attributes.setSymbolicLink(fileInfo.getAttribute(EFS.ATTRIBUTE_SYMLINK)); return attributes; } From this code, it's clear that it's only getting the Owner related resource attributes and ignoring the Group and Other permission attributes. Because of this, when Resource.setAttributes() is called with these attributes, we are loosing the Group and Other related permissions. To fix this issue, Here I am attaching the patch which contains the below changes ... * Update org.eclipse.core.resources.ResourceAttributes to store Group and Other related permissions. * Update org.eclipse.core.internal.utils.FileUtil.fileInfoToAttributes(IFileInfo fileInfo) to get Group and Other related permissions along with Owner permissions and populate all of them in the ResourceAttributes object. * Add tests to org.eclipse.core.tests.resources.ResourceAttributeTest to test the new methods. Please go thorough the patch and let me know your opinion.
Created attachment 190250 [details] Proposed Patch to fix this bug. The description about this patch is there in my latest comment in the bug. Please go through the patch and let me know your opinion.
Thank you very much for fixing this issue, this bug is the reason I could not upgrade to eclipse 3.6. Will this fix be included in 3.7M6?
(In reply to comment #25) > Thank you very much for fixing this issue Please note that this bug's status is still 'NEW' and not 'RESOLVED'.
(In reply to comment #26) > (In reply to comment #25) > > Thank you very much for fixing this issue > > Please note that this bug's status is still 'NEW' and not 'RESOLVED'. well, you're right. Let me say then I really appreciate the effort that has been put into this issue ;)
> Target Milestone: 3.7 Szymon, I'm not sure if you've realized that the proposed patch adds API in ResourceAttributes. Releasing it for M6 would avoid having to apply for an API change exception in M7.
Hi Szymon, Can you please go through the patch and let me know if you want any modifications to it. If the patch is fine, can you please take it forward to include it in the next release. My team is blocked on this bug and I want it to be included the earliest release possible. Please let me know if I need to do something from my side to get this fix submitted soon. Thanks, Thirumal.
(In reply to comment #28) > > Target Milestone: 3.7 > > Szymon, I'm not sure if you've realized that the proposed patch adds API in > ResourceAttributes. Releasing it for M6 would avoid having to apply for an API > change exception in M7. Thanks Markus for the heads up. I think that new methods in ResourcesAtributes does not have to end up as new API. Even if we decide to make them API, I would prefer to ask for a PMC approval during M7 instead of adding this API now in haste. BTW, I think that instead of many methods for setting attributes, we could have general set/get(attributes) methods in ResourceAttributes like in IFileInfo.
Created attachment 191743 [details] The fix with no API changes
I modified the fix so it does not contain API changes now. It is released to HEAD. Thanks Thirumal.
*** Bug 323946 has been marked as a duplicate of this bug. ***
*** Bug 334334 has been marked as a duplicate of this bug. ***
Am I reading this correctly ?! It won't be fixed for 3.6 ? Don't you think changing files permissions in an IDE is not important and central enough to be a critical urgent fix ? Am I missing something ? All I can see is that Eclipse 3.6 can't do basics and won't be fixed. I just can't believe it. And there is a fix. And without API change. What's the blocker for backporting to Helios and release a hotfix or something ? It's a critical bug, my tean can't work correctly with Eclipse 3.6. My boss wants me to investigate switching costs for adopting Netbeans because of this.
(In reply to comment #35) > > It's a critical bug, my tean can't work correctly with Eclipse 3.6. > My boss wants me to investigate switching costs for adopting Netbeans > because of this. While this doesn't address most of your post (deliberately), if you are analyzing costs/benefits you can create your own quick fix for deploying this fix within your company relatively easily, and probably at a lower cost (a "Help>Install New Software" by your developers) than a complete IDE switch. Let me know. PW
(In reply to comment #36) If the issue is just backporting the fix to 3.6, you could just create a quick fix and deploy it in your company as Paul said. I can backport the fix to 3.6.2+, so you can easily build a fixed bundle from the repo.
Paul, I agree but a backport isn't as cheap as you might think. We don't have in-house knowledge of the Eclipse code base and build process. I then need to dedicated skilled resources to the elaboration of a patch. On the other hand, dedicating a trainee to configure every workstation one by one will be cheaper, or so will think my boss. Now, if there already is patch available and you point me out a page explaining the build process, that would help. I could then try to convince my boss. And it's the way I'd prefer really (I am not interested in switching). Genuinely asking, I'm not familiar with eclipse processes, issuing a 2.6.3 release is so hard to do ? I might be overreacting it really feels like a big basic bug. Or am I hitting a corner case ? Frankly I'm puzzled here. Anyway, thanks for the responsiveness.
(In reply to comment #38) > Paul, I agree but a backport isn't as cheap as you might think. We don't have > in-house knowledge of the Eclipse code base and build process. I then need to > dedicated skilled resources to the elaboration of a patch. This is just my opinion: Nothing is free. But the cost of building a feature patch (which you can do from your eclipse, especially if the patch is already provided configured for eclipse 3.6.2) cannot be the same as switching every dev's IDE ... no matter which direction you go (to eclipse or to netbeans). And, that's why we offer to help with these kind of things. > Now, if there already is patch available Szymon offered to provide this. > and you point me out a page explaining > the build process, that would help. I could then try to convince my boss. And > it's the way I'd prefer really (I am not interested in switching). We can provide the steps for your hotfix if you decide to go that way. They will involve checking out org.eclipse.core.resources (File>Import...>Plug-ins and Fragments can get you the specific version you need for free), applying the patch, creating a feature patch project, and then using File>Export...>Deployable Features. It will create a p2 site that can be fed into all of the devs' eclipse in a variety of ways. > Genuinely asking, I'm not familiar with eclipse processes, issuing a 2.6.3 > release is so hard to do ? I might be overreacting it really feels like a big > basic bug. Or am I hitting a corner case ? Frankly I'm puzzled here. This is as I understand it: This is not something that we would spin up another maintenance release, that would probably only be considered for something like "eclipse doesn't work on windows 7 at all". There is a large cost associated with any release, and our project provides one release at a time (3.6.0, 3.6.1, 3.6.2, 3.7.0, 3.7.1, etc). To pick up a fix, our policy has always been move to the latest eclipse, even picking up the milestone/integration builds of the latest release depending on how important the fix is for their workflows. PW
I am wondering: does the fix write the file first, then applies a second IO operation to change its attributes or everything happens in a single IO operation where eclipse asks to create a file under the specific file permissions? Cause if we re not on the 2nd case, we 'll actually be ignoring the user's umask (a user could had a read-only umask, but creating a file and then trying to change its attributes wouldn't fail cause umask controls only initial file creation, not further changes through chmod) and that might not be a good idea. Cause from a user's point of view it's a single operation - creating a new file, which under unix's laws should follow umask... Note that in order to delete/overwrite a file, on a unix system, we don't need write permissions but the file's ownership. A file like that: -r--r--r-- 1 testuser testgroup 8 2011-04-01 18:41 testfile is totally deletable for the user "testuser". Write permissions are only needed if we need to modify a file.
I think this fix ultimately depends on the finer grained permission support from bug 297228
Hi there, I have an up to date version of Eclippse PHP running windows 7 x64 The files are on a network drive and (seemingly) at random points the files become unwritable and I have to request for their permissions to change. If I open notepad I don't have write issues. I am told that the file permissions keep changing but I cannot find a way to stop this. This bug seems like it's relevant but it's two years old. I did see there was a patch but I don't know how to apply it. Searching for patches and eclippse only comes up with creating patches for projects created in eclippse. Any help would be most greatly appreciated. Thanks
(In reply to comment #42) Please file a new bug, with steps to reproduce it, against Eclipse PHP. They should check whether it's a PHP specific issue. If not, they can move to Platform Resources for further investigations.
