Community
Participate
Working Groups
This problem exists solely on SUSE (we are testing version 9), and is locale/language independent. The problem re-occurs even if Eclipse is shut down and restarted. To re-create the problem, follow these steps: 1) Create a Simple Project (or Java Project) with the name project1. 2) In project1, create a folder (or Package, if a Java Project was created in step 1. ) called folder1. (Under Properties, the Default has "Executable" checked) 3) Under folder1, create a file called file1.txt. 4) Uncheck the "Executable" property of folder1 (which contains file1.txt). 5) In the "Package Explorer" view, double-click file1.txt. At this point, we see abnormal behavior when Eclipse produces the message "The file has been deleted from the file system. Do you want to save your changes or close the editor without saving?" 6) Click "Close". (If Save is selected, the Save cannot be successfully performed, and you get the message "Save could not be completed.") 7) Double-click file1.txt a 2nd time. (The editor produces the message resource file1.txt does not exist) 8) Restore the "Executable" property to folder1. 9) Create file1.txt again. The file cannot be created, and we get the error message "A resource already exists on disk". However, in the editor, we have the error message "Resource file1.txt does not exist". The end result is that a file with the name file1.txt cannot be created in the folder again, and can never be seen again, even if Eclipse is shut down and re- started.
I have tested this on Red Hat linux and have observed similar behaviour. This is actually very close to the behaviour I would expect. On Unix file systems, the executable bit on directories specifies whether the directory contents can be listed. When that bit is cleared, Eclipse does not have permission to view the directory contents, which gives the appearance of the directory contents being deleted. However, the directory contents do still exist on disk, which is why you get an error when you try to recreate the missing file. If you refresh the directory from the Package Explorer context menu after step 8), the file will appear as normal and you will be able to edit it again. I think we could improve the user experience in Eclipse by doing the following: - After the executable bit is changed on a directory, refresh that directory. This will cause the directory's children to disappear from the Eclipse UI. - Prompt the user for confirmation when clearing the executable bit on a directory, since this has the non-obvious effect of making the directory inaccessible.
I think those are good suggestions. It can be alarming when Eclipse tells the user that the file has already been deleted, without giving the user a warning beforehand! And then, Eclipse doesn't inform the user how to recover that file! Simple as the problem might be from a technical standpoint, it could be disastrous from a user standpoint.
Another observation: If the affected folder contains 2 or more files, only the 1st file gives the "deleted file" message in the editor, after the file is double-clicked in the Package Explorer. However, when a 2nd file is double-clicked in the Package Explorer, there is instead a black rectangle (the gnome terminal) that momentarily flashes outside of Eclipse. At the same time, the SUSE linux terminal produces a Gdk-CRITICAL message, file gdkgc.c line 464. Double-clicking on the 1st file also produces the black rectangle, unless the editor view (which contains the "deleted file" error message) is deleted, at which point that file disappears from the Package Explorer view.
I have entered bug 110186 against the UI suggesting that they prompt when the user tries to change the executable bit. I will keep this bug in core for the change of refreshing the folder when the executable bit is changed. I also removed "G2X" from the bug title because I have no idea what that means.
Just an explanation of what "G2X" means: It means "Group2 language-Remaining locales". I normally use tag such as G2X to label the test we are running. The tag also helps search for all bugs related to this test later on.
Ok, this seems unrelated to languages or locales, but I have added the tag back.
Created attachment 27417 [details] Turkish characters in UTF code
Downgrading severity since this is not a major loss of function. Although I can think of no reason why someone would want to clear the executable bit on a directory, the workaround is to refresh the folder manually after doing so. We'll look into improving this behaviour in 3.2 by doing a refresh automatically in this case.
Also note this bug is not related to NL. Comment #7 was attached to the wrong bug report.
Fixed. We now refresh the folder when the executable bit is changed on all platforms that support the executable bit.
Hi John, Is there any new build for bug verification? Thanks. Regards, Jacqueline
The fix will be in I20051025 and greater.
