bug-coreutils
[Top][All Lists]
Advanced

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

Re: [SECURITY] Re: PATCH: rm -rf and readdir bug in coreutils-6.7


From: Paul Eggert
Subject: Re: [SECURITY] Re: PATCH: rm -rf and readdir bug in coreutils-6.7
Date: Fri, 29 Dec 2006 18:23:57 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Mikulas Patocka <address@hidden> writes:

> If POSIX specifies something that is unimplementable (unique stable
> inode numbers) the question is why to rely on it?

But it's easily implementable, if your file system was written with
POSIX in mind.

In many cases the POSIX folks had to decide whether to make
concessions to non-Unix practice.  For example, should POSIX allow a
distinction between text and binary files, which is pretty much a
requirement for DOS-ish file systems?

As a general rule, the POSIX standardizers decided to stick with the
traditional Unix semantics when there was a clear clash with non-Unix
systems.  Inode numbers is one of those cases; newline representation
is another.


> 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).

smbclient should be able to do it, no?  (Admittedly it might be a bit
awkward, but that's often what happens when you start dealing with
nonstandard systems.  :-)

There are a lot of packages that will break (sometimes subtly) on file
systems that lack stable file serial numbers: coreutils, diffutils,
git, tar, the list goes on for quite a ways.  I'm afraid the only
current answer to this problem is "don't do that then".
(I'm quoting Linus Torvalds in <http://lkml.org/lkml/2005/4/8/236>.)




reply via email to

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