Update of bug #17877 (project findutils):
Status:None = Wont Fix
Assigned to:None = jay
Open/Closed:Open = Closed
I'm very reluctant to try opening every file in the
filesystem just in case it turns out to be a directory we need to
descend into.
Your reluctance is understandable, since it is incorrect to
always open every directory entry. The corresponding file
might be a special file, and opening
Miklos Szeredi [EMAIL PROTECTED] writes:
From what I understand, the solution for the find
problem will actually make fts more optimal in some cases even for
POSIX filesystems, and will cause no regressions whatsoever.
If so, then that's good for fts. The problem will continue
to remain for
On 10/7/06, Miklos Szeredi [EMAIL PROTECTED] wrote:
Yes, for systems with O_NOFOLLOW, that is a perfect (efficient, race
free) solution. For systems without O_NOFOLLOW, just moving the
lstat() and the open() close to each other
Actually moving the lstat() _after_ the open() totally removes
The legacy app will break regardless of how many files there are on
the filesystem, or even wheter it needs to use the inode number or
not. It will break because the stat() family of syscalls will return
with an error.
I don't see why. The kernel should be able to tell whether the app
Miklos Szeredi [EMAIL PROTECTED] writes:
If you were thinking of a soltuion, where the filesystem itself
supplies two different inode numbers based on the variant of the
userspace interface, then I'm sorry to inform you, that this sort of
interface is not likely to happen in the Linux kernel.
If you were thinking of a soltuion, where the filesystem itself
supplies two different inode numbers based on the variant of the
userspace interface, then I'm sorry to inform you, that this sort of
interface is not likely to happen in the Linux kernel.
I don't see why not.
Because it
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
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
Follow-up Comment #12, bug #17877 (project findutils):
If files are identified by the path, then you can hash the
path. If you use a good 64-bit hash the chance of collision
is practically zero. That's good enough.
Yes. And this solution is actually practical on pure 64bit
archs only. On
On 10/6/06, Miklos Szeredi [EMAIL PROTECTED] wrote:
Yes. And this solution is actually practical on pure 64bit
archs only. On 32bit and dual archs it's not practial, because
legacy apps (those compiled without largefile support) will
get an EOVERFLOW for stat if the inode number doesn't fit
Miklos Szeredi [EMAIL PROTECTED] writes:
If files are identified by the path, then you can hash the
path. If you use a good 64-bit hash the chance of collision
is practically zero. That's good enough.
Yes. And this solution is actually practical on pure 64bit
archs only. On 32bit and dual
Miklos Szeredi [EMAIL PROTECTED] writes:
If it's for legacy apps, tell people to recompile with largefile
support.
Paul, please! It is ridiculous to require end users to recompile
their applications or kernels or anything.
A small-file legacy app, one that cannot handle files larger than 2
But what about symlinks?
a g
b h-a
c
f-g
The moment you traverse the f-g symlink above,
the entire tree, a/b/c/f, is no longer referenced,
so the h-a link may take you back to a new inode,
and the cycle will not be detected.
Right. So
Follow-up Comment #11, bug #17877 (project findutils):
if some Linux-based file systems can't provide stable
inode numbers, they should be fixed so that they do. It
shouldn't be that hard.
It's not hard, it's impossible. Take for example path
based network filesystems (smbfs, sshfs). For
Follow-up Comment #8, bug #17877 (project findutils):
Thanks for the patch. I've tested it and it doesn't seem to make any
difference.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?17877
Follow-up Comment #8, bug #17877 (project findutils):
Thanks for the patch. I've tested it and it doesn't seem to make any
difference.
Are you using the fts version of find 4.3.x?
Yes, find/find from 4.3.1+patch.
With find/oldfind the bug doesn't show up.
Miklos
On 9/28/06, Eric Blake [EMAIL PROTECTED] wrote:
Follow-up Comment #1, bug #17877 (project findutils):
There are several Linux filesystems (including smbfs, fat, and
some FUSE based ones) which cannot provide stable inode numbers
for unreferenced files or directories.
OP, can you provide a
Follow-up Comment #6, bug #17877 (project findutils):
Good point about inode numbers being reused.
This means that what you can tell from comparing inode numbers (obtained from
pathnames), according to POSIX, is:
* If the inode numbers are different, the file is definitely a different
file.
*
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Replying outside of savannah, and adding bug-gnulib, since ultimately,
the behavior in question is a result of gnulib's fts]
According to Geoff Clare on 9/30/2006 5:53 AM:
Follow-up Comment #6, bug #17877 (project findutils):
Good point about
Eric Blake [EMAIL PROTECTED] wrote:
...
http://savannah.gnu.org/bugs/?17877
For the gnulib crowd, a summary of the above link is that find 4.3.0,
which uses gnulib's fts, is sometimes reporting No such file or
directory in the middle of traversal on non-POSIX file systems such as
smbfs,
Follow-up Comment #3, bug #17877 (project findutils):
POSIX does require a file's inode number to be stable. To see this consider
what happens if you stat() a pathname and remember the st_dev and st_ino
values, then some time later you stat() the same pathname and observe that
the st_ino value
Follow-up Comment #5, bug #17877 (project findutils):
BTW, POSIX isn't all that clear about inode numbers. Take this example:
touch x
rm x
mkfifo y
Is x and y the same file? Obviously not. Can they have the same inode
number? Yes, filesystems do reuse inode numbers.
So is st_ino a unique
Follow-up Comment #1, bug #17877 (project findutils):
There are several Linux filesystems (including smbfs, fat, and
some FUSE based ones) which cannot provide stable inode numbers
for unreferenced files or directories.
That's the problem. If an OS can't provide stable inode numbers, it is
Follow-up Comment #2, bug #17877 (project findutils):
I've found the following about st_ino in POSIX:
In definitions:
3.175 File Serial Number
A per-file system unique identifier for a file.
In sys/stat.h:
ino_t st_ino File serial number.
The st_ino and st_dev fields taken
25 matches
Mail list logo
