Mikulas Patocka <[EMAIL PROTECTED]> wrote:
BTW. looking at the code leads me to another observation --- all those
security checks against 'rm'-vs-'mv' race break apart if the attacker is
Thank you for bringing this up. However, note that such systems are not
POSIX-compliant, since (as you must well know) POSIX requires unique inode
numbers. There are several places in the coreutils where this requirement
is assumed, mainly for security and directory-cycle detection, but also
for the relatively new --preserve-root option. Relaxing it would not be
trivial. It's just that I'm not (yet?) convinced doing so is desirable.
It's quite bad.
Those unique inode numbers are unimplementable in certaion filesystems or
operating systems (smb or coda can have collisions; fat inode number
changes in rename; you can mount filesystem over NFS from 64-bit system on
an old 32-bit system; on Windows, you have reliable file identifier only
as long as the file is open).
If POSIX specifies something that is unimplementable (unique stable inode
numbers) the question is why to rely on it?
In other words: what utility should I use to *reliably* copy directory
tree on smb filesystem? (current cp will choke if it finds two directories
with the same ino).
Mikulas
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
