Re: large file support? (fwd)

Ulrich Drepper (drepper@ipd.info.uni-karlsruhe.de)
17 Aug 1997 14:08:42 +0200


alan@lxorguk.ukuu.org.uk (Alan Cox) writes:

> There are several reasons I'm sceptical. Firstly a 64bit aware bash opens
> a file redirection to a 32bit app which then blows up mysteriously...

It does not blow up mysteriously but instead get the EOVERFLOW error.
Franted, it must be added to the list of expected errors but this will
happen sooner or later anyway since some other OSes also know this
(probably sooner).

> The "file smaller than 2Gb" is unenforcable because other processors
> may also be altering an object, this object might also change remotely
> on a networked fs.

I don't think this is a problem. If a process modifies the file with
32 bit operations and others with 64 bit operations there is something
wrong (or at least inconsistent). This is why I suggest the 32 bit
handled gets a sticky bit which says it is unusable and should return
EOVERFLOW.

> The big problem is the EOVERFLOW blowing up apps it doesnt need to

I don't see a big problem here.

If an application modifies a file and it's the only program which
modifies this file there can never be a problem. This probably is
true for most commercial apps which are so important for you. Plus:
once the interface is available the authors can compile the app with
-D_FILE_OFFSET_BITS=64 and automatically the program can use 64 bit
functions.

If an application uses 32 bit operations but some others use 64 bit
operations, the former should stop as soon as it becomes obvious
something wrong is going on. And now think which kind of apps this
could be. I think applications which create files with more than 2GB
size are very special and so it is very unlikely that accidently a
second, unrelated application uses this very same file at the same
time.

If we say that as soon as the new interface is available all the
system utilities which work on files (such as cat, sort, ...) are
converted I really don't see a problem.

-- Uli
---------------. drepper@cygnus.com ,-. Rubensstrasse 5
Ulrich Drepper \ ,-------------------' \ 76149 Karlsruhe/Germany
Cygnus Solutions `--' drepper@gnu.ai.mit.edu `------------------------