TR : DOSFS unlink problem

Pavel Pisa ppisa4lists at pikron.com
Fri Nov 26 12:50:50 UTC 2004


On Thursday 25 November 2004 19:45, Etienne Fortin wrote:
> Hi Thomas,
> Maybe sometimes I should look at the mailing list archive before jumping
> to asking yet another question :) RTFM as they say :)
>
> Anyway, looking at unlink.c:unlink(), I find it strange to have to look
> at the parent directory of of the directory containing the file we want
> to unlink. Only the parent directory of the file should be looked at.
> This way, the call to rtems_filesystem_evaluate_parent() of the parent
> dir of the file to unlink seems unecessary. Looks like too much
> indirection. But I don't quite completely understand what is going on so
> I may be totally wrong.
>
> For now I just commented out the call to
> rtems_filesystem_evaluate_parent() (thank god RTEMS is open source!!!)
> until a solution is found.
>
> Etienne

Hello all,

I have only some thoughts about unlink for future considerations.
As I understand, the actual state is:
Unlink searches for path leaf node (file)
and then evaluates parent of that file. It checks
that parent is writtable and then requests unlink for file.
This approach could lead to important problems in longer perspective.
The unlink in the Posix sense does not work on leaf node (file)
level, it should unlink last path element from the directory tree.
Actual implementation would probably lead to incorrect results
for filesystems supporting multiple paths to one file (hard links)
and symbolic links.

Example:

/a/b/file1_name1      real file with data
/a/c/file1_name2      link -> /a/b/file1_name1

unlink(/a/c/file1_name2)
lookup inode of "file1". 
Lookup partent of file 1 ("/a/b").
Delete (/a/b/file1_name1).

This is far from the correct behavior.

My feeling is, that correct implementation should work
next way.

unlink(/a/c/file1_name2)
split path to directory part ("/a/c") and last path element ("file1_name2").
Lookup "/a/c" path. 
Ask VFS to unlink name ("file1_name2") from inode corresponding
to "/a/c" path.

The second approach helps for DOSFS problem, but in many other cases too.
There is not unambiguous or even any projection from file inode to its
parent on many filesystems. 

Best wishes 


                Pavel Pisa
        e-mail: pisa at cmp.felk.cvut.cz
        www:    http://cmp.felk.cvut.cz/~pisa
        work:   http://www.pikron.com



More information about the users mailing list