Re: rename("symlink-to-dir/", "name") behavior

2008-02-22 Thread Jim Meyering
Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 2/22/2008 6:09 AM: > |> I wonder if we would have much luck proposing a patch to the Linux kernel > |> folks to do just that? > | > | Do you see another errno symbol name that makes sense? > | I think that ENOTDIR makes the most

Re: rename("symlink-to-dir/", "name") behavior

2008-02-22 Thread James Youngman
On Fri, Feb 22, 2008 at 1:09 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > Do you see another errno symbol name that makes sense? ENOTSUP? James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: rename("symlink-to-dir/", "name") behavior

2008-02-22 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 2/22/2008 6:09 AM: |> I wonder if we would have much luck proposing a patch to the Linux kernel |> folks to do just that? | | Do you see another errno symbol name that makes sense? | I think that ENOTDIR makes the most sen

Re: rename("symlink-to-dir/", "name") behavior

2008-02-22 Thread Jim Meyering
Eric Blake <[EMAIL PROTECTED]> wrote: > I wrote the aardvark along those lines, and it was rejected in yesterday's > meeting of the Austin Group. They argued that Linux is allowed to fail to > follow symlink-to-dir/ in the rename and rmdir case, but only if it > returns a different errno than ENOT

Re: rename("symlink-to-dir/", "name") behavior

2008-02-22 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 1/28/2008 6:28 AM: | According to Geoff Clare on 1/28/2008 2:57 AM: | |> | |> My strict reading of the current wording in draft 4 does not permit | Linux' | |> behavior (even though it is more useful, in my opinion), since t

Re: rename("symlink-to-dir/", "name") behavior

2008-01-28 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Geoff Clare on 1/28/2008 2:57 AM: |> |> My strict reading of the current wording in draft 4 does not permit Linux' |> behavior (even though it is more useful, in my opinion), since the |> trailing slash on B/ means that the old argument n

rename("symlink-to-dir/", "name") behavior

2008-01-26 Thread Eric Blake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I know that draft 4 added some clarification on rename(2) (and mv(1)) behavior on path resolution. However, there is still an ambiguous situation, which I don't see documented, and I would like some consensus before writing an aardvark. This issue w