Community
Participate
Working Groups
all files generated in the .processed folder (preprocessor enabled) are readonly (-r--r--r--). Therefore, cleaning the project does not work since MacOSX (probably linux too) does not let you delete readonly files. So if you want to clean a project you have to go to the commandline and sudo "rm -rf .processed" in order to make the project compile again. I hope that this is a simple fix but it would greatly improve my efficiency. thanks - Rainer
I believe the problem is in PreprocessorBuilder.java in method private void writeProcessedResults(final IResource resource, byte[] contents, IProgressMonitor monitor) throws CoreException { ... outputFile.setCharset("UTF-8", monitor); outputFile.setDerived(true); --> setReadOnly(outputFile, true); I am not sure what the motivation for making the file readonly is (probably only Craig knows that), but it causes problems on MacOS.
Hi Rainer, i believe that files generated in the .processed folder are made read-only so the user cannot directly edit the preprocessed code leading to inconsistencies in the generated .class files. Maybe the best solution to fix this issue in MacOSX and Linux, is not generating read-write files, but add a contributor to the clean action that can remove this generated files in the .processed folder. We'll have to investigate this issue and discuss the best approach. Craig, do you have any suggestion?
To make sure I understand the circumstances... this is when you invoke the "Clean Project..." action?
yes, the problem occurs when you try to clean the project. While I can theoretically see the point in trying to prevent the users from messing with these files, I am not sure if it matters really since usually dirs starting with a . are hidden anyway. I have changed the mentioned line to make it read/write and that fixes the problem. But another solution would be to catch the exception in the clean step, make the file writeable and then delete it again (something like a forceDelete).
Actually, the builders that are part of MTJ get a callback method explicitly for a clean operation. It would be a simple matter of running through the folder hierarchy at that point to remove the read-only attribute. Given that the file names are the same as the unprocessed files, I think it is well worthwhile keeping them read-only by default.
I think this is a good solution, keep the preprocessed file read-only and do sth in PreprocessorBuilder.clean(). But another problem is: can the preprocess project be deleted sucessfully in MacOSX? I don't have the environment to test it. (In reply to comment #5) > Actually, the builders that are part of MTJ get a callback method explicitly > for a clean operation. It would be a simple matter of running through the > folder hierarchy at that point to remove the read-only attribute. > Given that the file names are the same as the unprocessed files, I think it is > well worthwhile keeping them read-only by default.
I would assume if the first thing that is done is to set the files and folders to read/write mode that it should be possible to delete on any platform. I have a Mac and can test changes.
FYI: I just filed bug 254444: "IResource#move(..) and #delete(..) fail on locked files on the Mac".
Hello everyone, I will take a look on this issue, and will submit a patch with this issue solved.
Created attachment 119968 [details] Patch with bug resolution Hello everyone, I finally got the time to fix this issue. Follows the patch with the resolution. [], David Marques
This solution looks solid to me. I don't have an up to date workspace at the moment to do the commit of the changes.
I can commit the patch if you have revised it. (In reply to comment #11) > This solution looks solid to me. I don't have an up to date workspace at the > moment to do the commit of the changes. >
i'm working on that :) gep (In reply to comment #12) > I can commit the patch if you have revised it. > > (In reply to comment #11) > > This solution looks solid to me. I don't have an up to date workspace at the > > moment to do the commit of the changes. > > >
Comment on attachment 119968 [details] Patch with bug resolution code reviewed and commited to svn
done.
bug released into 0.9.1
0.9.1 fixes this instance of the problem however, I still have a problem when I am updating from SVN and the file was removed on the server. In this case it looks as if Eclipse tries to delete the preprocessed file which does not work due to the same reason as the initial bug. I still think that making these files readonly in the first place does more harm than good (at least on macos). Usually the .processed folder is anyway hidden which should be hint enough for people to not mess with these files. My configuration: Eclipse 3.4.1 MTJ 0.9.1
david, who worked on the previous patch, is on vacation. once he is back i will ask him to take a look at this. :) gep (In reply to comment #17) > 0.9.1 fixes this instance of the problem however, I still have a problem when I > am updating from SVN and the file was removed on the server. In this case it > looks as if Eclipse tries to delete the preprocessed file which does not work > due to the same reason as the initial bug. > > I still think that making these files readonly in the first place does more > harm than good (at least on macos). Usually the .processed folder is anyway > hidden which should be hint enough for people to not mess with these files. > > My configuration: > Eclipse 3.4.1 > MTJ 0.9.1 >
Read-only files should not have anything to do with SVN. These files should be (used to be) marked as "Derived" in Eclipse and should never have been checked into SVN in the first place. The .processed directory is not something that should ever end up in source control. The question is whether we are no longer correctly marking these files as derived or if source control was done outside of Eclipse? If source control was handled outside of Eclipse, this is no longer something that we can do anything about. I don't believe that we should be switching these to read-write files and believe we have solved the root problem in the last round of development.
I fear there is a misunderstanding. Imagine I have a source file src/myclass.java (which is checked into svn) and the preprocessor generates .processed/myclass.java. The arc file is thenk deleted by someone else. As I update from svn and the src file is deleted eclipse tries to delete .processed/myclass.java. This fails due to the same permission problem. Similarily, if I refactor/rename myclass.java to myotherclass.java, the deletion of the old processed file fails. Hope that clarifies the issue.
Ups, my iPhone autocorrection caught me. The "arc" file should obviously mean "src" file. Furthermore I hope that it is obvious that the .processed folder is not checked into svn. Btw I use subversive with svnkit (both latest versions) but I don think that this really matters.
I'm moving it to a feature release.
change to wontfix for different reasons: no headcount to do it, no applicable anymore or could not find a good solution to do it
close wontfix bugs
