Re: coreutils-5.94 imminent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Phillip Susi on 2/13/2006 11:55 AM:
> Shouldn't it be made consistent? IMHO, the command "mv a b/" means move
> the file or directory named a into the directory named b, so if b does
> not exist or is not a directory, it should fail. If you want to make mv
> deviate from this behavior, then at least shouldn't it behave the same
> on all platforms, without depending on the implementation of rename()?
Read the earlier thread. The gist was that when a is a directory, and b
does not exist, you get the first synopsis form of rm(1) from POSIX,
(http://www.opengroup.org/onlinepubs/009695399/utilities/mv.html), which
states that you defer to the result of rename("a", "b/") in step 2. The
problem is that rename(2) is underspecified, so it is not obvious whether
moving a directory to a name that obviously denotes another directory
should succeed or fail; the argument was that coreutils should succeed if
the underlying system call can succeed until such time as POSIX is
improved to fully specify rename(2).
Speaking of which, consider this ambiguity in POSIX:
$ ln -s nowhere/ broken
$ mkdir /tmp/dir
$ mv -f /tmp/dir nowhere
This must succeed when . and /tmp are on different file systems (since in
step 2, rename(2) fails with EXDEV, you fall through to step 4 which
deletes the broken link before replacing it in step 5 with the directory),
but what about when . and /tmp are on the same file systems (or when
rename(2) can preserve hard links across file systems)? The POSIX rules
for rename(2) state both:
"If the old argument points to the pathname of a directory, the new
argument shall not point to the pathname of a file that is not a directory."
and
"If the new argument points to a pathname of a symbolic link, the symbolic
link shall be removed."
So which rule applies here - must rename remove the symbolic link and
replace it with the directory, or fail with ENOTDIR?
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD8dqk84KuGfSFAYARAtg+AKDBlGp/BtGuVjSSwk4Y3cHMKCPgfwCdGHEn
QQO+SlsoHPFkVao2bzZ0tVU=
=9/Fz
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-5.94 imminent
Shouldn't it be made consistent? IMHO, the command "mv a b/" means move the file or directory named a into the directory named b, so if b does not exist or is not a directory, it should fail. If you want to make mv deviate from this behavior, then at least shouldn't it behave the same on all platforms, without depending on the implementation of rename()? Jim Meyering wrote: Eric Blake <[EMAIL PROTECTED]> wrote: According to Jim Meyering on 2/9/2006 1:56 AM: I'm hoping to release coreutils-5.94 soon. If anyone sees something on the trunk that they want but that's not yet in 5.94, please speak up now. So far, my policy has been to apply only bug fixes. Whatever happened to this thread: http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00285.html Thanks for bringing that up. In spite of saying I wanted to fix it for 5.94, I decided to let it wait. The probable fix and tests seem complicated/risky enough that I'd prefer to release 5.94 now. For example, the tests will have to be dependent on how rename works, and will have to ensure that e.g., rm -rf a b; touch a; mv a b/ still fails on systems with a rename syscall that honors trailing slashes. I'd rather see such changes made to the trunk first, and get some exposure through a test release. Besides, no one volunteered to do the work ;-) The code changes are trivial. Writing tests and changing documentation will take more time. The fact that changing this part of mv induces no failure (on Linux) in the test suite is a sure indication we need more tests. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-5.94 imminent
Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 2/9/2006 1:56 AM: >> I'm hoping to release coreutils-5.94 soon. If anyone sees >> something on the trunk that they want but that's not yet >> in 5.94, please speak up now. So far, my policy has been >> to apply only bug fixes. > > Whatever happened to this thread: > http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00285.html Thanks for bringing that up. In spite of saying I wanted to fix it for 5.94, I decided to let it wait. The probable fix and tests seem complicated/risky enough that I'd prefer to release 5.94 now. For example, the tests will have to be dependent on how rename works, and will have to ensure that e.g., rm -rf a b; touch a; mv a b/ still fails on systems with a rename syscall that honors trailing slashes. I'd rather see such changes made to the trunk first, and get some exposure through a test release. Besides, no one volunteered to do the work ;-) The code changes are trivial. Writing tests and changing documentation will take more time. The fact that changing this part of mv induces no failure (on Linux) in the test suite is a sure indication we need more tests. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-5.94 imminent
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jim Meyering on 2/9/2006 1:56 AM:
> I'm hoping to release coreutils-5.94 soon. If anyone sees
> something on the trunk that they want but that's not yet
> in 5.94, please speak up now. So far, my policy has been
> to apply only bug fixes.
Whatever happened to this thread:
http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00285.html
The question was whether "mv a b/" failing when a is a directory and b
does not exist, which is a regression from 5.2.1, should be fixed in 5.94.
The thread spans month boundaries, but never seemed to reach any solid
conclusions. However, I am inclined to believe that rename("a", "b/") is
ambiguous of whether it should succeed in the same situation, and that "mv
a b/" should succeed if the underlying rename(2) can do so.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD8JF584KuGfSFAYARAkBuAJ47EBEGTWZCP3A9BLQRUFA2odvyGACfQyEh
3i3Shc08kRDwTESaCcyEvB4=
=O/5I
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-5.94 imminent
Andreas Schwab <[EMAIL PROTECTED]> wrote: > Jim Meyering <[EMAIL PROTECTED]> writes: > >> stat accepts the new option --printf=FMT, where FMT is *not* >> automatically newline terminated. > > Something's missing here: > >> works, backslash escapes in FMT *are* interpreted. Thanks. Now it looks like this: stat's --format=FMT option now works the way it did before 5.3.0: FMT is automatically newline terminated. The first stable release containing this change was 5.92. stat accepts the new option --printf=PFMT, where PFMT is *not* automatically newline terminated. Backslash escapes in PFMT *are* interpreted. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils-5.94 imminent
Jim Meyering <[EMAIL PROTECTED]> writes: > stat accepts the new option --printf=FMT, where FMT is *not* > automatically newline terminated. Something's missing here: > works, backslash escapes in FMT *are* interpreted. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils-5.94 imminent
I'm hoping to release coreutils-5.94 soon. If anyone sees something on the trunk that they want but that's not yet in 5.94, please speak up now. So far, my policy has been to apply only bug fixes. The df none/proc change was admittedly borderline, but it's small and safe, imho. The most important change is probably stat's feature adjustment to make it compatible with pre-5.3.0. Here's what the NEWS file (on the b5 branch) looks like now: * Major changes in release 5.94-cvs (2006-??-??) [stable] ** Feature changes df now considers "none" and "proc" file systems to be dummies and therefore does not normally display them. Also, inaccessible file systems (which can be caused by shadowed mount points or by chrooted bind mounts) are now dummies, too. stat's --format=FMT option now works the way it did before 5.3.0: FMT is automatically newline terminated. The first stable release containing this change was 5.92. stat accepts the new option --printf=FMT, where FMT is *not* automatically newline terminated. works, backslash escapes in FMT *are* interpreted. stat: backslash escapes are interpreted in a format string specified via --printf=FMT, but not one specified via --format=FMT. That includes octal (\ooo, at most three octal digits), hexadecimal (\xhh, one or two hex digits), and the standard sequences (\a, \b, \f, \n, \r, \t, \v, \", \\). ** Bug fixes When `cp -RL' encounters the same directory more than once in the hierarchy beneath a single command-line argument, it no longer confuses them with hard-linked directories. fts-using tools (chmod, chown, chgrp, du) no longer fail due to a double-free bug -- it could be triggered by making a directory inaccessible while e.g., du is traversing the hierarchy under it. fts-using tools (chmod, chown, chgrp, du) no longer misinterpret a very long symlink chain as a dangling symlink. Before, such a misinterpretation would cause these tools not to diagnose an ELOOP error. sort would fail for large inputs (~50MB) on systems with a buggy mkstemp function. sort and tac now use the replacement mkstemp function, and hence are no longer subject to limitations (of 26 or 32, on the maximum number of files from a given template) on HP-UX 10.20, SunOS 4.1.4, Solaris 2.5.1 and OSF1/Tru64 V4.0F&V5.1. tail -f once again works on a file with the append-only attribute (affects at least Linux ext2, ext3, xfs file systems) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
