Bug 314448

Summary: [efs] deleting a file inside a non-readable non-executable folder fails without exception
Product: [Eclipse Project] Platform Reporter: Martin Oberhuber <mober.at+eclipse>
Component: ResourcesAssignee: Platform-Resources-Inbox <platform-resources-inbox>
Status: NEW --- QA Contact:
Severity: normal    
Priority: P3 CC: Szymon.Brandys
Version: 3.6   
Target Milestone: ---   
Hardware: PC   
OS: Linux   
Whiteboard:
Bug Depends on:    
Bug Blocks: 314439    
Attachments:
Description Flags
patch v1 none

Description Martin Oberhuber CLA 2010-05-26 08:42:34 EDT 
+++ 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.
Comment 1 Martin Oberhuber CLA 2010-05-26 08:51:13 EDT 
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).
Comment 2 Martin Oberhuber CLA 2010-05-26 09:03:22 EDT 
(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);
Comment 3 Szymon Brandys CLA 2010-05-26 09:09:34 EDT 
Hi Martin,
Could you also attach the mentioned test, so we could add it to the Resources test suite. Thanks.
Comment 4 Martin Oberhuber CLA 2010-05-26 13:18:45 EDT 
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?
Comment 5 Szymon Brandys CLA 2010-05-27 03:54:00 EDT 
(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.
Comment 6 Eclipse Webmaster CLA 2019-09-06 16:11:27 EDT 
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.