According to my LFS spec (20Mar96), the application would not blow up
at all. Suppose it tries to call lseek(2) on the file. This will
return EOVERFLOW only if the file offset is above 2GB. Otherwise,
it will succeed as expected.
If the user first produces a 120GB file from a HERE document, and
then appends to it using a 32 bit cat, he probably deserves this to
fail mysteriously.
> 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.
At the time you perform write(2), you usually know what the current
file offset is, no? If it is beyond the overflow limit set on open(2),
you get EFBIG. So it is not the file size that determines failure,
but the position you want to write to.
The only issue I see is whether open should check for the file size; I
believe it shouldn't but wait and see what the user wants to do with
the file. As Ulrich points out, this is probably not an issue: All
applications that are meant to operate on large files will be
converted in no time. The real issue is to have the operating system
reliably support the feature.
Regards,
Martin