Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #314439 +++ Build ID: Eclipse 3.6rc2 on Linux-GTK-RHEL-4 Noticed when running the RSE unittests as per bug 314439, IFileStore#delete() does not behave as expected in the following scenario: mkdir nonAccessible touch nonAccessible/noperm.txt chmod 0 nonAccessible new FileStore("nonAccessible/noperm.txt").delete(EFS.NONE, null); according to IFileStore#delete() Javadocs, deletion occurs with "best effort semantics" and throws an exception when deletion was not successful. That is, the client should expect that if no exception is thrown, the file to delete is gone. In the concrete case, this fails because both java.io.File#exists() as well as the native UnixFileNatives#fetchFileInfo() do not distinguish between "file does not exist" and "there was an error returning file status". As a result, the non-accessible file in the example above, which is expected to return an error trying to get file status, is treated as non-existing. And the delete() method returns success without throwing an error.
Created attachment 169979 [details] patch v1 Attached is a quick-and-dirty initial patch (tested on Linux RHEL4) to illustrate the concept. The problem is that when getting file status, an ENOENT errno (which indicates file-does-not-exist) must be treated differently than other kind of errno (which indicates permission error, or I/O error). The patch ensures that fetchInfo() throws a CoreException in case of permission or I/O error. The errno is embedded into the exception text. I did not want to further expose errno codes outside native code, since they may be system dependent. Note that this patch makes the native EFS implementation behave slightly different than the java.io.File based implementation -- simply because in java.io.File I do not see any chance detecting I/O error or permission error. The java.io.File#exists() just returns false when there is a permission error. It might be possible to adjust the IFileStore#delete() API description in order to align with the java.io.File behavior -- but I personally think that it's better to fix the native implementation and live with java.io.File being not perfect (actually, weakening the API desc to say "...may..." might be an option).
(In reply to comment #0) Correction: The error occurs when the folder is READABLE but not WRITABLE and not EXECUTABLE: > mkdir nonAccessible > touch nonAccessible/noperm.txt chmod a-wx nonAccessible > new FileStore("nonAccessible/noperm.txt").delete(EFS.NONE, null);
Hi Martin, Could you also attach the mentioned test, so we could add it to the Resources test suite. Thanks.
The test as-is requires the RSE Infrastructure. I don't have time at the moment to create a test that runs on core/resources only. Can we defer this for now?
(In reply to comment #4) > The test as-is requires the RSE Infrastructure. I don't have time at the moment > to create a test that runs on core/resources only. Can we defer this for now? I understand that this is a 3.7 issue. Then no hurry.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
