Bitzi works
best with
Bitzi-Powered Applications.
|
Bitzi Developer Discussion: bitcollider with largefile support
Main Site : bboard : Bitzi Developer Discussion : One Message
Message:
|
bitcollider with largefile support
|
[forward as email]
|
| is it possible/going to be/there interest in compiling bitcollider (on linux) with largefile support? i'd really like to submit all those 4-6gig dvd-images someday...
| |
|
-- rcqj2dw3puql4but, December 24, 2003 07:23 pm
|
Replies:
|
Re: bitcollider with largefile support
|
[forward as email]
|
| You're right, the Bitcollider should definitely be updated to support large files. It's probably just a matter of changing a number of 'int's to 'long's. I don't have any giant files handy -- have you tried this, and how does it fail? - Gordon @ Bitzi
| |
|
-- gojomo, December 29, 2003 08:40 pm
|
|
Re: bitcollider with largefile support
|
[forward as email]
|
| when a application compiled without largefile support (ends up using open() instead of open64()), tries to open a file >=2GiB, that fails with errno="file too large". $ dd if=/dev/null of=LARGEFILE count=0 bs=1 seek=$((1024*1024*1024*2)) # this is a simple and FAST way to get (empty/sparse) large files without any disk I/O $ bitcollider -p LARGEFILE Cannot find file/dir LARGEFILE. Skipping. (note the misleading error message duh...) after a quick google search and a compile with make CC="gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE" (<http://ac-archive.sourceforge.net/largefile/> seems a nice resource) i get: $ dd if=/dev/null of=LARGEFILE count=0 bs=1 seek=$((1024*1024*1024*2)) $ bitcollider -p LARGEFILE bitprint=SHKQMQW5SMHJKQWDTU3PAULNIX2ODLYN but then with somewhat larger (+1meg) files it crashes at some point, i would suspect the hashes with internal block-states (ed2k or ftuuhash) there, i'll look at that a bit further when i get to it... (but i'm not the one to fix the whole app, i'm afraid)
| |
|
-- rcqj2dw3puql4but, December 30, 2003 03:54 am
|
|
Re: bitcollider with largefile support
|
[forward as email]
|
| when a application compiled without largefile support (ends up using open() instead of open64()),
tries to open a file >=2GiB, that fails with errno="file too large".
$ dd if=/dev/null of=LARGEFILE count=0 bs=1 seek=$((1024*1024*1024*2))
# this is a simple and FAST way to get (empty/sparse) large files without any disk I/O
$ bitcollider -p LARGEFILE
Cannot find file/dir LARGEFILE. Skipping.
(note the misleading error message duh...)
after a quick google search and a compile with
make CC="gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE"
(<http://ac-archive.sourceforge.net/largefile/> seems a nice resource)
i get:
$ dd if=/dev/null of=LARGEFILE count=0 bs=1 seek=$((1024*1024*1024*2))
$ bitcollider -p LARGEFILE
bitprint=SHKQMQW5SMHJKQWDTU3PAULNIX2ODLYN
but then with somewhat larger (+1meg) files it crashes
at some point, i would suspect the hashes with internal
block-states (ed2k or ftuuhash) there, i'll look at that
a bit further when i get to it...
(but i'm not the one to fix the whole app, i'm afraid)
| |
|
-- rcqj2dw3puql4but, December 30, 2003 04:06 am
|
|
Re: bitcollider with largefile support
|
[forward as email]
|
| Thanks for the info. We'd appreciate suggestions/patches from anyone who has the insight to help us fix this right, on both Linux and Windows.
| |
|
-- gojomo, January 18, 2004 06:37 pm
|
|
Re: bitcollider with largefile support
|
[forward as email]
|
| yay for largefile support here too, but to less insight to contribute something useful other than MOO
| |
|
-- coprophiliac, June 18, 2004 07:15 am
|
[
Post a reply
]
|
