Topic: Show Attachments as KB, MB, GB ??

[hitsquaduk]

SMF only shows attachment sizes as KB only there there a way to show them as MB and GB?? I have big files on my forum and people dont know what all the numbers are so this would be handy to have it show as MB,GB

[Rudolf]

In Display.php
Search for:

Code: [Select]

'size' => round($attachment['filesize'] / 1024, 2) . ' ' . $txt['smf211'],Replace with:

Code: [Select]

'size' => $attachment['filesize']>1048576 ? round($attachment['filesize']/1048576,2) . ' MB' : ($attachment['filesize']>1024 ? round($attachment['filesize']/1024,2) . ' KB' : $attachment['filesize'] . ' B'),

[hitsquaduk]

That works great thank you for your time  

[Iomega0318]

Ok so I know this is VERY old, however this is what I am needing to use on my forum.

However the above code does not work correctly and does not show the correct size in MB.

[MrPhil]

In what way is it "not working correctly"? Is it changing what's displayed, but not showing the expected numbers? Is it not having any effect at all? Is it showing MB and you want MiB? In that case, use 1000000 and 1000 for MiB and kiB instead of 1048576 and 1024.

[Iomega0318]

In what way is it "not working correctly"? Is it changing what's displayed, but not showing the expected numbers? Is it not having any effect at all? Is it showing MB and you want MiB? In that case, use 1000000 and 1000 for MiB and kiB instead of 1048576 and 1024.

Sorry, it is working and showing MB etc, however it is not showing the correct number.
For example, I have a file that is 44254.34 kB, 442.54 MB but with this it shows as 44.2 MB.

Also in the above code I notice there is no GB conversion..

[MrPhil]

You're saying that 45316444 bytes shows as 44254.34 kB and 44.2 MB? Are you sure it's not showing 43.22 MB? Remember, bytes/1024 --> kB, kB/1024 --> MB. Use 1000 if you want kiB and MiB. Where do you get 442.54 MB from?

To show GB (can your server even allow file uploads that size?):

Code: [Select]

'size' => $attachment['filesize']>=1073741824
               ? round($attachment['filesize']/1073741824, 2) . ' GB'
               : ($attachment['filesize']>=1048576
                  ? round($attachment['filesize']/1048576, 2) . ' MB'
                  : ($attachment['filesize']>=1024
                    ? round($attachment['filesize']/1024, 2) . ' kB'
                    : $attachment['filesize'] . ' B' )),
or

Code: [Select]

'size' => $attachment['filesize']>=1000000000
               ? round($attachment['filesize']/1000000000, 2) . ' GiB'
               : ($attachment['filesize']>1000000
                  ? round($attachment['filesize']/1000000, 2) . ' MiB'
                  : ($attachment['filesize']>1000
                    ? round($attachment['filesize']/1000, 2) . ' kiB'
                    : $attachment['filesize'] . ' B' )),


[Iomega0318]

Thank you for the updated one with GB (and yes/no it can lol, kinda complicated) and after looking into it my file was only holding 8 numbers in the database so it was one short, after fixing it and it showing 9 numbers it now shows up right.. the original code does work it was just my database that was missing a number.. oops..

**EDIT**
hmm odd, if I use your code it shows everything as kB but if I use the above code it will show the correct number of MB now that I fixed the database.. any ideas why yours does not work?

[MrPhil]

I think the size in the database is going to be a signed 32 bit integer (2.1 billion max). If it's unsigned, that will be 4.2 billion max. The "size" should be 10 digits, not 8 or 9, to allow the full amount. If you have 8 or 9 digits, SQL will cut off or shorten the returned value in some way, which is not desirable in this case.

I'm confused by your statements. What is now working and what isn't? Is "the above code" the latest that I gave, or something earlier? Give an example of actual size (in bytes) and what shows up displayed as the size. Remember that the size on a Windows PC will not be quite the same size as on a Linux server, if the attachment was text (uploaded in ASCII format), due to CRLF <--> newline translation. For binary files, the size should be the same.

[Arantor]

I think the size in the database is going to be a signed 32 bit integer (2.1 billion max). If it's unsigned, that will be 4.2 billion max. The "size" should be 10 digits, not 8 or 9, to allow the full amount. If you have 8 or 9 digits, SQL will cut off or shorten the returned value in some way, which is not desirable in this case.

