bug-findutils
[Top][All Lists]
Advanced

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

Re: [bug #17877] Invalid "No such file or directory" error on filesystem


From: Paul Eggert
Subject: Re: [bug #17877] Invalid "No such file or directory" error on filesystem without stable inode numbers
Date: Fri, 06 Oct 2006 11:21:15 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Miklos Szeredi <address@hidden> 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
GiB, is already quite a limited app these days.  Such a program will
do just fine with 32-bit inode numbers in practice, as people won't
expect much of it.  If someone complains that such an app doesn't work
with a lot of files (e.g., the 470,000 files on your root file
system), then you tell them "sorry, you've got a legacy app built for
a small environment; please recompile it".  It's exactly what you'd
tell them when their program doesn't work with a 2.5 GiB file.

But even if you disagree with me, and want to implement some other
solution for small-file apps that would cause small-file GNU 'find' to
break, then that's OK.  GNU 'find' is not compiled in small-file mode.
Just get the filesystem to work in largefile mode, and leave GNU
'find' alone.  (Similarly for GNU coreutils, etc.)

>> That's much better than asking people to rewrite thousands of apps.
>
> I think you are the only one asking for that.

The issue in question is much larger than GNU 'find'.  It applies to
many programs that use gnulib, and it applies to many other programs
that don't use gnulib.  There's no way we're going to rewrite them
all, particularly if the rewrites make the programs less secure on
file systems that conform to the standard.

> I'm not holding my breath for these bug reports, sorry.

It's better to take a proactive approach, and fix buggy areas when
warned about them, before users find out about them; particularly when
the failure mode is so obscure, as it will be here.

>> There is a standard for this, a standard that reflects longstanding
>> practice.
>
> Which is what I have been doing.

Then I'm afraid I'm totally lost.  If POSIX says that inodes must be
unique and stable, and if the file system is conforming to POSIX, then
what's the problem?




reply via email to

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