bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: readlink(1) behavior


From: Jim Meyering
Subject: Re: readlink(1) behavior
Date: Wed, 23 Sep 2009 16:36:35 +0200

Eric Blake wrote:

> According to Eric Blake on 9/18/2009 5:35 AM:
>> On one hand:
>>
>> ln -s dangling link => 0
>> stat dangling/ => ENOENT
>> stat link/ => ENOENT
>> mkdir link/ => 0
>
> Creating a directory through a slashed symlink works on Solaris 10, and is
> required by POSIX, but it fails on Linux with EEXIST (in other words,
> Linux ignores the trailing slash).  Unlike the rmdir counterpart (where it
> is nice that Linux does NOT follow the slashed symlink to remove the dir,
> leaving a dangling symlink), this seems like a case where the Solaris
> behavior is nicer.  At any rate, now that readlink -f claims that both
> missing/ and symlink-to-missing/ can resolve, would it make sense to
> change mkdir(1) to guarantee that 'mkdir symlink-to-missing/' obeys POSIX
> and creates missing instead of complaining that symlink-to-missing exists?
>  Should I do this via a mkdir(2) wrapper in POSIX (wrapping both mkdir and
> mkdirat because Linux does not comply), or just in coreutils?

This does not seem to be important enough to merit penalizing
all Linux-based uses of mkdir, so maybe just mkdir(1), to start with?
Ideally, someone would get the fix into the kernel, and *then*
we'd do the right thing in gnulib, and that would penalize only older
Linux kernels.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]