Nope. MySQL uses the 'size' to figure out how big to display values for the command line client. int( is the same 32-bit column as int(10) just it won't display 10 columns on the command line client.

[MrPhil]

That's exactly what I was saying (or trying to say). The internal representation is usually a standard hardware integer size (char, short, long, even long long), with the number of displayed digits meaning that the returned (or inserted) value might be truncated in some way. AFAIK, this also applies to program use of the value, not just command line use -- does anyone have documentation to the contrary? It's hard to believe that MySQL (or any other SQL implementation) would truncate or round down to N digits for the command line but not for API use. Note that there are DECIMAL fields which may be stored as a string (of a given length) of ASCII digits, but that is a separate data type from "int".

[Arantor]

Nope, the returned value is not truncated in any way when you're using a non command line client. I can't find any documentation on this but a simple test would be to create a tinyint(1) column then try storing 100 in it and seeing what you get back. Certainly on MySQL 5.0 and 5.1 this returns 100 as expected when using something like phpMyAdmin or the PHP interface.

[Iomega0318]

You're saying that 45316444 bytes shows as 44254.34 kB and 44.2 MB? Are you sure it's not showing 43.22 MB? Remember, bytes/1024 --> kB, kB/1024 --> MB. Use 1000 if you want kiB and MiB. Where do you get 442.54 MB from?

To show GB (can your server even allow file uploads that size?):

Code: [Select]

'size' => $attachment['filesize']>=1073741824
               ? round($attachment['filesize']/1073741824, 2) . ' GB'
               :  $attachment['filesize']>=1048576
                  ? round($attachment['filesize']/1048576, 2) . ' MB'
                  : $attachment['filesize']>=1024
                    ?  round($attachment['filesize']/1024, 2) . ' kB'
                    : $attachment['filesize'] . ' B',
or

Code: [Select]

'size' => $attachment['filesize']>=1000000000
               ? round($attachment['filesize']/1000000000, 2) . ' GiB'
               :  $attachment['filesize']>1000000
                  ? round($attachment['filesize']/1000000, 2) . ' MiB'
                  : $attachment['filesize']>1000
                    ?  round($attachment['filesize']/1000, 2) . ' kiB'
                    : $attachment['filesize'] . ' B',


Was just saying if I use your code it does not work, was wondering why.

If I use the original code:

Code: [Select]

'size' => $attachment['filesize']>1048576 ? round($attachment['filesize']/1048576,2) . ' MB' : ($attachment['filesize']>1024 ? round($attachment['filesize']/1024,2) . ' KB' : $attachment['filesize'] . ' B'),it works fine, for example I uploaded a file and changed the database size to "999999999" it now shows up as 953.67 MB

But I was also wanting to convert even larger files to show as GB right now if it's a GB or over it just shows as 4096 MB.

..................................................

[MrPhil]

4294967295 is 2^32-1, the maximum 32 bit unsigned integer, which has 10 digits if my eyes don't deceive me. 9999999999 exceeds that internal limit (even though it's still 10 digits) and is likely to cause an error.

I don't know why my code wouldn't work for you, unless your original $attachment['filesize'] is not a 32 bit or smaller integer. Is it a decimal value (floating point)? 1073741824 should fit comfortably within any int or bigint (32 or 64 bit, signed or unsigned). The comparison is done by subtracting one number from the other, so that should work OK. Possibly to do the division, it's converting the values to floating point first, and you're losing enough precision to cause a problem, although the result should be of the correct magnitude:  1100000000/1073741824 might be handled as 1.1E+09/1.07374E+09, but that should still be in the ballpark of 1.02 (GB). I'll have to play around with it a bit, and will post any news here.

Update: OK, add some ( ) as shown in the edited post above. PHP has some peculiar precedence rules!

I read up on the MySQL data types, and it appears that the length, e.g.,  (10) is ignored except when you have ZEROFILL on to left pad with 0's out to the given length for command line display purposes. It is not supposed to affect the actual value in either command line or via API. It's not clear whether a ZEROFILL'd value exceeding the given width simply displays at the needed width (exceeding the given field width); nor is it clear what happens if a signed integer is negative (the use of width 11 leads me to suspect that an extra digit is needed for the minus sign).

[Iomega0318]

Update: OK, add some ( ) as shown in the edited post above. PHP has some peculiar precedence rules!

Awesome, that did it thank you!