Charles E Campbell Jr wrote:
Sounds like the filesize is getting stored in a 32bit signed
number, and overflowing.
Yes, definitely.
Please let me know what getfsize() is actually returning
The return value is the bit pattern for the low 32 bits of the
true 64-bit file size:
3,146,839,490 file actual size
-1,148,127,806 returned by getfsize()
The sum of the absolute values is exactly 4G. I confirmed the
above with a file exactly 8G + 512 bytes (getfsize() said it was
512 bytes).
I was going to suggest that you treat a negative getfsize()
value as a large file (may as well do that even if the value is
-1 for an error indication).
I suppose that would be useful until some better solution is
implemented. I didn't propose it because it would be quite ugly
for the script to give results like this:
3GB file is large
5GB file is not large
7GB file is large
9GB file is not large
Another ugly (but accurate) workaround would be:
- Provide the source for a small executable called islargefile
to do the calculation.
- Provide an option in the script to use the executable.
- Have the script execute system('islargefile xxx 123456').
Return value 0 means "no", 1 means "yes", 2 means "error"
(return is first character of system() string).
Need to work out how to pass arguments:
xxx = path of file to be tested
123456 = limit at which file is large
John
