On 10/7/06, Miklos Szeredi <[EMAIL PROTECTED]> wrote:
[ JY: I assume that "> >" quotes statements by Paul Eggert, but the attribution has been lost ]
> There must already be such problems with hard links anyway, so this > extra problem isn't that much worse. Yes it is. Neither sftp, nor smbfs, nor fat support hard links. All of them support rename.
Not entiirely accurate. SSHFS supports whatever the underlying remote filesystem supports. That might include hard links. That is, directories A and B visible under SSHS could both be symbolic links to some other directory. Files C and D could be hard links to the same inode. However, the ls command of SFTP does not have any kind of "-i" option and so it is impossible to discover that this is the case.
What about embedded devices, where the table would not fit in memory? My guess is that an entry in such a table would be minimum 32bytes. A million such entries would take 32Mbytes.
Not sure what you're suggesting here. You clearly wouldn't be suggesting that everybody's interpretation of struct stat.st_ino should change just because of potential implementation limitation of a wristwatch-based Linux system. So I'm not sure what you *are* suggesting here. Clearly using a hash function to supply inode numbers from path names would not reqiure you to store an in-memory hash table. The hash value is enough. You could perhaps use a pair of Bloom filters to account for collisions (though this would mean that two SSHFS-using clients might disagree about the inode number of a given file).
> Again, it is unreasonable to expect standard utilities to port around > file systems that don't have reliable inode numbers. It breaks too > many other things: simplicity and security being the most important > two. It breaks neither of those. You are clearly just making this up, without understanding the issues. If you are actually interested in what's involved in fixing an application please follow the discussion on gnulib-bugs.
Let's move a little towards a position where we can make progress. As to how findutils might change, 0. Changes to make find functinally incorrect (i.e. give the wrong answer ans return qith exit status 0) will not be (deliberately) made 1. Changes to find which reduce its level of security will only be accepted if this is necessary to correct functional defects 2. I'm basically not willing to make changes to fix (even functional) problems on accessory filesystems if this reduces the level of security of the program on 'core' filesystems. (The distinction here is between for example the filesystem that / or /home is on and other stuff like AFS). 3. Code changes must follow the GNU coding standards (including copyright assignments, as the FSF requires). 4. I prefer changes which include documentation, and, normally, prefer changes that are small rather than changes that are big. Changes within these guidelines are welcome and encouraged. The only patch currently attached to the bug report is one which didn't fix the problem.
> People will just have to learn to not trust running standard > utilities on file systems that lack reliable-enough inode numbers.
Well, for find one of the principal problems is that there's no way around using directory inode numbers for security checks. On POSIX filesystems without O_NOFOLLOW (and perhaps some with, if the semantics are synthesised) there's no alternative. Filesystems not having support for symbolic links don't need the checks. But I can't think of a way to tell if we're looking at such a filesystem. I would expect that using readlink() won't work because I expect you would get EINVAL on non-supporting filesystems, just as you do on symlink-supporting filesystems for non-symlinks. Creating a symlink to verify that you get EPERM is also something that find certainly shouldn't do. James. _______________________________________________ Bug-findutils mailing list Bug-findutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-findutils
