olarge -- force O_LARGEFILE on app binaries.

olarge -- force O_LARGEFILE on app binaries.

[Tigran Aivazian]

Hi,

Some time ago I was annoyed to see that ghostscript didn't support large
files (>2G) and, although the fix to gs(1) was trivial it was very
undesirable to have to recompile it (for lots of reasons like mismatch
between the source set and fonts, libraries etc). So the only (efficient)
solution in my case would have been to "modify" the behaviour of the gs
binary without rebuilding it. One way is to use LD_PRELOAD feature but I
found it easier to just knock up a simple kernel module olarge.o to do the
job.

In case someone else encountered the same problem and needed the solution 
(but didn't know how to write it), here it is for download:

http://www.moses.uklinux.net/patches/olarge.tar.gz

Regards
Tigran

PS. (for those familiar with sys_call_table[] handling in modules this 
should be obvious but just in case --- don't try to unload the module 
while "using it", i.e. running an app you have thus modified.)

PPS. Don't bother explaining to me that this is "not a nice thing to do 
inside a module", I am well aware of it. This is just a quick fix to a 
specific problem and I share with others who may have hit it as well, 
that's all. As the GPL license says "no assumed useability for any 
purpose...." :) Enjoy.

Re: olarge -- force O_LARGEFILE on app binaries.

[Andreas Dilger]

On Apr 14, 2003  16:03 +0100, Tigran Aivazian wrote:
> Some time ago I was annoyed to see that ghostscript didn't support large
> files (>2G) and, although the fix to gs(1) was trivial it was very
> undesirable to have to recompile it (for lots of reasons like mismatch
> between the source set and fonts, libraries etc). So the only (efficient)
> solution in my case would have been to "modify" the behaviour of the gs
> binary without rebuilding it. One way is to use LD_PRELOAD feature but I
> found it easier to just knock up a simple kernel module olarge.o to do the
> job.

I don't see how this helps you very much.  So now, instead of the kernel
complaining with EFBIG and/or SIGXFSZ, your 32-bit size offset wraps in
the application.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

Re: olarge -- force O_LARGEFILE on app binaries.

[Tigran Aivazian]

On Mon, 14 Apr 2003, Andreas Dilger wrote:
> I don't see how this helps you very much.  So now, instead of the kernel
> complaining with EFBIG and/or SIGXFSZ, your 32-bit size offset wraps in
> the application.

Good point, but, very _very_ luckily it does NOT happen in this case, i.e. 
with gs(1). I just verified every bit of output and it is correct both 
before and beyond the 2G boundary, all the way to 5.2G. But in general 
(i.e. for some other app) your comment is valid.

Regards
Tigran

Re: olarge -- force O_LARGEFILE on app binaries.

[Andreas Dilger]

On Apr 14, 2003  17:29 +0100, Tigran Aivazian wrote:
> On Mon, 14 Apr 2003, Andreas Dilger wrote:
> > I don't see how this helps you very much.  So now, instead of the kernel
> > complaining with EFBIG and/or SIGXFSZ, your 32-bit size offset wraps in
> > the application.
> 
> Good point, but, very _very_ luckily it does NOT happen in this case, i.e. 
> with gs(1). I just verified every bit of output and it is correct both 
> before and beyond the 2G boundary, all the way to 5.2G. But in general 
> (i.e. for some other app) your comment is valid.

I suppose for applications that do only streaming I/O (and gs is one of those)
this O_LARGEFILE fix shouldn't cause any problem.  Any applications which do
seeking, or otherwise use/store the file offset for any reason will likely
break.  However, since they are still using the 32-bit syscalls, they will
likely just get EOVERFLOW and not die horribly (assuming they check the
return code).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/