Re: mv -v, cp -v messages should be different
jida...@jidanni.org wrote: Gentlemen, I object. The messages for these two commands should be different. $ cp -v f g `f' - `g' $ mv -v f g `f' - `g' Exactly how different etc. I leave up to you. Maybe even just = for the latter instead of -. I think it's fine from the context as is? If one was going to change it I'd have: file == file_copy file - file_rename file = file_copy_unlink But I don't see the need TBH. cheers, Pádraig.
RE: mv doesn't respect --reply=no
Hello Eric, Thank you very much for your reply and recommendation. I have replaced gnuwin32 with cygwin and mv.exe with rsync.exe and everything now works as expected. Thanks again, Miro -Original Message- From: Eric Blake [mailto:e...@byu.net] Sent: Tuesday, October 20, 2009 7:56 PM To: Halas, Miroslav Cc: bug-coreutils@gnu.org Subject: Re: mv doesn't respect --reply=no -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Halas, Miroslav on 10/20/2009 3:54 PM: This bus was encountered as part of mv.exe from coreutils 5.3.0 from gnuwin project Severely old. The latest version is 8.0. I'd recommend upgrading to something a little more maintained, such as the cygwin port of coreutils. mv --v --reply=no a.txt Z:\ always overwrites Z:\a.txt if present. Not a bug, but admittedly confusing. My understanding is that --reply=no should mean answer no to question about overwriting the file. No, --reply=no means to answer no IF THE QUESTION WOULD HAVE BEEN ASKED. But since POSIX requires mv to overwrite writable files without asking, depending on the situation (and your situation was one of them), there was no question ever asked for --reply=no to respond to. http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#cp-and-mv-t he-reply-option-is-deprecated And your confusion in this matter is why newer versions of mv have altogether removed --reply. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkreXAoACgkQ84KuGfSFAYBnKQCg1GTr+Tsu7EVmDr0mNC/S1L/Y nZMAn2wX2Cxkq3Q6oUEm5uxhx5tsrhsk =3icw -END PGP SIGNATURE-
Re: mv doesn't respect --reply=no
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Halas, Miroslav on 10/20/2009 3:54 PM: This bus was encountered as part of mv.exe from coreutils 5.3.0 from gnuwin project Severely old. The latest version is 8.0. I'd recommend upgrading to something a little more maintained, such as the cygwin port of coreutils. mv --v --reply=no a.txt Z:\ always overwrites Z:\a.txt if present. Not a bug, but admittedly confusing. My understanding is that --reply=no should mean answer no to question about overwriting the file. No, --reply=no means to answer no IF THE QUESTION WOULD HAVE BEEN ASKED. But since POSIX requires mv to overwrite writable files without asking, depending on the situation (and your situation was one of them), there was no question ever asked for --reply=no to respond to. http://www.gnu.org/software/coreutils/faq/coreutils-faq.html#cp-and-mv-the-reply-option-is-deprecated And your confusion in this matter is why newer versions of mv have altogether removed --reply. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkreXAoACgkQ84KuGfSFAYBnKQCg1GTr+Tsu7EVmDr0mNC/S1L/Y nZMAn2wX2Cxkq3Q6oUEm5uxhx5tsrhsk =3icw -END PGP SIGNATURE-
Re: mv should call fsync before erasing source file
Jim Meyering wrote: Maybe you want a new option to enable this behavior when does not do an atomic rename, but it will never be the efault, because it would cause a huge performance hit when copying many files between devices. True, it's the classic reliability vs performance tradeoff, although in the case of a batch move, the algorithm could be changed to copy many, sync many, remove many in that order. Anyway, a command line option would be better than nothing. Just the existence of the option and a short blurb in mv --help could potentially make someone reading the help text aware who might otherwise not be. Of course there are workarounds (such as using find/dd/rm in a script as you suggest, in fact I might just write such a script and alias it to mv) but I'm especially concerned for a newbie who might not even know there was a potential for a problem. -- View this message in context: http://www.nabble.com/mv-should-call-fsync-before-erasing-source-file-tp25725948p25733498.html Sent from the Gnu - Coreutils - Discuss mailing list archive at Nabble.com.
Re: mv italian translation
On Thu, 30 Apr 2009, Stefano Mersi wrote: when trying to move a diretcory into itself the progam says in italian: mv: impossibile spostare myDir in una sottodirectory di sé stessa, myDir/myDir There is a grammar error: sé stessa should become se stessa Please report translations bugs here: http://translationproject.org/team/it.html Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: the --reply option is deprecated; use -i or -f instead
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dennis Heuer on 3/30/2009 11:10 AM: hello, i just read the message as in the subject as i tried to archive some web-pages. the problem with dropping this option is that there is no alternative for --reply=no, if you think twice. this option is quite helpful to not overwrite files of different content but of same name, as is often with web-pages. this also can't be solved with -u. please think twice and at least offer an alternative like: Consider upgrading: coreutils 7.1 added 'mv --no-clober' for exactly this reason. - -- Don't work too hard, make some time for fun as well! Eric Blake e...@byu.net -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknQ/zoACgkQ84KuGfSFAYDh3ACgq9EfYykgjNoyV7YmxCcl8iRf WCgAnR+QovTtIRk2C0Exm0pIqm7xbbjI =iH1q -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: the --reply option is deprecated; use -i or -f instead
Hello Dennis, On Monday 30 March 2009 19:10:11 Dennis Heuer wrote: i just read the message as in the subject as i tried to archive some web-pages. the problem with dropping this option is that there is no alternative for --reply=no, if you think twice. this option is quite helpful to not overwrite files of different content but of same name, as is often with web-pages. this also can't be solved with -u. please think twice and at least offer an alternative like: -s skip files if already existing there is an alternative - new cp/mv option --no-clobber (-n). It was introduced in coreutils 7.1. Kamil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv --reply=no needs an alternative
Hello Mike, there is an alternative: 'mv -n'. Which version of coreutils are you using? What does 'mv --version' say? Kamil On Tuesday 03 March 2009 16:06:44 Mike McWilliam wrote: Hello All I have read many explainations why '--reply=no' does not work as expected. I am dumbfounded why the hundreds of posts out there neglect the fact there is no way to move safely AND QUIETLY. Yet discuss at great length about how the documentation is misleading, and that this particular option is defined behaviour for this very specific behavior. If you ask me the mv command is flawed, like I say in my subject line, there is no alternative for safe AND QUIET moving. If you wanted a special --reply=no then rename the option, like --reply-obscure-case=no should be implemented. Yes, I understand this non-intuitive case has been in mv long enough that changing the behaviour of mv would screw up MANY scripts. Yet there is also talk of deprecating it, and removing this option. Well if this is the case, then bring it back again, but allow the behaviour to do safe and quiet moves. Regardless of the --reply=no issue, tell me how can I move files without overwriting? If I have to write a bash scrip I will, but would prefer not to. Thanks Mike ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: preserving permissions for `./file': Invalid argument
Richard Leeden wrote: Since 7.1 I'm seeing an error message with mv when attempting to move files from filesystems mounted on swap (such as /tmp and /var/run). I've only been able to test on sparc Solaris and see the issue on Solaris 8 and 9 but not on 10. To reproduce: roottouch /tmp/a rootmv /tmp/a . mv: preserving permissions for `./a': Invalid argument The mv of the file does work though. I don't see the problem when moving files within standard filesystems, or when moving a file to /tmp or within /tmp - only when moving from /tmp to a standard filesystem. Thanks for the report. However we'll need more information. For example, what is the type of your destination file system? If it's a local file system, df -hT . will tell you. If it's NFS, it'd be good if you could tell us the OS of the server as well as the type of disk it exports. What are the permissions of the source and destination files and the destination directory? I.e., run this after the mv: ls -ld /tmp/a a . Also, please rerun your example under truss, to see what system calls are used i.e., rm -f a truss -o log mv /tmp/a . and post the log. Caveat: Solaris 8 and 9 are on the way out, in my mind. I haven't had access to those types of systems for at least three years now, and that's a pretty serious impediment to maintaining portability to them. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: preserving permissions for `./file': Invalid argument
Jim Meyering wrote: Thanks for the report. However we'll need more information. For example, what is the type of your destination file system? If it's a local file system, df -hT . will tell you. If it's NFS, it'd be good if you could tell us the OS of the server as well as the type of disk it exports. What are the permissions of the source and destination files and the destination directory? I.e., run this after the mv: ls -ld /tmp/a a . Also, please rerun your example under truss, to see what system calls are used i.e., rm -f a truss -o log mv /tmp/a . and post the log. Caveat: Solaris 8 and 9 are on the way out, in my mind. I haven't had access to those types of systems for at least three years now, and that's a pretty serious impediment to maintaining portability to them. Thanks for the reply. And, yes I agree Solaris 8 and 9 are on the way out, but unfortunately we're going to be stuck with them at work for some time to come yet. :( Anyway, here's the info you asked for. The destintation FS is a local FS: output from df -hT . FilesystemTypeSize Used Avail Use% Mounted on /dev/md/dsk/d24 ufs481M 209M 225M 49% /usr/home Full details of all permissions, before and after the move: rootrm -f a roottouch /tmp/a root rootls -ld /tmp /tmp/a . a ls: cannot access a: No such file or directory drwxr-xr-x 5 rleeden admin 8192 Feb 28 09:05 . drwxrwxrwt 11 rootsys 4484 Feb 28 09:05 /tmp -rw-r--r-- 1 rootother0 Feb 28 09:05 /tmp/a root rootmv /tmp/a . mv: preserving permissions for `./a': Invalid argument root rootls -ld /tmp /tmp/a . a ls: cannot access /tmp/a: No such file or directory drwxr-xr-x 5 rleeden admin 8192 Feb 28 09:05 . drwxrwxrwt 11 rootsys 4355 Feb 28 09:05 /tmp -rw-r--r-- 1 rootother0 Feb 28 09:05 a root And the truss output: execve(/usr/local/bin/mv, 0xFFBFF2FC, 0xFFBFF30C) argc = 3 resolvepath(/usr/lib/ld.so.1, /usr/lib/ld.so.1, 1023) = 16 resolvepath(/usr/local/bin/mv, /usr/local/bin/mv, 1023) = 17 stat(/usr/local/bin/mv, 0xFFBFF0C0) = 0 open(/var/ld/ld.config, O_RDONLY) = 3 fstat(3, 0xFFBFEB40)= 0 mmap(0x, 132, PROT_READ, MAP_SHARED, 3, 0) = 0xFF3B close(3)= 0 stat(/usr/local/lib/libintl.so.8, 0xFFBFEBC8) = 0 resolvepath(/usr/local/lib/libintl.so.8, /usr/local/lib/libintl.so.8.0.2, 1023) = 31 open(/usr/local/lib/libintl.so.8, O_RDONLY) = 3 mmap(0x0001, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_ALIGN, 3, 0) = 0xFF3A mmap(0x0001, 106496, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFF38 mmap(0xFF38, 34770, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF38 mmap(0xFF398000, 4364, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 32768) = 0xFF398000 munmap(0xFF38A000, 57344) = 0 memcntl(0xFF38, 8240, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 close(3)= 0 stat(/usr/local/lib/libc.so.1, 0xFFBFEBC8)Err#2 ENOENT stat(/usr/lib/libc.so.1, 0xFFBFEBC8) = 0 resolvepath(/usr/lib/libc.so.1, /usr/lib/libc.so.1, 1023) = 18 open(/usr/lib/libc.so.1, O_RDONLY)= 3 mmap(0xFF3A, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF3A mmap(0x0001, 802816, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFF28 mmap(0xFF28, 703464, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF28 mmap(0xFF33C000, 24496, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 704512) = 0xFF33C000 mmap(0xFF342000, 6720, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xFF342000 munmap(0xFF32C000, 65536) = 0 memcntl(0xFF28, 117696, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 close(3)= 0 stat(/usr/local/lib/libgen.so.1, 0xFFBFEBC8) Err#2 ENOENT stat(/usr/lib/libgen.so.1, 0xFFBFEBC8)= 0 resolvepath(/usr/lib/libgen.so.1, /usr/lib/libgen.so.1, 1023) = 20 open(/usr/lib/libgen.so.1, O_RDONLY) = 3 mmap(0xFF3A, 32768, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF3A mmap(0x0001, 98304, PROT_NONE, MAP_PRIVATE|MAP_NORESERVE|MAP_ANON|MAP_ALIGN, -1, 0) = 0xFF36 mmap(0xFF36, 22921, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xFF36 mmap(0xFF376000, 2351, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 24576) = 0xFF376000 munmap(0xFF366000, 65536) = 0 mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFF35 memcntl(0xFF36, 6372, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0 close(3)= 0 stat(/usr/local/lib/libiconv.so.2, 0xFFBFEBC8) = 0 resolvepath(/usr/local/lib/libiconv.so.2, /usr/local/lib/libiconv.so.2.4.0, 1023) = 32 open(/usr/local/lib/libiconv.so.2, O_RDONLY) = 3
Re: mv: preserving permissions for `./file': Invalid argument
Richard Leeden wrote: Jim Meyering wrote: Thanks for the report. However we'll need more information. For example, what is the type of your destination file system? If it's a local file system, df -hT . will tell you. If it's NFS, it'd be good if you could tell us the OS of the server as well as the type of disk it exports. What are the permissions of the source and destination files and the destination directory? I.e., run this after the mv: ls -ld /tmp/a a . Also, please rerun your example under truss, to see what system calls are used i.e., rm -f a truss -o log mv /tmp/a . and post the log. Caveat: Solaris 8 and 9 are on the way out, in my mind. I haven't had access to those types of systems for at least three years now, and that's a pretty serious impediment to maintaining portability to them. Thanks for the reply. And, yes I agree Solaris 8 and 9 are on the way out, but unfortunately we're going to be stuck with them at work for some time to come yet. :( Anyway, here's the info you asked for. The destintation FS is a local FS: output from df -hT . FilesystemTypeSize Used Avail Use% Mounted on /dev/md/dsk/d24 ufs481M 209M 225M 49% /usr/home Full details of all permissions, before and after the move: rootrm -f a roottouch /tmp/a root rootls -ld /tmp /tmp/a . a ls: cannot access a: No such file or directory drwxr-xr-x 5 rleeden admin 8192 Feb 28 09:05 . drwxrwxrwt 11 rootsys 4484 Feb 28 09:05 /tmp -rw-r--r-- 1 rootother0 Feb 28 09:05 /tmp/a root rootmv /tmp/a . Thanks. One more question. Does the same thing happen when you do this as a normal user? I have to admit that this is low priority, so it may be a week or two before I investigate. In the mean time, try building without ACL support: ./configure --disable-acl and see if the mv you get from that works better. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: preserving permissions for `./file': Invalid argument
Jim Meyering wrote: Richard Leeden wrote: Jim Meyering wrote: Thanks for the report. However we'll need more information. For example, what is the type of your destination file system? If it's a local file system, df -hT . will tell you. If it's NFS, it'd be good if you could tell us the OS of the server as well as the type of disk it exports. What are the permissions of the source and destination files and the destination directory? I.e., run this after the mv: ls -ld /tmp/a a . Also, please rerun your example under truss, to see what system calls are used i.e., rm -f a truss -o log mv /tmp/a . and post the log. Caveat: Solaris 8 and 9 are on the way out, in my mind. I haven't had access to those types of systems for at least three years now, and that's a pretty serious impediment to maintaining portability to them. Thanks for the reply. And, yes I agree Solaris 8 and 9 are on the way out, but unfortunately we're going to be stuck with them at work for some time to come yet. :( Anyway, here's the info you asked for. The destintation FS is a local FS: output from df -hT . FilesystemTypeSize Used Avail Use% Mounted on /dev/md/dsk/d24 ufs481M 209M 225M 49% /usr/home Full details of all permissions, before and after the move: rootrm -f a roottouch /tmp/a root rootls -ld /tmp /tmp/a . a ls: cannot access a: No such file or directory drwxr-xr-x 5 rleeden admin 8192 Feb 28 09:05 . drwxrwxrwt 11 rootsys 4484 Feb 28 09:05 /tmp -rw-r--r-- 1 rootother0 Feb 28 09:05 /tmp/a root rootmv /tmp/a . Thanks. One more question. Does the same thing happen when you do this as a normal user? I have to admit that this is low priority, so it may be a week or two before I investigate. In the mean time, try building without ACL support: ./configure --disable-acl and see if the mv you get from that works better. Yes, same thing happens as a normal user. And, yes building without ACL support, I no longer see the error message when doing the mv. No worries about this being low priority. But if you need any more info let me know. Richard -- View this message in context: http://www.nabble.com/mv%3A-preserving-permissions-for-%60.-file%27%3A-Invalid-argument-tp22247790p22260660.html Sent from the Gnu - Coreutils - Discuss mailing list archive at Nabble.com. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv feature request: -z swap files
TL Mieszkowski t...@ftfa.us wrote: I've needed to swap two filenames more than once, but no UNIX program I can find does it. The patch I've included works on two regular files, one regular file and a directory, but if you provide two directories or 1 directory first it trashes the first directory. I think this is due the vagaries of the rename function, but I can't understand why it happens. It says it can't copy a directory into itself, but the target doesn't even exist. There may also be issues across filesystems, since it uses the /tmp directory? Is there a way to do it without a /tmp? Is it possible to do it right, without just calling mv? Is this workable at all? Thank you for the patch, but this functionality does not belong in mv. However, a program that does that -- and does it robustly and efficiently -- would be a useful addition to coreutils. Note that it must be safe to run e.g., cd /tmp exch FILE1 FILE2, assuming the new tool is called exch. I don't want to dictate the language (or maybe I do ;-), but at least initially it should be a script, probably written in Perl. I'm considering maintaining a contrib/ directory in coreutils, and if someone already has such a script, I'd consider adding it. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv missing destination operand message
[EMAIL PROTECTED] (Karl Berry) wrote: $ mv foo mv: missing destination file operand after `/u/karl/tmp/paper.ltx' The destination operand doesn't have to be a file, it is often a directory. So I suggest deleting file. Not that I will argue if you decide not to :). Hi Karl, Thanks for the suggestion. However, file is often used not to distinguish between symlink, directory, fifo, block device, etc, but rather to denote a generic file system object, and that's the intent here. That same diagnostic is also used in cp, ln, and install, so I'd like to keep it as is. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv missing destination operand message
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 9/25/2008 1:24 AM: mv: missing destination file operand after `/u/karl/tmp/paper.ltx' However, file is often used not to distinguish between symlink, directory, fifo, block device, etc, but rather to denote a generic file system object, and that's the intent here. That same diagnostic is also used in cp, ln, and install, so I'd like to keep it as is. On the other hand, is there any reason why 'ln path/to/file' creates './file', while 'mv path/to/file' and 'cp path/to/file' complain? For all three apps, POSIX does not specify the one-argument case, so we are free to choose the behavior that makes the most sense. I'm wondering if adding some consistency here would help matters (either make ln reject the one-argument case, or make cp and mv treat the one-argument case as an implicit '-t .'). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjbg2gACgkQ84KuGfSFAYCjowCfQJAuBuFPE27tEkwQqyATSFiK qSkAnjgeevYBD6KGFuwEtsajVjt9zVJa =UQ9W -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv missing destination operand message
Eric Blake [EMAIL PROTECTED] wrote: According to Jim Meyering on 9/25/2008 1:24 AM: mv: missing destination file operand after `/u/karl/tmp/paper.ltx' However, file is often used not to distinguish between symlink, directory, fifo, block device, etc, but rather to denote a generic file system object, and that's the intent here. That same diagnostic is also used in cp, ln, and install, so I'd like to keep it as is. On the other hand, is there any reason why 'ln path/to/file' creates './file', while 'mv path/to/file' and 'cp path/to/file' complain? For all three apps, POSIX does not specify the one-argument case, so we are free to choose the behavior that makes the most sense. I'm wondering if adding some consistency here would help matters (either make ln reject the one-argument case, or make cp and mv treat the one-argument case as an implicit '-t .'). Removing the one-arg feature of ln is not an option, as I'm sure you know. GNU ln has been that way for a very long time -- probably since the beginning. I'm not too enthusiastic about making cp and mv consistent on that front, but if some other implementation does that, or if enough people think it'd be a worthwhile feature addition (not just for consistency), I'd consider it. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv missing destination operand message
Jim Meyering [EMAIL PROTECTED] writes: Removing the one-arg feature of ln is not an option, as I'm sure you know. GNU ln has been that way for a very long time -- probably since the beginning. In fact, it's already in 2BSD. But both cp and mv always required at least two arguments. 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
Re: mv symlink-to-dir/, debian bug feed
On Jan 28, 2008 12:45 AM, Bob Proulx [EMAIL PROTECTED] wrote: For all distros perhaps being more aggressive at forwarding downstream bugs to the upstream mailing list would be a good thing. I know that I have not been doing that as much as I should. I could not agree more. I often find that there are bugs or patches of which I had no knowledge because they were never forwarded upstream. In my case, I'm referring to findutils, and the Debian packager for findutils is easily the most communicative of all the distribution contacts. So much so, that I don't even know who the relevant person is for (afaict) any other distribution.(I've BCC'ed him to let him know I appreciate his work while still sparing his blushes). However, nevertheless I have subscribed myself for findutils and locate (with pts-subscribe). The downstream maintainers do a lot of valuable work in making the various tools work together in sensible ways and in doing triage of bugs. However, should it be the case that I make a boneheaded call on a feature or transition[*], seeing the influx of bug reports to the distibutions is an important signal that somethng has gone wrong. I fear though that there may be memebrs of the mailing list who might be deterred by the increased level of email. That wouldn't include me though, I think (famous last words...). [*] Case in point: the short-lived change in find's regex syntax. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv symlink-to-dir/, debian bug feed
Jim Meyering wrote: Eric Blake wrote: Meanwhile, would it be worth subscribing bug-coreutils to the debian bug feed list? That way, this list would see bugs as they are reported, and others besides Jim will be able to chime in with advice. I know Bob Proulx is already subscribed there. Some of the traffic would not be interesting, i.e., a message announcing that a bug is closed, or tagged -- but those are easy to skip. Overall, I think it would be better for both Debian and GNU. We can always try, and if it doesn't work out, remove it later. Bob, Michael, what do you think? I have mixed thoughts about subscribing GNU's bug-coreutils to the Debian coreutils BTS list. There are good points and bad points and I can think of several of each. It will be more information and more noise to the mailing list. I can't be unbiased and so will abstain from voting. In the end it will depend upon the needs of the rest of the community. If Jim would like to subscribe it and gets benefit from it then that is okay with me. For all distros perhaps being more aggressive at forwarding downstream bugs to the upstream mailing list would be a good thing. I know that I have not been doing that as much as I should. I will comment that the way reports should be answered will be different depending upon the path by which they are reported. Users of a software distribution are best served when the bug is fixed in the native packaging environment. This means that answering a user with a pointer to the source code and saying to upgrade to the latest version is not the best thing for a distribution user. If a Solaris, HP-UX, IBM AIX, etc. (no native packages) user reports a bug and they have a locally compiled version of the source then this makes the most sense. But for Debian and others too the best answer is usually to get things into the pipeline for an official release such that the next software distribution stable release contains the fix. In that environment developers may work on the bleeding edge but less technical users are encouraged to work in stable release environments. There will often be a large pipeline delay between upstream and downstream. Living with both environments will mean needing to understand the reporting user's environment and how to best serve the user when answering. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv symlink-to-dir/, debian bug feed
Eric Blake [EMAIL PROTECTED] wrote: I've noticed that Jim just committed a patch based on a bug originally reported through the debian tracker without any additional mention here: http://git.sv.gnu.org/gitweb/?p=coreutils.git;a=commit;h=c0c8685 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=343652 Thanks. But regarding the patch, I'm wondering if an Austin Group interpretation is needed here. The next draft for POSIX has already tightened the IMHO, it is needed. If you're willing to broach the subject, that'd be great. wording to make it clear that rename(dir, newdir/) must fail with ENOTDIR if newdir is not already a directory. Likewise, it clarifies that 'mv dir newdir/' must fail (oops - coreutils 6.10 doesn't do that). However, I still don't see any clarification on whether the Linux behavior of rename(symlink-to-dir/, newname) failing with ENOTDIR is valid. As you probably realize, that is behavior straight from glibc and the kernel rename syscall. Meanwhile, would it be worth subscribing bug-coreutils to the debian bug feed list? That way, this list would see bugs as they are reported, and others besides Jim will be able to chime in with advice. I know Bob Proulx is already subscribed there. Some of the traffic would not be interesting, i.e., a message announcing that a bug is closed, or tagged -- but those are easy to skip. Overall, I think it would be better for both Debian and GNU. We can always try, and if it doesn't work out, remove it later. Bob, Michael, what do you think? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv symlink-to-dir/, debian bug feed
On Sat, Jan 26, 2008 at 07:23:08PM +0100, Jim Meyering wrote: I know Bob Proulx is already subscribed there. Some of the traffic would not be interesting, i.e., a message announcing that a bug is closed, or tagged -- but those are easy to skip. Overall, I think it would be better for both Debian and GNU. We can always try, and if it doesn't work out, remove it later. Bob, Michael, what do you think? Fine with me. Subscription options are here: http://www.debian.org/doc/manuals/developers-reference/ch-resources.en.html#s-pkg-tracking-system I think if bts is chosen, you'd get only bug reports without the extraneous status change emails. Mike Stone ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: Moving directories to themselves (not the bug with incorrect error message)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Michal Wencl on 11/18/2007 3:16 AM: mkdir -p a b/a touch a/1 a/2 b/a/2 move a b Current result: In my version of mv (5.97) the following error message is returned: Consider upgrading. The latest stable version of coreutils is 6.9, and it includes some bug fixes for mv. Expected result: Directory a is fully moved to directory b/a, thus b/a contains files 1 and 2 where b/a/2 was overwritten witch a/2. Wrong. POSIX doesn't allow this behavior. In order to move directory a to a subdirctory of b, when b/a already exists, b/a must be unlinkable; but since b/a is not empty, it can't be unlinked. Could you think about it, please? It would be great if at least a switch for it was added to mv (and other coreutils). What you appear to be wanting is a new option to mv, maybe spelled like 'mv --merge'. But such a feature is not part of coreutils yet, because no one has submitted a patch for it. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQDw684KuGfSFAYARAvTiAJ4iBg1Ao0I16Y4vcxSIrtJJ4aeUUwCdGOd1 fUxP2Kr0h+vbSm0mRrjD8mQ= =z0MJ -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: Moving directories to themselves (not the bug with incorrect error message)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 11/18/2007 6:20 AM: Could you think about it, please? It would be great if at least a switch for it was added to mv (and other coreutils). What you appear to be wanting is a new option to mv, maybe spelled like 'mv --merge'. But such a feature is not part of coreutils yet, because no one has submitted a patch for it. As a followup, I'm pretty sure rsync already does what you are looking for, so why bloat mv to do something that can be done with another tool? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHQD1I84KuGfSFAYARAtehAKCKcuXr5P3lcuvPQmT+iprw4LWmIQCfdCyl L3aMb0bqHSlTSZ2VcJ0xgnM= =TTAH -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: Moving directories to themselves (not the bug with incorrect error message)
As a followup, I'm pretty sure rsync already does what you are looking for, so why bloat mv to do something that can be done with another tool? Thanks for a quick answer. I didn't study rsync deeply yet but I understand it as a copy utility that temporarily takes filesystem space and wears down a storage medium when moving files to another directory. That is not necessary (it's unwanted) in this case. The mv --merge you proposed might still be useful. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: Moving directories to themselves (not the bug with incorrect error message)
Michal Wencl wrote: As a followup, I'm pretty sure rsync already does what you are looking for, so why bloat mv to do something that can be done with another tool? I didn't study rsync deeply yet but I understand it as a copy utility that temporarily takes filesystem space Rsync is a swiss-army-chainsaw tool. It has a zillion options and operating modes. But it is also often simply the best tool for the job too. Check out the --inplace option. It is not a perfect fit but may be enough. and wears down a storage medium when moving files to another directory. I think you are thinking of the work needed to compare two files between the client and the server. For individual runs it is unlikely to be a problem. It becomes a problem when a server is serving a large number of files to a large number of clients. The large number of processes all grinding away can be a problem. But in the single threaded case it is not much different from other file copy methods. That is not necessary (it's unwanted) in this case. The mv --merge you proposed might still be useful. If someone were to write a patch with a copyright assignment to the FSF so that it could be used I am sure that it would be considered. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv can't change filename case on case-insensitive file systems
Jonathan Lennox lennox at cs.columbia.edu writes: On Cygwin using non-managed mounts (and presumably other operating systems when using a case-insensitive file system), it's not possible to use Coreutils mv to change the case of a filename; mv reports that they are the same file. There is another case-insensitive file system issue that I hope we can clean up in the process, which affects both mv and cp: $ mkdir a b c $ touch a/a b/a $ cp -vR a/* b/* c `a/a' - `c/a' cp: will not overwrite just-created `c/a' with `b/a' But $ mkdir a b c $ echo 1 a/A $ echo 2 b/a $ cp -vR a/* b/* c `a/A' - `c/A' `b/a' - `c/a' $ ls c A $ cat c/a 2 Oops - we got the spelling of a/A but the contents of b/a (the result is corrupted), because we did not detect the clash in the case-insensitive filenames. And had we used 'mv -v' instead of 'cp -vR', the result is the silent loss of data, which is contrary to the goal of mv. Maybe a first step is teaching same_name in gnulib's same.c about case- insensitive directories. But it would sure be a lot easier if there were a reliable way to tell if a directory entry of a different case in a case- insensitive directory already exists (or, put another way, it would be nice if something like realpath could be used to fess up to the canonical case spelling of a directory entry but without dereferencing the final symlink; canonicalize_filename_mode(CAN_ALL_BUT_LAST) doesn't cut it as currently implemented). Even something like pathconf(dir, _PC_CASE_INSENSITIVE) would be useful, but again, that is not standardized. Lacking an efficient standardized API, checks for case-insensitivity are only needed when stricmp() succeeds when strcmp() fails (actually, I'm not sure whether choice of locale can affect case-insensitive equality of filenames?). So a first-order approximation is doing a stricmp()/strcmp() filter, and when that shows a possible clash, use stat() on both spellings and declare that the directory is case-insensitive if the inodes match and the link count is 1. But that still doesn't solve the ambiguity when foo and Foo have the same inode, but link count 1, because we still can't tell if foo and Foo are case- sensitive hard links to each other or if foo is a hardlink to bar and Foo is a case-insensitive reference to foo. At this point, about the only way I can see to portably resolve that ambiguity is with a readdir() search. You can see where this is headed - it is adding a LOT of overhead into checking for the corner-case of case-insensitivity, where such overhead is unnecessary if you comply with POSIX and have no case-insensitive file systems in the first place. Maybe now is the time to start lobbying for cygwin, Mac, and Linux to agree on a way to efficiently identify case-insensitive directories? On the other hand, since gnulib doesn't mind platform-specific code inside generic APIs, I could easily prepare a gnulib patch for same_name() that answers the question correctly for cygwin (it won't help for Mac or Linux, or any other system that has a way to mount FAT, HFS, or NTFS systems case- insensitively, but support for additional systems can be added to gnulib as solutions are encountered). Christian Franke proposed an idea for such a patch here: http://cygwin.com/ml/cygwin-developers/2007-08/msg00030.html -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv executed incompletely due to insufficient privileges
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Elmar Stellnberger on 8/17/2007 1:13 PM: package/version: coreutils-5.93-20 Consider upgrading. The latest stable coreutils is 6.9. In this case the privileges suffice for creating a new directory entry for the destination file but not for removing the source file. Awkwardly the result will depend on whether the target location resides on the same mount point or not: * same mount point: nothing is done * different mount point: file is copied but not deleted Generally we expect mv to be atomic by default. Thanks for the report. However, but mv is only atomic when you don't cross mount points (ie. when rename(2) will do the job, rather than a full blown copy/delete sequence). If the --backup switch is stated we may want it to behave like a copy and delete in sequence (copied though not deleted). Notwithstanding the result should always be the same no matter whether source and destination reside on different mount points! When successful, the end results are the same. And on failure, as you discovered, a message is printed telling you why the failure occurred, even if the reason for failure differs between local and cross-device moves. This behavior is all specified by POSIX, so there is no bug here. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGxlo584KuGfSFAYARAoGaAKDHMOrBc35+uLPzpUw5vP2mi355LgCgzPF4 vzteUb4eK9/kDvLqYgTOSSY= =UGQm -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv can't change filename case on case-insensitive file systems
Eric Blake wrote: [snip] Mac HFS is the other biggest case-preserving case-insensitive system out there; can anyone comment on whether rename(2) is a no-op or changes case when given two case-wise distinct spellings of the same file? Adding to what Jonathan already posted... $ df -T . FilesystemType 1K-blocks Used Available Use% Mounted on /dev/disk0s3 hfs80287128 12435372 67595756 16% / $ touch foo $ mv foo Foo mv: `foo' and `Foo' are the same file $ mv --version mv (GNU coreutils) 6.9 Copyright (C) 2007 Free Software Foundation, Inc. This is free software. You may redistribute copies of it under the terms of the GNU General Public License http://www.gnu.org/licenses/gpl.html. There is NO WARRANTY, to the extent permitted by law. Written by Mike Parker, David MacKenzie, and Jim Meyering. $ /bin/mv foo Foo # /bin/mv is not coreutils $ ls ?oo Foo $ perl -e 'rename(Foo,foo)' $ ls ?oo foo $ uname -srp Darwin 8.8.0 powerpc $ -- Matthew So long, and thanks for all the fish -- the dolphins ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv can't change filename case on case-insensitive file systems
On Thursday, August 16 2007, John Cowan wrote to Eric Blake, John Cowan, Jonathan Lennox, bug-coreutils@gnu.org saying: Eric Blake scripsit: You missed my earlier remark - since POSIX requires case sensitivity, a case-insensitive file system is not specified by POSIX, therefore, a platform may do whatever it likes with rename(2), including change the case (rather than be a no-op). Well and good. In fact, however, both Cygwin and the Linux VFAT driver do treat rename(Foo, foo) as a no-op. No, on Cygwin rename(2) will change file case: $ touch foo $ echo *oo foo $ perl -e 'rename foo, Foo or die($!)' $ echo *oo Foo $ uname -srvmo CYGWIN_NT-5.1 1.5.24(0.156/4/2) 2007-01-31 10:57 i686 Cygwin On Cygwin, rename(2) of regular files just wraps the Windows MoveFile API, after the usual path transformations and the like. -- Jonathan Lennox lennox at cs dot columbia dot edu ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv can't change filename case on case-insensitive file systems
Jonathan Lennox scripsit: No, on Cygwin rename(2) will change file case: Ah, sorry. I had mixed up what rename(2) does with what mv does. -- First known example of political correctness: John Cowan After Nurhachi had united all the other http://www.ccil.org/~cowan Jurchen tribes under the leadership of the [EMAIL PROTECTED] Manchus, his successor Abahai (1592-1643) issued an order that the name Jurchen should --S. Robert Ramsey, be banned, and from then on, they were all The Languages of China to be called Manchus. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv can't change filename case on case-insensitive file systems
On Wednesday, August 15 2007, Eric Blake wrote to Jonathan Lennox, bug-coreutils@gnu.org saying: (I reported this issue on the bug tracker on Savannah, but it looks like sending bug reports to this mailing list is preferred, so I'm repeating it here.) The bug-tracker forwards all edits to this list, so you just repeated yourself. Yes, I saw that on the web archive shortly after I sent the second message. Sorry about that. Mac HFS is the other biggest case-preserving case-insensitive system out there; can anyone comment on whether rename(2) is a no-op or changes case when given two case-wise distinct spellings of the same file? On Darwin, rename(2) does indeed change case given two spellings of the same file: $ uname -a Darwin woody.local 8.10.1 Darwin Kernel Version 8.10.1: Wed May 23 16:33:00 PDT 2007; root:xnu-792.22.5~1/RELEASE_I386 i386 i386 $ touch foo $ echo *oo foo $ perl -e 'rename foo, Foo or die ($!)' $ echo *oo Foo Darwin's mv(1) code also has special-case code added to handle case-renaming a directory, to force mv foo Foo in that case to be the equivalent of coreutils mv's mv -T foo Foo. The code (BSD licensed) is at http://www.opensource.apple.com/darwinsource/10.4.9.x86/file_cmds-116.10/mv/mv.c; you might need to register for an Apple ID. -- Jonathan Lennox lennox at cs dot columbia dot edu ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv can't change filename case on case-insensitive file systems
FAT is always upper case and the driver forces it to lower case. VFAT ignores attempts to change case with rename(), in conformity to Posix. You missed my earlier remark - since POSIX requires case sensitivity, a case-insensitive file system is not specified by POSIX, therefore, a platform may do whatever it likes with rename(2), including change the case (rather than be a no-op). There _is_ no conformity issue, once you use rename(2) on a non-conformant file system; rather, it is just a consistency issue. My question, then, is whether it is likely that Linux will be changed to take this attitude. And now that we have proven that current Linux behaves differently than current cygwin, which behavior should mv(1) promote? I would argue that being able to change case is more useful, particularly based on the volume of complaints of people on case-insenstive systems who don't like the current solution of using an intermediate name. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: cannot move `dir' to a subdirectory of itself, `../dir'
Chris Moore [EMAIL PROTECTED] writes: $ mv dir .. mv: cannot move `dir' to a subdirectory of itself, `../dir' With coreutils 6.9 you'll get Directory not empty. 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
Re: mv: cannot move `dir' to a subdirectory of itself, `../dir'
Andreas Schwab wrote: Chris Moore [EMAIL PROTECTED] writes: $ mv dir .. mv: cannot move `dir' to a subdirectory of itself, `../dir' With coreutils 6.9 you'll get Directory not empty. That also seems incorrect. Shouldn't the error be A file ( directory ) with that name already exists? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: cannot move `dir' to a subdirectory of itself, `../dir'
Phillip Susi [EMAIL PROTECTED] writes: Andreas Schwab wrote: Chris Moore [EMAIL PROTECTED] writes: $ mv dir .. mv: cannot move `dir' to a subdirectory of itself, `../dir' With coreutils 6.9 you'll get Directory not empty. That also seems incorrect. Shouldn't the error be A file ( directory ) with that name already exists? No. If the directory was empty it would just be overwritten, so the non-emptyness is the key for the error (and it's directly the error the kernel returns). 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
Re: mv can't change filename case on case-insensitive file systems
(I reported this issue on the bug tracker on Savannah, but it looks like sending bug reports to this mailing list is preferred, so I'm repeating it here.) The bug-tracker forwards all edits to this list, so you just repeated yourself. On Cygwin using non-managed mounts (and presumably other operating systems when using a case-insensitive file system), it's not possible to use Coreutils mv to change the case of a filename; mv reports that they are the same file. The underlying Cygwin rename() function does support this functionality. Although it is an unstandardized behavior. Consider - should rename(Foo, foo) be a no-op when stat(Foo) and stat(foo) resolve to the same file? Reading just the POSIX rename(2) requirements seems to say yes (it requires rename to be a no-op when both names resolve to the same inode, ie. no case change allowed); but reading the stat(2) requirements says it is undefined, since a case-insensitive filesystem violates POSIX in the first place. Mac HFS is the other biggest case-preserving case-insensitive system out there; can anyone comment on whether rename(2) is a no-op or changes case when given two case-wise distinct spellings of the same file? Also, what about FAT filesystem access under Linux? I'd like to know whether platforms agree on semantics, before deciding whether a patch is even possible. One of the more interesting manifestations of the problems with case-insensitive systems was this example culled from the mentioned thread on cygwin: $ mkdir foo $ mv -T foo Foo Rather than being a no-op (because it is two spellings of the same file) or changing the case (as was argued above might be reasonable behavior for case-insensitive systems), it triggers the coreutils shortcut that since foo and Foo give the same stat results, they must be hard-linked, so it attempts unlink(foo), which is invalid on a directory. Another example: $ touch foo $ ln foo fool $ mv foo Foo $ echo ?oo* fool Oops - because foo has a link count 1, and because stat returned the same results, unlink(foo) was called, getting rid of foo in all forms rather than just renaming foo. Yes, the data is preserved in fool, but it seems odd to have all references to foo disappear merely because of the hard link. -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: overwrite `/etc/lilo.conf', overriding mode 0644?
On Thu, Jun 14, 2007 at 06:18:38AM +0800, Dan Jacobson wrote: $ mv /etc/motd /etc/lilo.conf mv: overwrite `/etc/lilo.conf', overriding mode 0644? y mv: cannot move `/etc/motd' to `/etc/lilo.conf': Permission denied I would skip the first message, as isn't there no point in asking, as it is bound to fail. No? Yes, one could use mv -f. cp doesn't have the message. Ah ha! See? mv (GNU coreutils) 5.97 Seems you've brought this up before: http://lists.gnu.org/archive/html/bug-coreutils/2007-03/msg00130.html ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv: overwrite `/etc/lilo.conf', overriding mode 0644?
J Thanks for the bug report, but 5.97 is very close to a year old. J You're wasting your time testing it, I think, because many changes J have been made since then. Please try a recent version of coreutils. J (More generally, before reporting a bug in any piece of software, it J is advisabel to verify that you are using a recent version). I see Debian sid is not as bleeding edge as I thought. Sorry, over and out. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv
On 3/23/07, Eric Blake [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The fact that you mailed the obsolete bug-fileutils list implies that you may be due for an upgrade. fileutils merged into coreutils, and the latest stable version is now 6.9. Is it time perhaps to automate responses for the various obsolete lists? James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv
[EMAIL PROTECTED] wrote: Hello maintainers of the mv command, I have a problem with the mv command. I cannot rename a file to lower case. I used mv because Konqueror also fails. Is there an explanation to this issue? Greetings, Fabian. You're trying this on a USB key right? They generally have FAT partitions which are case insensitive. You could reformat as ext2 for example if you didn't need to use it with windos. I don't use KDE, but have seem Konq crash due to mishandling this error. Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv
James Youngman [EMAIL PROTECTED] wrote: On 3/23/07, Eric Blake [EMAIL PROTECTED] wrote: The fact that you mailed the obsolete bug-fileutils list implies that you may be due for an upgrade. fileutils merged into coreutils, and the latest stable version is now 6.9. Is it time perhaps to automate responses for the various obsolete lists? That would be great, if there is a way to ensure that the responses go only to legitimate senders. I've just updated the file (only in git/cvs), README-package-renamed-to-coreutils, with a few more URLS: -- As of 2002-09-01, the GNU fileutils, textutils, and sh-utils packages have been merged into one, called the GNU coreutils. See http://www.gnu.org/software/coreutils/ for a description. Here's the FAQ list: http://www.gnu.org/software/coreutils/faq/ For information on the mailing lists associated with the coreutils package, see these: http://mail.gnu.org/mailman/listinfo/coreutils-announce http://mail.gnu.org/mailman/listinfo/bug-coreutils mailing list archives are here: http://news.gmane.org/gmane.comp.gnu.coreutils.announce http://news.gmane.org/gmane.comp.gnu.core-utils.bugs (up to the minute) http://mail.gnu.org/pipermail/bug-coreutils/ (updated every 12 hours) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv
[EMAIL PROTECTED] wrote on 22-03-07 17:58: Hello maintainers of the mv command, I have a problem with the mv command. I cannot rename a file to lower case. I used mv because Konqueror also fails. Is there an explanation to this issue? Greetings, Fabian. Yes! -- in fact there are many possible explanations. That might be a problem right there... ;-) Why don't you for starters do: `strace -o /tmp/mv.log /bin/mv FOO foo' and see if /tmp/mv.log can make you any the wiser. bj ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The fact that you mailed the obsolete bug-fileutils list implies that you may be due for an upgrade. fileutils merged into coreutils, and the latest stable version is now 6.9. According to [EMAIL PROTECTED] on 3/22/2007 10:58 AM: Hello maintainers of the mv command, I have a problem with the mv command. I cannot rename a file to lower case. I used mv because Konqueror also fails. Is there an explanation to this issue? Sometimes it depends on your filesystem; for example, FAT is generally handled as case-preserving but case-insensitive, which means that FOO and foo name the same file, so the attempt to rename fails. You need to give us more details about your OS and filesystem. Meanwhile, you can always go through a temporary name: 'mv foo foo1; mv foo1 FOO'. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGA1e484KuGfSFAYARAuCTAKCe038jR/vX7bi5hrm1Rqxd8uuBKACgrC1z IvxkP3JsN+Y66Z76jyRg2/M= =eH31 -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv, cp ask anyway though bound to fail
P But the only way to find out is to try. ACLs allow file systems to P change their minds, so you don't know for sure whether the lunch was P cancelled until you show up and try to eat. The same principle P applies here. Must be some ask permission before taking the candy vs. take the candy and if it is not OK the lady will take it back from you or something that is too deep for me... OK ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv, cp ask anyway though bound to fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Dan Jacobson on 3/15/2007 2:05 PM: JM They're not bound to fail. JM An alternate access method (e.g., an ACL) may allow it to succeed. Does it cost much more to check first that too then before asking? E.g., if I were a secretary, I would double check if the lunch were already cancelled before asking the boss if he wants to attend. Sorry, but POSIX requires the current behavior. If it bothers you that much, then take it up with the Austin group with proposed wording that allows your desired behavior without breaking 30 years of legacy use that depends on the current behavior. http://www.opengroup.org/onlinepubs/009695399/utilities/cp.html - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+eEi84KuGfSFAYARAhTrAKCjPNiO5QmpEVUnuJPWa2FjEssj9gCfXth9 Q9klKUebI8p25VGWDQFX0cM= =36+b -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv, cp ask anyway though bound to fail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 3/15/2007 6:17 PM: Sorry, but POSIX requires the current behavior. If it bothers you that much, then take it up with the Austin group with proposed wording that allows your desired behavior without breaking 30 years of legacy use that depends on the current behavior. That said, POSIX levies no requirements on the wording of the prompt; perhaps you could propose a patch that rewords cp: overwrite `/etc/passwd', overriding mode 0644? into cp: attempt to overwrite `/etc/passwd', overriding mode 0644? , making it clear that the question is being asked before the attempt, and that the attempt may still fail. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF+eL584KuGfSFAYARAlOfAKC5pnac8Z+7pKzoxPGn9bgJSSJscgCgxAl3 u/SqUjgphPcwcc56+Kzqca4= =O/ER -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv command fails on files 4GB
Rich Morgan [EMAIL PROTECTED] writes: I'm trying to move large files from one filesystem to another and the mv command fails with the message File size limit exceeded. The partial destination file is not removed and is 4,294,967,295 bytes in size. Most likely that's not a bug in mv; it's a problem with your user limits. If you're running Bash, type ulimit -a. mv is subject to these limits, just like any other program is. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv command fails on files 4GB
Paul Eggert wrote: Rich Morgan [EMAIL PROTECTED] writes: I'm trying to move large files from one filesystem to another and the mv command fails with the message File size limit exceeded. The partial destination file is not removed and is 4,294,967,295 bytes in size. Most likely that's not a bug in mv; it's a problem with your user limits. If you're running Bash, type ulimit -a. mv is subject to these limits, just like any other program is. It could also be trying to move the file from e.g. ext2/3 to a brain-dead filesystem (e.g. FAT32) which has a 4GB limit. That's also not something that mv can deal with, it's a limitation of the filesystem that cannot be avoided. Brian ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv (coreutils) 5.2.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please post questions about coreutils to the bug-coreutils list, as requested in the 'mv --help' output, rather than sending private mail to just one of the developers. You will then be more likely to get an answer by someone who knows (the collective knowledge of list subscribers is greater than that of the developer you randomly choose), and your question and answer will be archived for future reference so that people can find it via a web search. According to Debarshi Ray on 12/7/2005 6:38 AM: I know this may sound stupid, but is it so that the mv command (5.2.1) does not overwrite pre-existing directories? I am asking this, since the following command: $ mv /tmp/a ~/ gives an error message complaining that it can not overwrite /home/rishi/a, where a is a directory present in /home/rishi as well as in /tmp. Coreutils 5.2.1 is old - the latest stable version is 5.93 (http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00058.html). Consider upgrading. Meanwhile, the behavior you are asking about is required by POSIX (http://www.opengroup.org/onlinepubs/009695399/utilities/mv.html). - -- 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 iD8DBQFDluoo84KuGfSFAYARAqZ2AJ9N9GGCM8CA3eRTzvyuoIsxSbIuRwCfaY4P 9VOrVBHmLTkXij0+ar6JjJ8= =ImKd -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv bug
On Wed, 7 Dec 2005, Vincent Chan wrote: I have a bunched of files in a directory and there are a.avi and a.rar in it. Inside the directory, there is also a directory called a. I wanted to type mv a.* a. But instead I typed mv a.* by mistake. As a result, I can't find the original a.rar anymore, but I found that it renamed a.avi to a.rar. Why? This behaviour is caused not by mv itself, but the actions of the shell expanding the a.* argument. Permit me to explain by example: $ echo a.* a.avi a.rar $ mv --verbose a.* `a.avi' - `a.rar' The shell passes the two separate filenames to mv, which interprets the arguments as a request to overwrite. To avoid this, you could create a shell alias such as: alias mv='mv -i' which will prompt the user in situations like this. Cheers, Phil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 11/30/2005 10:57 AM: It does appear that POSIX does not specify what should happen when you do this: mkdir new cd new touch a mv a b/c That is, if b does not exist, then rename(a, b/c) is not required to fail. That's very strange, but there's nothing in the existing language that requires it to fail. I read ENOTDIR: A component of either path prefix is not a directory as forbidding rename(a, b/c) when b does not exist. But yes, the wording earlier in the DESCRIPTION is weak, with the restriction only being that Write access permission is required for the directory containing old and the directory containing new, such that without the additional text under ENOTDIR you could argue that it is . that contains b/c rather than ./b containing c, since 'new' was b/c. Hence you are right: rename(a, b/) is not required to fail either. I view this as a defect in POSIX. rename(a, b/.) must fail since b/. has a trailing dot component I see no difference here. POSIX allows rename(a, b/.) to succeed, using the same logic as above. No. The resolution of XSH 108 explicitly requires failure if a trailing component is . or .., along with words in EINVAL to that effect. Therefore, I contend that rename(a, b/.) MUST fail, but that rename(a, b/) MAY fail or succeed, given the current wording as corrected by the defect report. This is similar to the issue that we discussed a couple months ago as to whether mkdir(b/, 0777) is allowed to succeed (even though mkdir(b/., 0777) must fail), and whether rmdir(b/) is allowed to succeed (even though rmdir(b/.) must fail. My argument remains that pathname resolution must treat b/ as b/. when determining that the filename exists and is a directory (or does not exist), but that when the trailing dot is not explicitly present, pathname resolution is only done to check the preconditions of the syscall, as opposed to the entire call treating a trailing slash the same as an implicit trailing dot. - -- 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 iD8DBQFDjvW484KuGfSFAYARAhATAKDSGoAi3419R/ugPoZhRdyIMdU/UgCfaUSo CAtxMJYV4xDM2X4M0x5bTBY= =kt0W -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
Hmm, I'm not familiar with that resolution. I looked for it in http://www.opengroup.org/austin/aardvark/finaltext/xshbug.txt and found that XSH Enhancement Request Number 108 talks about the y0() function. Perhaps you got the number wrong? Or am I looking in the wrong place? You are looking at the pre-2004 defects; try looking at the current ones http://www.opengroup.org/austin/aardvark/latest/xshbug2.txt or at my original link in my earlier email, http://lists.gnu.org/archive/html/bug-coreutils/2005-11/msg00301.html http://www.opengroup.org/austin/docs/austin_270.txt I filed it in September after the big debate on this list on the same topic, see the thread here: http://lists.gnu.org/archive/html/bug-coreutils/2005-09/msg00203.html -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
[EMAIL PROTECTED] (Eric Blake) writes: You are looking at the pre-2004 defects; try looking at the current ones http://www.opengroup.org/austin/aardvark/latest/xshbug2.txt But ERN 108 in that URL refers to what happens with rename(a, b/.), which obviously should fail. It doesn't really address the issue of what should happen with rename(a, b/). I agree that this entire area is murky, underspecified, and differs in surprising ways on various systems. What a pain. (Somebody should clean it up. :-) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 11/29/2005 11:16 PM: No, because POSIX requires that Write access permission is required for the directory containing 'old' and the directory containing 'new'. Here 'new' is b/, which is equivalent to b/.. So the directory containing 'new' is b. But b does not exist, so 'rename' can't have write access to it. I disagree. Your quote came from the EACCES text, not the DESCRIPTION; and I claim that if rename(a, b/) is to fail because b/ doesn't exist, it should fail with ENOTDIR or ENOENT, not EACCES. My argument is that 'new' being b/ is DIFFERENT than b/.. During pathname resolution, the two are treated the same, but pathname resolution is only used up to the point where it is determined that b/. does not name a non-directory (since b does not yet exist). From there, POSIX no longer requires pathname resolution, so I maintain that Linux is still POSIX-compliant by allowing rename(a, b/) to succeed, but that rename(a, b/.) must fail since b/. has a trailing dot component (and because the parent of b/. does not exist). We should probably bring this up on the austin mailing list. This was also discussed recently in light of my defect XSH ERN 108, http://www.opengroup.org/austin/docs/austin_270.txt. As far as changing 'mv' goes, I see two competing goals here: A. Have 'mv' conform to POSIX even if 'rename' does not. B. Have 'mv' do whatever 'rename' does, even if 'rename' does not conform to POSIX. We should pick either (A) or (B). We can't do both at the same time. We shouldn't do (A) for non-directories and (B) for directories (which seems to be what's being proposed here). I'd be happy to help with either (A) or (B). Personally I have a mild preference for (B) since it's easier to implement (and it lets us blame the kernel guys if some POSIX pedant bugs us :-). I also would favor (B). But we certainly need testsuite additions to ensure that we don't introduce future regressions against this decision. - -- 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 iD8DBQFDjbhN84KuGfSFAYARAgkxAJ9CEeKzwVGb0Oqv8BCySIxWaEu8PwCglDiX xsyLzPt8bJXj0p8s1/QmZy0= =WmAz -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
Eric Blake [EMAIL PROTECTED] writes: I maintain that Linux is still POSIX-compliant by allowing rename(a, b/) to succeed It does appear that POSIX does not specify what should happen when you do this: mkdir new cd new touch a mv a b/c That is, if b does not exist, then rename(a, b/c) is not required to fail. That's very strange, but there's nothing in the existing language that requires it to fail. Hence you are right: rename(a, b/) is not required to fail either. I view this as a defect in POSIX. rename(a, b/.) must fail since b/. has a trailing dot component I see no difference here. POSIX allows rename(a, b/.) to succeed, using the same logic as above. We should probably bring this up on the austin mailing list. Yes, probably. B. Have 'mv' do whatever 'rename' does, even if 'rename' does not conform to POSIX. I also would favor (B). But we certainly need testsuite additions to ensure that we don't introduce future regressions against this decision. OK, it'll be harder to test (B), since that relies on the test suite knowing what rename() does. But I guess we can work around that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
Paul Eggert [EMAIL PROTECTED] wrote: I also would favor (B). But we certainly need testsuite additions to ensure that we don't introduce future regressions against this decision. OK, it'll be harder to test (B), since that relies on the test suite knowing what rename() does. But I guess we can work around that. It shouldn't be hard. Just run a little perl snippet to determine what rename() does, and base the expected results on that. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
[EMAIL PROTECTED] (Bob Proulx) wrote: Jim Meyering wrote: Paul Eggert [EMAIL PROTECTED] wrote: I also would favor (B). But we certainly need testsuite additions to ensure that we don't introduce future regressions against this decision. OK, it'll be harder to test (B), since that relies on the test suite knowing what rename() does. But I guess we can work around that. It shouldn't be hard. Just run a little perl snippet to determine what rename() does, and base the expected results on that. A problem exists with configure testing for kernel behavior and then Whoops. Stop right there ;-) We're talking about the test suite performing a test of kernel behavior, so that it (the test suite for mv) knows which rename() semantics are in effect. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
Jim Meyering wrote: Bob Proulx wrote: Jim Meyering wrote: Paul Eggert wrote: OK, it'll be harder to test (B), since that relies on the test suite knowing what rename() does. But I guess we can work around that. It shouldn't be hard. Just run a little perl snippet to determine what rename() does, and base the expected results on that. A problem exists with configure testing for kernel behavior and then Whoops. Stop right there ;-) We're talking about the test suite performing a test of kernel behavior, so that it (the test suite for mv) knows which rename() semantics are in effect. Oops. I got out of sync reading the commentary and thought this was about configuring behavior of 'mv' and not testing the behavior. Now I feel foolish for having said all of that. I will get some sleep now. But just in case there is a suggestion to configure test for kernel behavior and then freeze it into the code then I am ready with my refutation! :-) Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
Note that the underlying rename would fail on Linux 2.6.x and *BSD (but it'd succeed on Solaris 9 and 10): $ touch a; rm -rf b; perl -e 'rename a, b/ or die $!' The difference is whether a is a directory or a regular file. When a is not a directory, I would expect rename(a, b/) to fail because it would attempt to create a directory (although that may be a defect in POSIX for not explicitly mentioning this case). But when a is a directory, I see no reason why rename cannot succeed. Not a directory at -e line 1. [Exit 20] Currently, mv detects this particular `problem' without performing an actual rename, so it's more consistent than it would be if it were relying on the actual system call. Which problem, the issue of moving a non-directory into something that looks like a directory because of the trailing slash, or the issue of moving a directory to another looks-like-a-directory? -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
Tim Waugh [EMAIL PROTECTED] wrote: On Tue, Nov 29, 2005 at 05:24:32PM +0100, Jim Meyering wrote: Note that the underlying rename would fail on Linux 2.6.x and *BSD (but it'd succeed on Solaris 9 and 10): No, you're looking at a different case: $ touch a; rm -rf b; perl -e 'rename a, b/ or die $!' Not a directory at -e line 1. [Exit 20] Certainly if a is a regular file I wouldn't expect this to work, and in fact it does not work on Linux with coreutils-5.2.1 either. The particular case I wanted to raise awareness of is when a is a directory. I see, now. Thanks. *That* is a bug. Ouch. And it needs to be fixed in coreutils-5.94. If someone feels like preparing a patch along with ChangeLog entries, NEWS, and test cases, I won't complain. The problem is the strip_trailing_slashes (dest) call in mv.c. It may need to be removed altogether, and the new behavior documented. Otherwise, rm -rf a; touch a; mv a b/ will mistakenly succeed on Linux-based systems. Testing how the underlying rename function handles this case will be tricky, since you'll get different results on e.g., Solaris 7 and earlier. Note that the --strip-trailing-slashes option affects only source file names. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
Eric Blake [EMAIL PROTECTED] writes: I read that as rename() sees that a is a directory, so it resolves b/ as b/. to ensure that b/ is not the pathname of a non-directory (it isn't, since b/. does not exist), then can go ahead No, because POSIX requires that Write access permission is required for the directory containing 'old' and the directory containing 'new'. Here 'new' is b/, which is equivalent to b/.. So the directory containing 'new' is b. But b does not exist, so 'rename' can't have write access to it. As far as changing 'mv' goes, I see two competing goals here: A. Have 'mv' conform to POSIX even if 'rename' does not. B. Have 'mv' do whatever 'rename' does, even if 'rename' does not conform to POSIX. We should pick either (A) or (B). We can't do both at the same time. We shouldn't do (A) for non-directories and (B) for directories (which seems to be what's being proposed here). I'd be happy to help with either (A) or (B). Personally I have a mild preference for (B) since it's easier to implement (and it lets us blame the kernel guys if some POSIX pedant bugs us :-). ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv a b/ when b does not exist
Tim Waugh [EMAIL PROTECTED] writes: rm -rf a b mkdir a mv a b/ fails on Linux with coreutils-5.93: mv: target `b/' is not a directory: No such file or directory In previous releases (such as 5.2.1) it has worked. The rename() call is also happy with the trailing slash. Is this a regression, or an intentional change? As I understand it, POSIX says that mv a b/ is equivalent to rename(a, b/), and that the latter should fail when the directory b does not exist. So the old mv behavior did not conform to POSIX, and the new mv behavior does. Admittedly it is a murky area. One could argue that if Linux rename(a, b/) works (contrary to POSIX), then mv should defer to rename and contradict POSIX as well. For what it's worth, Solaris 10 mv and OpenBSD 3.4 mv behave the old way, so there is a sideways-compatibility argument here as well. (I could possibly be responsible for the change; I don't recall offhand right now) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv do not preserves default acls
[EMAIL PROTECTED] wrote: I think there is a bug in the mv command. New files created by mv do not inherit their parent directory's default ACL entries (if any), but retain their original ACLs. I have tested this behavoir on different distributions and filesystems supporting acls. We haven't integrated support for ACLs, yet. There are patches being used by several distributions. If there's interest, I'll begin distributing one of those patch sets -- and keeping it in sync -- so people don't have to struggle through merges all the time. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Eric Blake [EMAIL PROTECTED] wrote: According to Dr. David Alan Gilbert on 9/26/2005 11:17 AM: $ mkdir a b $ ln -s $PWD/a sym $ mv sym/ b mv: cannot move `sym/' to `b/sym': Not a directory Nod. Perhaps the warning needs a warning that it can't be relied on? No, POSIX requires rename(sym/, name) to move the directory, not the symlink, so the warning is accurate and should apply to all systems, whether or not their rename is conformant. You may also want to check what `type mv` prints, in case you have an alias in place that strips trailing slashes. As you can imagine, I find the POSIX-required behavior to be senseless. The above behavior of non-POSIX rename, seen on Linux-2.6.x, is fine. Now that Linux/glibc provides a sane rename function, I'm tempted to make mv work in the above manner on all systems rather than allowing the crazy move-pointed-to-directory behavior on systems with a technically-conforming rename. The wrapper will incur the expense of a syscall or two on losing systems when the first argument ends with `/'. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Jim Meyering [EMAIL PROTECTED] writes: As you can imagine, I find the POSIX-required behavior to be senseless. Two things. First, I recall that you preferred the non-POSIX behavior because of file name completion issues. But because we agitated about this a while ago, Bash now does a better job with file name completion. For example, given this: mkdir dir ln -s dir symlink If I type mv sym[TAB], where [TAB] stands for a tab character, the screen then looks like this: mv symlink If I type another [TAB] it then looks like this: mv symlink/ so I'm given a signal from Bash that I have a symlink to a directory, and that it matters whether there's a trailing slash. In the old days this didn't happen, the intermediate step was missing, and so there was more of an argument that mv symlink/ target should ignore the slash. Nowadays, though, isn't that argument weaker? Second, I just read the POSIX spec and it seems to be a bit buggy http://www.opengroup.org/onlinepubs/009695399/functions/rename.html. The rationale says Renaming dot or dot-dot is prohibited but I can't see anything to that effect in the text itself. Furthermore, POSIX says that a pathname like abc/ must be resolved as if it were abc/. (see http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11) so arguably rename(abc/, def) must be handled like rename(abc/., def) and if renaming dot or dot-dot is prohibited (which I think it must be, even if it's omitted inadvertently from the standard) then this must fail. There's a similar issue with rmdir symlink/. It's not clear that rmdir (symlink/) should succeed, because pathname resolution indicates that it should be treated like rmdir (symlink/.) and this clearly must fail. Clearly it's a messy area. My kneejerk reaction is that I might prefer it if mv symlink/ foo and rmdir symlink/ always failed, if only because in a confusing situation like this it's often better to use the Hippocratic rule: first, do no harm. It would be easy to implement that rule: it wouldn't require any system calls at all, since we could simply reject all file names with trailing slashes. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
[cc-ing bash-completion maintainer] First, I recall that you preferred the non-POSIX behavior because of file name completion issues. But because we agitated about this a while ago, Bash now does a better job with file name completion. For example, given this: mkdir dir ln -s dir symlink If I type mv sym[TAB], where [TAB] stands for a tab character, the screen then looks like this: mv symlink If I type another [TAB] it then looks like this: mv symlink/ This assumes, of course, that you don't have 'set mark-symlinked-directories on' in your ~/.inputrc, at which point a single [TAB] completes the trailing slash. On the other hand, with the bash-completion package, it might make sense for programmable completion for mv, cp, and rm to omit the trailing slash in spite of the mark-symlinked-directories setting. The only argument against this is that there is no way to know whether the user really meant to move (or copy or delete) the symlink to a directory, vs. a file located in the directory, until they move on to the next word or hit Enter. This was the entire reason that mark-symlinked-directories exists in readline, and --strip-trailing-slashes exists as an option to mv and cp. On a related note, why don't rm and rmdir have a --strip-trailing-slashes option? so I'm given a signal from Bash that I have a symlink to a directory, and that it matters whether there's a trailing slash. Second, I just read the POSIX spec and it seems to be a bit buggy http://www.opengroup.org/onlinepubs/009695399/functions/rename.html. The rationale says Renaming dot or dot-dot is prohibited but I can't see anything to that effect in the text itself. Agreed - we should bring this up with the austin group. Something along the lines of this statement from rmdir(): If the path argument refers to a path whose final component is either dot or dot-dot, rmdir() shall fail. ... [EINVAL] The path argument contains a last component that is dot. Furthermore, POSIX says that a pathname like abc/ must be resolved as if it were abc/. (see http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_1 1) so arguably rename(abc/, def) must be handled like rename(abc/., def) and if renaming dot or dot-dot is prohibited (which I think it must be, even if it's omitted inadvertently from the standard) then this must fail. I agree with your logic here on rename(2) needing to fail on a trailing slash if it is also supposed to fail on a trailing dot. But that doesn't necessarily mean that mv(1) need to fail on a trailing slash or dot. There's a similar issue with rmdir symlink/. It's not clear that rmdir (symlink/) should succeed, because pathname resolution indicates that it should be treated like rmdir (symlink/.) and this clearly must fail. Oops - cygwin has a bug in this regards: $ mkdir dir $ rmdir dir/. $ echo $? 0 $ ls dir ls: dir: No such file or directory Is it worth patching coreutils rm and rmdir to work around buggy systems that don't follow this POSIX restriction on rmdir()? (Meanwhile, I will try to get cygwin fixed.) Should we update the coreutils testsuite? My kneejerk reaction is that I might prefer it if mv symlink/ foo and rmdir symlink/ always failed, if only because in a confusing situation like this it's often better to use the Hippocratic rule: first, do no harm. It would be easy to implement that rule: it wouldn't require any system calls at all, since we could simply reject all file names with trailing slashes. You could probably convince me that your proposed approach of always rejecting an operation with a trailing slash is valid, as long as the error message gives a hint to the user on how to do what they wanted, and as long as --strip-trailing-slashes still worked. On the other hand, since 'mv symlink/ foo' invokes underspecified behavior in rename(2), maybe we can get away with deciding that mv(1) always behaves as --strip-trailing-slashes - is there anything in POSIX that would prohibit us from always stripping the trailing slash and acting on the symlink without an explicit option requesting that behavior? -- Eric Blake ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Paul Eggert [EMAIL PROTECTED] wrote: Jim Meyering [EMAIL PROTECTED] writes: As you can imagine, I find the POSIX-required behavior to be senseless. Two things. First, I recall that you preferred the non-POSIX behavior because of file name completion issues. But because we agitated about this a That was indeed a motivator, since it made the commands with ambiguous syntax more likely. while ago, Bash now does a better job with file name completion. For example, given this: ... and so there was more of an argument that mv symlink/ target should ignore the slash. Nowadays, though, isn't that argument weaker? Even if bash fixes things to make this less likely, there's still plenty of room for user error and confusion, especially since less-seasoned users still use shells that cannot -- or are not configured to -- clean up the syntax of their commands. Personally, this hasn't affected me for some time (since I switched to zsh). zsh can be configured so that it completes the trailing slash in I type mv symliTAB zsh does this: mv symlink/ But the moment I type the space after the zsh-added `/', zsh removes that slash. If I type the slash, zsh leaves it. That said, I looked in some old command history logs and see hundreds of commands I typed (back before using zsh) including trailing slashes like this: mv dir/ new-name I know lots of people who would be very annoyed if they had to change habits or even just add an option via an alias to avoid failure in cases like those. Second, I just read the POSIX spec and it seems to be a bit buggy http://www.opengroup.org/onlinepubs/009695399/functions/rename.html. The rationale says Renaming dot or dot-dot is prohibited but I can't see anything to that effect in the text itself. Furthermore, POSIX says that a pathname like abc/ must be resolved as if it were abc/. (see http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap04.html#tag_04_11) so arguably rename(abc/, def) must be handled like rename(abc/., def) and if renaming dot or dot-dot is prohibited (which I think it must be, even if it's omitted inadvertently from the standard) then this must fail. There's a similar issue with rmdir symlink/. It's not clear that rmdir (symlink/) should succeed, because pathname resolution indicates that it should be treated like rmdir (symlink/.) and this clearly must fail. Clearly it's a messy area. My kneejerk reaction is that I might prefer it if mv symlink/ foo and rmdir symlink/ always failed, if only because in a confusing situation like this it's often better to use the Hippocratic rule: first, do no harm. It would be easy to implement that rule: it wouldn't require any system calls at all, since we could simply reject all file names with trailing slashes. IMHO, such a move [making mv fail for any source argument specified with a trailing slash] would `do harm' :-) albeit to people's sensibilities when GNU mv starts griping, not to their files. I think the wrapper-induced overhead of an extra lstat imposed on losing systems, but only for operands with a trailing slash, is bearable. This is one of those `would be nice' things. But I'm not in any big hurry, since Linux 2.6.x does it right. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
[EMAIL PROTECTED] (Eric Blake) writes: Why don't rm and rmdir have a --strip-trailing-slashes option? I'd guess because that option is an ugly hack and we'd rather that the problem went away we should bring this up with the austin group. Perhaps, but let's figure out what we want first. I agree with your logic here on rename(2) needing to fail on a trailing slash if it is also supposed to fail on a trailing dot. But that doesn't necessarily mean that mv(1) need to fail on a trailing slash or dot. But POSIX says mv a/ b does the equivalent of rename(a/, b). So if you agree with the logic, then mv a/ b must fail. Oops - cygwin has a bug in this regards: $ mkdir dir $ rmdir dir/. $ echo $? 0 $ ls dir ls: dir: No such file or directory Is it worth patching coreutils rm and rmdir to work around buggy systems that don't follow this POSIX restriction on rmdir()? Naah, let's just get cygwin fixed. On the other hand, since 'mv symlink/ foo' invokes underspecified behavior in rename(2), maybe we can get away with deciding that mv(1) always behaves as --strip-trailing-slashes POSIX may be underspecified, but it's not _that_ underspecified. :-) I think one could argue that mv symlink/ foo should rename the target of the symlink (which is what Solaris does), or that it should fail (which is what I'd mildly prefer); but I don't see a way to read POSIX to say that it allows mv to ignore the slash. Note that, by this argument, mv dir/ foo should fail even if dir/ is an ordinary directory and is not a symlink. So it'd be kind of a big change. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
[EMAIL PROTECTED] (Eric Blake) wrote: As you can imagine, I find the POSIX-required behavior to be senseless. The above behavior of non-POSIX rename, seen on Linux-2.6.x, is fine. Now that Linux/glibc provides a sane rename function, I'm tempted to make mv work in the above manner on all systems rather than allowing the crazy move-pointed-to-directory behavior on systems with a technically-conforming rename. The wrapper will incur the expense of a syscall or two on losing systems when the first argument ends with `/'. If you do that, you need to make sure POSIXLY_CORRECT still gets the POSIX behavior of move-pointed-to-directory. But Not if I deem that behavior senseless :-) Can you imagine any real user (non-standards-weenie) *wanting* or even expecting that behavior? The few people I've shown that example to in person have always looked a little slack-jawed and expressed dismay that such silly behavior is mandated. wasn't this the reason that --strip-trailing-slashes was created as an option? That way, a user can do alias mv='mv --strip-trailing-slashes' and get the sane behavior of always moving the symlink, not the pointed-to-directory, regardless of whether rename() is conformant or not, and regardless of whether their shell's tab-completion puts slashes on symlinks-to-directories. Right. But as long as Linux's rename had the unwanted behavior, I was unwilling to impose the overhead of a wrapper. Now that constraint is removed. Meanwhile, since you think that the POSIX definition of rename() is insane, try filing an aardvark to allow an implementation-defined choice between moving the symlink/moving the directory, rather than the current mandated semantics of moving the directory. That way, Linux 2.6.x would still be able to comply to POSIX with what you term to be saner semantics (personally, I like the POSIX-mandated semantics, as it provides a consistent way to choose between operating on the symlink vs. operating on what it points to by the presence of the trailing slash, and it is not just rename() that is affected by POSIX semantics). Or you could file an aardvark on mv(1) to allow an implementation to always strip trailing slashes before calling rename(). I don't want to give myself that kind of work right now. Besides, I don't lose sleep if a GNU tool or two deviate from POSIX on corner cases like this. One way or another, we'll all converge, eventually. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
On a related note, why don't rm and rmdir have a --strip-trailing-slashes
option?
Because as far as I know, there is no need.
Do you know of a system where `rmdir symlink/'
removes only the referent of the symlink?
Yes, cygwin (but again, that goes back to the rmdir(2) bug
in cygwin that I have just reported to the cygwin maintainers):
$ mkdir a
$ ln -s a b
$ rmdir b/
$ ls -F a b
ls: a: No such file or directory
b@
Whereas on sane systems (for example, Solaris 8):
$ mkdir a
$ ln -s a b
$ rmdir b/
rmdir: directory b/: Path component not a directory
$ rmdir b/.
rmdir: directory b/.: Can't remove current directory or ..
By Paul's argument, both uses should have failed with
EINVAL, since POSIX requires resolving symlink/ as
symlink/., and requires rmdir(symlink/. to fail with
EINVAL. Solaris 8 returned ENOTDIR in the first case, so
it appears they stripped the trailing slash (and their error
message leaves something to be desired in accuracy in
the second case). But at least it reliably failed instead
of removing a. I don't have access to other systems to
see what other behaviors might exist.
Is it worth patching coreutils rm and rmdir to work around buggy
systems that don't follow this POSIX restriction on rmdir()? (Meanwhile,
I will try to get cygwin fixed.) Should we update the coreutils testsuite?
It depends a whole lot on how invasive or complicated the patch is.
Ideally, it wouldn't change anything in src/*.c at all.
If cygwin doesn't get patched, it sounds like a gnulib module
to replace rmdir() is all that would be needed. Something like
this untested snippet (it would need to be cleaned up for
corner cases like , /, ., but you get the picture):
int
rpl_rmdir(const char* name)
{
int len = strlen (name);
if (name[len - 1] == '/'
|| (name[len - 1] == '.'
(name[len - 2] == '/'
|| (name[len - 2] == '.' name[len - 3] == '/'
{
errno = EINVAL;
return -1;
}
return rmdir (name);
}
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Jim Meyering [EMAIL PROTECTED] writes: Do you know of a system where `rmdir symlink/' removes only the referent of the symlink? Lots of systems do that, I expect. Solaris 10 does, for example. This is either with Solaris rmdir or coreutils 5.3.0 rmdir. I wouldn't be surprised if core commands other than mv and rmdir are affected by this issue as well. rm and ln come to mind, though I haven't tested them. Here's a transcript on Solaris 10 (sparc) with coreutils 5.3.0: 1018-otter $ ls -l total 2 drwxrwxr-x 2 eggert faculty 512 2005-09-28 15:18 dir lrwxrwxrwx 1 eggert faculty 3 2005-09-28 15:18 symlink - dir 1019-otter $ rmdir symlink/ 1020-otter $ ls -l total 1 lrwxrwxrwx 1 eggert faculty 3 2005-09-28 15:18 symlink - dir ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Jim Meyering [EMAIL PROTECTED] writes: I think the wrapper-induced overhead of an extra lstat imposed on losing systems, but only for operands with a trailing slash, is bearable. This is one of those `would be nice' things. But I'm not in any big hurry, since Linux 2.6.x does it right. Yes, I wouldn't be in any hurry either. Come to think of it, how about if we just stick to the current approach, and let 'mv' use the system rename() function and do whatever rename() does? Advantages of the current approach: * Easier to implement and maintain. * Solaris folks used to Solaris mv's behavior won't be surprised by GNU mv. * GNU mv conforms to POSIX, on POSIX-conforming hosts. (On non-POSIX hosts all bets are off anyway. :-) Disadvantages: * GNU mv behaves differently on different hosts. Similarly for rmdir and rmdir(), etc. I suppose either way, the eocumentation needs to explain the issue better. (Arrgh.) ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
On a related note, why don't rm and rmdir have a --strip-trailing-slashes
option?
Because as far as I know, there is no need.
Do you know of a system where `rmdir symlink/'
removes only the referent of the symlink?
By a strict reading of
http://www.opengroup.org/onlinepubs/009695399/utilities/rm.html,
'rm -R symlink/' should empty the referrant, then fail!
step 0: the command line does not end in .
step 1: symlink/ exists
step 2: 'symlink/' is of type directory ('symlink', on the other hand,
is of type symlink); this is the recursion, ending with the
referrant being emptied, and symlink and symlink/ still existing
step 3: 'symlink/' is a directory
step 4: call rmdir(symlink/), which should fail with EINVAL
But no implementation of rm(1) that I am aware of does this;
they all unlink symlink and call it quits, leaving the referrant
(and its contents) alone. We really do need to clean this up
with the austin group; surely they intended to document
historical behavior.
--
Eric Blake
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
* Jim Meyering ([EMAIL PROTECTED]) wrote: $ mkdir a b $ ln -s $PWD/a sym $ mv sym/ b mv: cannot move `sym/' to `b/sym': Not a directory The 'mv' is straight out of recent cvs. I'm in an ext3 filesystem on Linux (Ubuntu). Am I misunderstanding something about that warning or is this a bug? It depends on the semantics of the rename syscall. And those semantics vary from system to system. On older linux systems (probably 2.4.x, certainly 2.2.20, which I've just tested) your mv command renames `a' to b/sym. OK, as far as I can tell on the 2.6.x machines I've tried it on it doesn't. Losing systems probably deserve a configure-time test and a rename wrapper to correct for the unexpected behavior. Nod. Perhaps the warning needs a warning that it can't be relied on? Dave -- -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv trailing slash warning
Dr. David Alan Gilbert [EMAIL PROTECTED] wrote: In the info pages for 'mv' is the following statement: --- _Warning_: If you try to move a symlink that points to a directory, and you specify the symlink with a trailing slash, then `mv' doesn't move the symlink but instead moves the directory referenced by the symlink. *Note Trailing slashes::. --- ... $ mkdir a b $ ln -s $PWD/a sym $ mv sym/ b mv: cannot move `sym/' to `b/sym': Not a directory The 'mv' is straight out of recent cvs. I'm in an ext3 filesystem on Linux (Ubuntu). Am I misunderstanding something about that warning or is this a bug? It depends on the semantics of the rename syscall. And those semantics vary from system to system. On older linux systems (probably 2.4.x, certainly 2.2.20, which I've just tested) your mv command renames `a' to b/sym. Losing systems probably deserve a configure-time test and a rename wrapper to correct for the unexpected behavior. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv --reply=no doesn't work well
Thomas Rachel wrote: I recently deteted that if I use mv --reply=no, it doesn't behave as if I pressed 'n' on mv -i. This has become a hot topic. Please read this thread to catch up on the happenings. http://lists.gnu.org/archive/html/bug-coreutils/2005-06/msg00160.html Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv --reply=no overwrites files
Christian Boltz wrote: I just found a bug in mv: it overwrites files even when --reply=no is given (which should never overwrite existing files according to the documentation). This has become a hot topic. Please read this thread to catch up on the happenings. http://lists.gnu.org/archive/html/bug-coreutils/2005-06/msg00160.html Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv datebug in mv (coreutils) 5.2.1
[EMAIL PROTECTED] wrote: The date bug of mv is still present in mv (coreutils) 5.2.1 distributed with Fedore Core 3. When superuser moves a directory into a another directory, the date of the former directory changes to the current date. The date of the directory is updated whenever there is a change in the contents. One of the files in the directory is the .. entry. The .. entry points to the parent of the current directory. Moving a directory will cause the previous .. to be replaced with a new and different .. file. Therefore the timestamp is updated. This is not a bug. This is correct behavior. Here is an example. mkdir /tmp/adir1 mkdir /tmp/adir2 mkdir /tmp/adir1/anotherdir ls -ldiog /tmp/adir1/anotherdir/.. 1068004 drwxr-xr-x 3 80 2005-06-13 00:08 /tmp/adir1/anotherdir/.. mv /tmp/adir1/anotherdir /tmp/adir2/ ls -ldiog /tmp/adir2/anotherdir/.. 1141039 drwxr-xr-x 3 80 2005-06-13 00:09 /tmp/adir2/anotherdir/.. Note the change in inode numbers. The .. entry is updated to point to the new parent directory. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv -f may remove the destination file
Paul Eggert wrote: Urs Thuermann [EMAIL PROTECTED] writes: lstat64(bar, 0xb904) = -1 ENOENT (No such file or directory) rename(foo, bar)= 0 This check, however, is not sufficient as a file named bar could be created between the calls to lstat(2) and rename(2). In general, mv is not (and is not supposed to be) immune to race conditions like that. If two processes are futzing around in the same directory, bad things normally can happen with the standard utilities. There are some exceptions, but this isn't one of them. Agreed. But I think the reason for the question might be for what purpose is the lstat() call there? It is there to tell if the destination is a directory and if so then it converts the rename to a rename to a file in the subdirectory, also as required by POSIX. With the -f the code does not need to care if the target is writable or not but regardless it needs to know if it is a directory or not. I don't think it is possible to avoid using multiple system calls and still have correct 'mv' behavior and so it is not possible to avoid the race either. The rename(2) call will not automatically handle directories as destinations, but 'mv' must. Bob ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv -f may remove the destination file
[EMAIL PROTECTED] (Bob Proulx) writes: I think the reason for the question might be for what purpose is the lstat() call there? It is there to tell if the destination is a directory and if so then it converts the rename to a rename to a file in the subdirectory, also as required by POSIX. There are actually two lstat calls; one for the directory, and one for the existing-destination check. Presumably one could be optimized away, if someone is ambitious. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv -f may remove the destination file
Urs Thuermann [EMAIL PROTECTED] writes: $ strace mv foo bar Hmm, your email's Subject: line says mv -f but this strace doesn't. I'll assume for now that you meant to write about plain mv, not mv -f. lstat64(bar, 0xb904) = -1 ENOENT (No such file or directory) rename(foo, bar)= 0 This check, however, is not sufficient as a file named bar could be created between the calls to lstat(2) and rename(2). In general, mv is not (and is not supposed to be) immune to race conditions like that. If two processes are futzing around in the same directory, bad things normally can happen with the standard utilities. There are some exceptions, but this isn't one of them. If the source is not a directory, a better solution, suggested in comp.unix.internals, is to use link(2) But POSIX requires mv to behave as if it called rename(), not link(). See http://www.opengroup.org/onlinepubs/95399/utilities/mv.html. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv and hard links
[EMAIL PROTECTED] (Eric Blake) wrote:
This may be worthy of raising an issue with the austin group, but I
thought I'd ask here first. A complaint was raised on the cygwin list
that the following sequence had no interactive prompt:
$ uname
CYGWIN_NT-5.0
$ touch a
$ ln a b
$ mv -i a b
$ echo $?
0
$ mv --version | head -n 1
mv (GNU coreutils) 5.3.0
Thanks for forwarding that.
It's a bug.
Here's a patch:
Prompt once again for `mv -i A B' when A and B are hard links
to the same file. This fixes a bug introduced by my 2003-04-04
(coreutils-5.0.1) change.
* src/copy.c (abandon_move): New function, factored out of
copy_internal, now that this code is being used from two places.
(copy_internal): Perform the same interactive-related test for
whether it's alright to proceed and (usually) overwrite the
destination file.
Index: src/copy.c
===
RCS file: /fetish/cu/src/copy.c,v
retrieving revision 1.175
diff -u -p -r1.175 copy.c
--- src/copy.c 1 Mar 2005 12:27:47 - 1.175
+++ src/copy.c 10 Mar 2005 21:20:51 -
@@ -792,6 +792,28 @@ record_file (Hash_table *ht, char const
}
}
+/* When effecting a move (e.g., for mv(1)), and given the name DST_PATH
+ of the destination and a corresponding stat buffer, DST_SB, return
+ true if the logical `move' operation should not proceed.
+ Return true if it may proceed.
+ Depending on options specified in X, this code may issue an
+ interactive prompt asking whether it's ok to overwrite DST_PATH. */
+static bool
+abandon_move (const struct cp_options *x,
+ char const *dst_path,
+ struct stat const *dst_sb)
+{
+ assert (x-move_mode);
+ return ((x-interactive == I_ALWAYS_NO
+UNWRITABLE (dst_path, dst_sb-st_mode))
+ || ((x-interactive == I_ASK_USER
+ || (x-interactive == I_UNSPECIFIED
+x-stdin_tty
+UNWRITABLE (dst_path, dst_sb-st_mode)))
+ (overwrite_prompt (dst_path, dst_sb), 1)
+ ! yesno ()));
+}
+
/* Copy the file SRC_PATH to the file DST_PATH. The files may be of
any type. NEW_DST should be true if the file DST_PATH cannot
exist because its parent directory was just created; NEW_DST should
@@ -887,7 +909,8 @@ copy_internal (const char *src_path, con
x, return_now, unlink_src);
if (unlink_src)
{
- if (unlink (src_path))
+ if (!abandon_move (x, dst_path, dst_sb)
+ unlink (src_path))
{
error (0, errno, _(cannot remove %s), quote (src_path));
return false;
@@ -980,14 +1003,7 @@ copy_internal (const char *src_path, con
/* cp and mv treat -i and -f differently. */
if (x-move_mode)
{
- if ((x-interactive == I_ALWAYS_NO
- UNWRITABLE (dst_path, dst_sb.st_mode))
- || ((x-interactive == I_ASK_USER
- || (x-interactive == I_UNSPECIFIED
- x-stdin_tty
- UNWRITABLE (dst_path, dst_sb.st_mode)))
- (overwrite_prompt (dst_path, dst_sb), 1)
- ! yesno ()))
+ if (abandon_move (x, dst_path, dst_sb))
{
/* Pretend the rename succeeded, so the caller (mv)
doesn't end up removing the source file. */
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv fails with Too many open files when moving _many_ files
My patch of Monday (2004-10-18) was wrong.
Here's a fix that introduces fewer bugs.
I've added a test for the cross-partition mv failure
and another that makes rm fail with Monday's patch.
2004-10-21 Jim Meyering [EMAIL PROTECTED]
* tests/mv/leak-fd: New file.
* tests/mv/Makefile.am (TESTS): Add it.
* tests/rm/dot-rel: New file.
* tests/rm/Makefile.am (TESTS): Add it.
Correct my patch of 2004-10-18.
* src/remove.c (rm): Destroy the saved_cwd here (via cwd_state),
if necessary, not in remove_dir. Otherwise, removing multiple
`.'-relative nonempty directories no longer worked.
This highlights some minor duplication in the current code:
Since the changes of 2004-05-22, the u.saved_cwd member at
the bottom of the active-directory stack was no longer
strictly necessary. An upcoming change will remove that member.
Index: src/remove.c
===
RCS file: /fetish/cu/src/remove.c,v
retrieving revision 1.117
diff -u -p -r1.117 remove.c
--- src/remove.c18 Oct 2004 08:59:12 - 1.117
+++ src/remove.c21 Oct 2004 10:11:37 -
@@ -1151,10 +1151,7 @@ remove_dir (Dirstack_state *ds, char con
free (empty_dir);
if (AD_stack_height (ds) == 1)
- {
- free_cwd (AD_stack_top(ds)-u.saved_cwd);
- break;
- }
+ break;
}
}
@@ -1235,6 +1232,9 @@ rm (size_t n_files, char const *const *f
ds_free (ds);
+ if (cwd_state cwd_state-saved_errno == 0)
+free_cwd (cwd_state-saved_cwd);
+
free (cwd_state);
return status;
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv fails with Too many open files when moving _many_ files
Cyril Bouthors [EMAIL PROTECTED] wrote:
I'm having problems when moving everything from a directory that
contains 10852 top level directories and a total of ~30+ files and
subdirectories with this command:
Thanks a lot for that report.
It is indeed a bug.
Here's the fix:
Plug a leak that would cause rm or a cross-device mv to fail when
operating on too many command-line-specified nonempty directories.
* src/remove.c (remove_dir): Destroy the `struct saved_cwd' on the
top of the stack before returning. This usually closes the file
descriptor that was used to return to the original working directory.
Reported by Cyril Bouthors in
http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/3048
* NEWS: Mention it here.
Index: remove.c
===
RCS file: /fetish/cu/src/remove.c,v
retrieving revision 1.116
retrieving revision 1.117
diff -u -p -u -r1.116 -r1.117
--- remove.c22 Sep 2004 20:13:09 - 1.116
+++ remove.c18 Oct 2004 08:59:12 - 1.117
@@ -1151,7 +1151,10 @@ remove_dir (Dirstack_state *ds, char con
free (empty_dir);
if (AD_stack_height (ds) == 1)
- break;
+ {
+ free_cwd (AD_stack_top(ds)-u.saved_cwd);
+ break;
+ }
}
}
___
Bug-coreutils mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv fails with Too many open files when moving _many_ files
Paul Eggert [EMAIL PROTECTED] wrote: Here's how I reproduced it, both with coreutils 5.2.1 and with CVS coreutils. On my host, /tmp and /home are different file systems; this is a crucial part of the bug. ulimit -n 1024 cd /home/eggert/junk mkdir foo /tmp/foo cd foo for f in $(seq 1 1500); do mkdir $f; touch $f/f; done mv * /tmp/foo Thanks a lot for that small test case. Often, reproducing the problem is harder than coming up with a fix. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv fails with Too many open files when moving _many_ files
Cyril Bouthors wrote: I'm having problems when moving everything from a directory that contains 10852 top level directories and a total of ~30+ files and subdirectories with this command: # mv * ../../../webalizer-clients/ It fails with: mv: cannot create regular file `../../../webalizer-clients/bouthors/usage_200305.html': Too many open files Thanks for the report. It is much appreciated. However I am unable to reproduce the problem locally. I tried this to do so: mkdir /tmp/foo /tmp/bar cd /tmp/foo for f in $(seq 1 3);do touch $f;done mv * ../bar/ I tried both 5.2.1 and the latest 5.3.0 release image. You said you were using linux 2.6.6. What glibc version are you using? However, whenever you are moving a very large or unbounded number of files using a shell expanded glob character such as '*' you should be aware of exceeding the ARG_MAX kernel limitation. For example in my above case just removing that list of files will trigger the problem on my system. rm ./* -bash: /bin/rm: Argument list too long Let me suggest the following as an improvement. ls | xargs mv --target-directory=../../../webalizer-clients/ This works if the files all have normal names. For handling files with unusual characters it is always best to use null terminated strings. For this 'find' is best. I tend to use the short options but for clarity this following example has fully spelled out options suitable for a script. find . -maxdepth 1 -not -path . -print0 \ | xargs --no-run-if-empty --null mv --target-directory=/SOME/DIR/ Bob ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv fails with Too many open files when moving _many_ files
[EMAIL PROTECTED] (Bob Proulx) writes: I am unable to reproduce the problem locally. I think your attempt didn't capture all the relevant parts of the bug. Here's how I reproduced it, both with coreutils 5.2.1 and with CVS coreutils. On my host, /tmp and /home are different file systems; this is a crucial part of the bug. ulimit -n 1024 cd /home/eggert/junk mkdir foo /tmp/foo cd foo for f in $(seq 1 1500); do mkdir $f; touch $f/f; done mv * /tmp/foo The output is: mv: cannot create regular file `/tmp/foo/566/f': Too many open files mv: cannot create regular file `/tmp/foo/567/f': Too many open files mv: cannot create regular file `/tmp/foo/568/f': Too many open files ... ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: mv behaviour different than SuSv3
Never mind, my mistake. After reading the SuS spec another 10 times i realise i was taking parts out of context. Glenn ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: mv -i --reply=no ... acts like --reply=yes
Tim Waugh [EMAIL PROTECTED] wrote: With coreutils-5.2.1, I see unexpected behaviour with mv -i --reply=no: $ rm -rf x $ mkdir -p x/a x/b $ cd x $ echo a a/foo $ echo b b/foo $ mv -i --reply=no a/foo b/foo $ cat b/foo a That's because -i is equivalent to --reply=query (as mentioned in --help), and since you specify --reply=no after -i, the --reply=no takes precedence. The --reply=S option was added to ensure that this use of `mv' (note the absence of a -i option) touch a b; chmod u-w b; mv a b could be made to do its job without prompting the user. Without an option like --reply=yes, the above would prompt the user with e.g., `mv: overwrite `b', overriding mode 0444? Obviously, the descriptions (both --help and info) could be improved. Corrections welcomed. Though maybe the whole --reply=S addition deserves to be rethought. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: mv -i --reply=no ... acts like --reply=yes
Jim Meyering [EMAIL PROTECTED] wrote: Tim Waugh [EMAIL PROTECTED] wrote: $ echo a a/foo $ echo b b/foo $ mv -i --reply=no a/foo b/foo $ cat b/foo a That's because -i is equivalent to --reply=query (as mentioned in --help), and since you specify --reply=no after -i, the --reply=no takes precedence. I think that's what Tim expected. But b/foo was replaced with a/foo, in spite of --reply=no. The same thing happens for me with 5.2.1. paul ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: mv -i --reply=no ... acts like --reply=yes
On Thu, Apr 15, 2004 at 11:41:33AM -0400, Paul Jarc wrote: I think that's what Tim expected. But b/foo was replaced with a/foo, in spite of --reply=no. The same thing happens for me with 5.2.1. Well, I didn't expect --reply=no to override the -i; I had thought (without reading the documentation) that --reply applied to the questions that -i prompted. Now I see that for this specific case what I was doing was equivalent to 'mv a/foo b/foo' since b/foo is writable. It would have been nice if '-i --reply=no' did what '-u' does -- but now that I have read the documentation I can see why that isn't so. So the next question I have is: why does 'mv -i -u' prompt me? :-) Tim. */ pgp0.pgp Description: PGP signature ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: mv -i --reply=no ... acts like --reply=yes
[EMAIL PROTECTED] (Paul Jarc) wrote: Jim Meyering [EMAIL PROTECTED] wrote: Tim Waugh [EMAIL PROTECTED] wrote: $ echo a a/foo $ echo b b/foo $ mv -i --reply=no a/foo b/foo $ cat b/foo a That's because -i is equivalent to --reply=query (as mentioned in --help), and since you specify --reply=no after -i, the --reply=no takes precedence. I think that's what Tim expected. But b/foo was replaced with a/foo, in spite of --reply=no. The same thing happens for me with 5.2.1. But --reply=no has an effect only when there *would be* a prompt, and once the -i has been canceled out (and since the destination file is writable), there is no prompt. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: mv checks that fail...
I forgot to say that this is also on GNU/Hurd. Sorry for that. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: mv checks that fail...
Have you perhaps hacked ls.c so that it always prints the `author' name? Nope, this is a pristine checkout from CVS. ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: mv checks that fail...
Alfred M. Szmidt [EMAIL PROTECTED] wrote: From todays CVS the following test(s) fail (full log, so scroll down a bit): ... Have you perhaps hacked ls.c so that it always prints the `author' name? It seems like something like that is causing these differences: e.g., - 1 cp loc_reg rem_sl [cp: `loc_reg' and `rem_sl' are the same file ](loc_reg) (rem_sl - dir/loc_reg) + 1 cp loc_reg rem_sl [cp: `loc_reg' and `rem_sl' are the same file ](loc_reg) (02:28 rem_sl - dir/loc_reg) - 0 cp --rem -d loc_reg rem_sl (loc_reg) (rem_sl) + 0 cp --rem -d loc_reg rem_sl (loc_reg) (:28 rem_sl) *** expected-22938Wed Jun 18 02:28:33 2003 --- actual-22938 Wed Jun 18 02:28:33 2003 *** *** 1,33 ! 1 cp loc_reg rem_sl [cp: `loc_reg' and `rem_sl' are the same file ](loc_reg) (rem_sl - dir/loc_reg) 0 cp --rem loc_reg rem_sl (loc_reg) (rem_sl) ! 0 cp --rem -d loc_reg rem_sl (loc_reg) (rem_sl) ... --- 1,33 ! 1 cp loc_reg rem_sl [cp: `loc_reg' and `rem_sl' are the same file ](loc_reg) (02:28 rem_sl - dir/loc_reg) 0 cp --rem loc_reg rem_sl (loc_reg) (rem_sl) ! 0 cp --rem -d loc_reg rem_sl (loc_reg) (:28 rem_sl) ... ___ Bug-coreutils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-coreutils
Re: mv fails to move files
Jim Meyering [EMAIL PROTECTED] wrote:
Iida Yosiaki [EMAIL PROTECTED] wrote:
It seems for me that mv in coreutils 4.5.8 failes to move files
in a certain condition.
* How to reproduce the bug.
...
Thank you for the very nice bug report!
To reassure anyone who might be worrying about whether
this is serious, note that this happens only when hard-linked
files are moved (or copied with cp --preserve=link) onto existing
destination files without using a --backup option.
Your test actually exposed two problems:
* how does mv (and cp --preserve=link) handle existing destination
files that end up being the target of a link call?
* how is the dev/ino-filename mapping managed when a file with
more than one hard link cannot be copied/moved
Here's how I've fixed the first one.
...
And here's the fix for the second part:
* src/copy.c (copy_internal) [un_backup]: When recovering from a
failure to create a hard link, do not remove the entry associating
the source dev/ino with the destination file name.
* tests/mv/Makefile.am (TESTS): Add hard-3.
* tests/mv/hard-3: New test, for the above-fixed bug.
Inspired by a report from Iida Yosiaki.
Index: src/copy.c
===
RCS file: /fetish/cu/src/copy.c,v
retrieving revision 1.140
retrieving revision 1.141
diff -u -p -u -r1.140 -r1.141
--- src/copy.c 28 Feb 2003 21:36:18 - 1.140
+++ src/copy.c 2 Mar 2003 06:09:28 - 1.141
@@ -1556,11 +1556,14 @@ copy_internal (const char *src_path, con
un_backup:
- /* We didn't create the destination.
- Remove the entry associating the source dev/ino with the
+ /* We have failed to create the destination file.
+ If we've just added a dev/ino entry via the remember_copied
+ call above (i.e., unless we've just failed to create a hard link),
+ remove the entry associating the source dev/ino with the
destination file name, so we don't try to `preserve' a link
to a file we didn't create. */
- forget_created (src_sb.st_ino, src_sb.st_dev);
+ if (earlier_file == NULL)
+forget_created (src_sb.st_ino, src_sb.st_dev);
if (dst_backup)
{
Index: tests/mv/hard-3
===
RCS file: /fetish/cu/tests/mv/hard-3,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -p -u -r1.3 -r1.4
--- tests/mv/hard-3 1 Mar 2003 21:28:39 - 1.3
+++ tests/mv/hard-3 2 Mar 2003 05:59:23 - 1.4
@@ -1,6 +1,17 @@
#!/bin/sh
# Ensure that using `cp --preserve=link' to copy hard-linked arguments
# onto existing destinations works, even when one of the link operations fails.
+# This bug was fixed in coreutils-4.5.9.
+# To exercise this bug is non-trivial:
+# Set-up requires at least three hard-linked files. In copying them,
+# while preserving links, the initial copy must succeed, the attempt
+# to create the second file via `link' must fail, and the final `link'
+# (to create the third) must succeed. Before the corresponding fix,
+# the first and third destination file would not be linked.
+#
+# Note that this is nominally a test of `cp', yet it is in the tests/mv
+# directory, because it requires use of the --preserve=link option that
+# mv enables by default.
if test $VERBOSE = yes; then
set -x
Index: tests/mv/Makefile.am
===
RCS file: /fetish/cu/tests/mv/Makefile.am,v
retrieving revision 1.35
retrieving revision 1.37
diff -u -p -u -p -r1.35 -r1.37
--- tests/mv/Makefile.am2 Feb 2003 20:15:11 - 1.35
+++ tests/mv/Makefile.am2 Mar 2003 21:27:48 - 1.37
@@ -2,6 +2,8 @@
AUTOMAKE_OPTIONS = 1.3 gnits
TESTS = \
+ hard-3 \
+ hard-2 \
perm-1 \
i-link-no \
part-fail \
Index: tests/mv/hard-3
===
RCS file: tests/mv/hard-3
diff -N tests/mv/hard-3
--- /dev/null 1 Jan 1970 00:00:00 -
+++ tests/mv/hard-3 2 Mar 2003 21:29:33 - 1.5
@@ -0,0 +1,70 @@
+#!/bin/sh
+# Ensure that using `cp --preserve=link' to copy hard-linked arguments
+# onto existing destinations works, even when one of the link operations fails.
+# This bug was fixed in coreutils-4.5.9.
+# To exercise this bug is non-trivial:
+# Set-up requires at least three hard-linked files. In copying them,
+# while preserving links, the initial copy must succeed, the attempt
+# to create the second file via `link' must fail, and the final `link'
+# (to create the third) must succeed. Before the corresponding fix,
+# the first and third destination files would not be linked.
+#
+# Note that this is nominally a test of `cp', yet it is in the tests/mv
+# directory, because it requires use of the --preserve=link option that
+# mv enables by default.
+
+if test $VERBOSE = yes; then
+ set -x
+ cp --version
+fi
+
+. $srcdir/../envvar-check
