Summary: | Refresh folder when executable bit is changed [G2X] | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Henry Huang <hhenry> | ||||
Component: | Resources | Assignee: | John Arthorne <john.arthorne> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | camle, Karice_McIntyre, kitlo, llyen, mtveety, steven.wasleski | ||||
Version: | 3.1.1 | ||||||
Target Milestone: | 3.2 M3 | ||||||
Hardware: | PC | ||||||
OS: | Linux | ||||||
See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=530209 | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Henry Huang
2005-09-20 05:53:02 EDT
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. |