Re: [Help-gnunet] files > 2 gb

[Darren]

This is informative, thank you.

I just wanted to provide an additional informative link on this topic:
http://www.suse.de/~aj/linux_lfs.html

This site talks about filesystems, and distributions which have LFS support.  I 
have pasted a small snippet below regarding using programs with LFS, expanding 
upon what Christian has explained.

-------------------------
For using LFS in user programs, the programs have to use the LFS API. This 
involves recompilation and changes of programs. The API is documented in the 
glibc manual (the libc info pages) which can be read with e.g. "info libc".

In a nutshell for using LFS you can choose either of the following:

    * Compile your programs with "gcc -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE". This forces all file access calls to use the 64 bit 
variants. Several types change also, e.g. off_t becomes off64_t. It's therefore 
important to always use the correct types and to not use e.g. int instead of 
off_t.
        * Define _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE. With these defines 
you can use the LFS functions like open64 directly.
        * Use the O_LARGEFILE flag with open to operate on large files.

        A complete documentation of the feature test macros like 
_FILE_OFFSET_BITS and _LARGEFILE_SOURCE is in the glibc manual (run e.g. "info 
libc 'Feature Test Macros'").

-----------------------

Darren <address@hidden>

> Date: Sun, 20 Oct 2002 16:58:13 +0200 (CEST)
> From: Christian Drechsler <address@hidden>
> To: address@hidden
> Subject: [Help-gnunet] files > 2 gb
> 
> hi there!
> 
> so here is a quick-and-easy solution for those who use rpm-based systems
> to recompile their packages with large file summit support:
> 
> - find the lib directory of your rpm installation, normally /usr/lib/rpm/
> 
> - look into the rpmrc file you find there. don't edit this file! it will
>   be overwritten next time you install a new version of rpm.
> 
> - find the line beginning with
>   optflags: i386
>   (hint: rpm normally always uses that architecture in order to keep the
>   stuff portable. if you want to compile directly for athlon, e.g., you
>   will have to set "buildarchtranslate: athlon: athlon" in /etc/rpmrc,
>   too. and you certainly must use the corresponding optflags:-line from
>   /usr/lib/rpm/.)
> 
> - create (or edit) the file /etc/rpmrc
> 
> - copy the "optflags: i386"-line to that file and add "-D_LARGEFILE_SOURCE
>   -D_FILE_OFFSET_BITS=64" to it
> 
> - get the source rpm of the package you want to recompile
> 
> - issue "rpm --rebuild <package>.src.rpm"
> 
> - if everything works as it should you will find the readymade rpm in
>   /usr/src/redhat/RPMS/i386/ (or athlon/ or any other architecture if you
>   changed sth according to the hint above).
> 
> - now install it by saying "rpm -U --force <package>.rpm". the --force
>   param is necessary if you have the same version number running already.
>   rpm would otherwise decline to overwrite the old files.
> 
> this workes out of the box here. but if i try to start gnunetd now with my
> old large database, it stops with
> Oct 20 15:35:09 getDatabase: failed to open database file 
> /home/zottel//.gnunet/data/content.gdb with error: File seek error
> 
> if i use the version without LFS, gnunetd first starts without problems
> but crashes a little later. why is that now? maybe within the file there
> are inidices pointing beyond the 2gb line that turn around to small values
> with the old 32bit integer, and as the file never got bigger than 2 gb,
> now they point beyond the end of the file? that's the only answer i can
> imagine. as compilation and stuff worked without the slightest problems,
> i'm quite positive that the database could now grow beyond 2 gb. i
> probably won't be able to repair the old one, but what the heck ... ;-)
> 
> comments?
> 
> regards, zottel
> 
> 
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> Help-gnunet mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/help-gnunet
> 
> 
> End of Help-gnunet Digest

--