getting file size for really big (10GB) files?

[Martin]

Hi all.
I am developing a filemanager that needs to handle big files. While
testing on some zipped files of 6-7GB each I noticed that filesize(),
filemtime() and similar php-functions can't handle fikles larger than
2GB. This is true on the two servers I have regular access to (one
php4-RedHat, the other php5-Fedora).

If there a way to ger around these functions somehow? My fallback plan
is to use the systems functions and then parse the output-text to get
at the needed data. Naturally I was looking for a prettier way to do
it.

I'd appreciate any tips on the subject. thanks.

[tony]

In article <11**********************@m79g2000cwm.googlegroups .com>,
ma****@eimermusic.com says...

Hi all.
I am developing a filemanager that needs to handle big files. While
testing on some zipped files of 6-7GB each I noticed that filesize(),
filemtime() and similar php-functions can't handle fikles larger than
2GB. This is true on the two servers I have regular access to (one
php4-RedHat, the other php5-Fedora).

If there a way to ger around these functions somehow? My fallback plan
is to use the systems functions and then parse the output-text to get
at the needed data. Naturally I was looking for a prettier way to do
it.

I'd appreciate any tips on the subject. thanks.

I must be honest - I would choose another language if I wanted to do that
(10 Gb is quite a small file in my world)

PHP takes the absurd step of converting any integer it doesnt like into
a float on the fly at runtime - a more dangerous practice I can't
imagine. The upshot is maybe you'll come unstuck trying to manipulate
large integers.

Obviously you can work around preventing that from being a problem but
you shouldn't have to.

I dont know if its relevant to your situation but I thought I'd just
highlight it because it caused me big problems.

tony

[ImOk]

My suggestion is you shell out and execute 'ls' and send output to a
txt file and then parse the result if you just need the file size.

Martin wrote:

Hi all.
I am developing a filemanager that needs to handle big files. While
testing on some zipped files of 6-7GB each I noticed that filesize(),
filemtime() and similar php-functions can't handle fikles larger than
2GB. This is true on the two servers I have regular access to (one
php4-RedHat, the other php5-Fedora).

If there a way to ger around these functions somehow? My fallback plan
is to use the systems functions and then parse the output-text to get
at the needed data. Naturally I was looking for a prettier way to do
it.

I'd appreciate any tips on the subject. thanks.

[Martin]

Thanks for both your replys.

I have noticed that PHP does not handle big files well in any
situation. The manual brushes by this and, for example, suggests I use
sprinf to make an unsigned number to get the correct size for files up
to 4GB. So very 90s. :)

I am surprised that PHP can't simply get the same result as 'ls'. I was
thinking of using it but the downside is that it imposes some
limitations on the server installation I can use. Ideally I would like
to avoid exec() and other commands that is often blocked on hosting
servers. (even though most won't like 10Gb files anyway)

The bigger problem is really that different installations return vastly
different results for filesize(). My local php4 (Mac OS X) at least
returns a number while the php5 (Fedora) server I use throws a warning
and returns false on the same file. Php5 on Fedora I really expected to
be up to it.

Sorry for the little rant. This is one area where I assumed PHP would
be OK. Developing an application for a few months and at the final
testing stage finding out these problems is no fun. You can imagine how
much headscratching I have done to get the uploading and downloading of
these huge files to work... and then I stumble on this "detail".

Thanks again guys.

[ImOk]

Well, if it makes you feel better (and worse after reading) here isthe
bug report. Its supposed to be fixed, but no one has done anything in a
few years. I am surprised. I guess people jut use Java for issues like
this.

http://bugs.php.net/bug.php?id=27792

Martin wrote:

Thanks for both your replys.

I have noticed that PHP does not handle big files well in any
situation. The manual brushes by this and, for example, suggests I use
sprinf to make an unsigned number to get the correct size for files up
to 4GB. So very 90s. :)

I am surprised that PHP can't simply get the same result as 'ls'. I was
thinking of using it but the downside is that it imposes some
limitations on the server installation I can use. Ideally I would like
to avoid exec() and other commands that is often blocked on hosting
servers. (even though most won't like 10Gb files anyway)

The bigger problem is really that different installations return vastly
different results for filesize(). My local php4 (Mac OS X) at least
returns a number while the php5 (Fedora) server I use throws a warning
and returns false on the same file. Php5 on Fedora I really expected to
be up to it.

Sorry for the little rant. This is one area where I assumed PHP would
be OK. Developing an application for a few months and at the final
testing stage finding out these problems is no fun. You can imagine how
much headscratching I have done to get the uploading and downloading of
these huge files to work... and then I stumble on this "detail".

Thanks again guys.

[micro]

In article <11*********************@a14g2000cwb.googlegroups. com>,
j_********@yahoo.com says...

Well, if it makes you feel better (and worse after reading) here isthe
bug report. Its supposed to be fixed, but no one has done anything in a
few years. I am surprised. I guess people jut use Java for issues like
this.

http://bugs.php.net/bug.php?id=27792

I cant imagine why anyone would use java for anything at all.

[ImOk]

Ok, Java is an overkill. But if you have to overcome a bug then maybe
use Ruby or Python or Perl.

mi***@fan.com wrote:

In article <11*********************@a14g2000cwb.googlegroups. com>,
j_********@yahoo.com says...

Well, if it makes you feel better (and worse after reading) here isthe
bug report. Its supposed to be fixed, but no one has done anything in a
few years. I am surprised. I guess people jut use Java for issues like
this.

http://bugs.php.net/bug.php?id=27792

I cant imagine why anyone would use java for anything at all.