Having random scripts die with EOVERFLOW is IMHO a "blow up mysteriously"
to the average user.
> 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.
Oh look NFSv3 hasnt got such a bit, Oh look SMBfs hasn't got such a bit etc
Furthermore the denial of service and setuid application attacks possible
on this are astronomical in scale if you can use setuid apps to "taint"
32bit files.
> 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
Yes. Like an lseek on a 64bit file, or an mmap() that would go over
2^32 bytes. O_APPEND on a file over 2^32 bytes is an interesting one,
perhaps that should fail in case the app then uses lseek.
> 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.
To be able to use normal unix file redirection my shell has to be one
of them however. Thats why its important that the applications continue
to do the right thing, or as close as possible. "cat" for example works
fine given a 64bit file and doing 32bit operations. Stuff like tail
that does lseek won't. Thats why we want to stop the minimum number
of operations.
Alan