Hi, I have been watching the thread about the file::copy. I ran into an issue in the Linux environment that brings a serious question, MAX file size. Keep in mind the server is running 7.0 RH, we have 7.2 Enterprise Server also, and we pay for support. But even the RH support says they can't handle files in excess of 2GB (approx).
i believe RH 7.1 beta r1 (code name Fisher) which uses kernel 2.4.0 is the first RH that supports the LFS (Large File Support) extension. your server running 7.0 won't be able to address > 2GB file. If you have 7.2 Enterprise, why don't you use that instead? If you pay for support, isn't RH suppose to provide help / instruction on how to get your 7.0 with LFS support?
if you simply want to know if Perl is able to deal with > 2GB file, you can:
[panda]$ perl -V | grep 'uselargefiles'
and you should see something like:
uselargefiles=define
to see that if perl (the binary) is compiled to use LFS API, use:
[panda]$ perl -V | grep 'OFFSET_BIT'
and if you see something like:
D_GNU_SOURCE -fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
you are in good shape. the easiest solution to get LFS support is to upgrade your 7.0 imo.
david
David,
Thanks for the observations. But the point that RH made to me (Again, about 6 months ago) was that this issue was in 7.0-7.2 and YES, they did not recommend rebuilding the kernel because at THAT time the 2.4 was "Buggy" in their opinion. I am not so worried about Perl being able to READ/WRITE or what ever for large files, but the O/S has to be able to do this first, correct? That's my main point and the obstacles I've run into on this. It seems like to me, it is time to revisit this with the RH folks to see what THEY say about it, then go through the pain of upgrading a server with a ton of perl code on it, of course, everything must be TESTED to make 100% sure I haven't dropped anything through the cracks.
Thankx...
-- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
