Hi,
I’ve been looking at the various ways in which I can convert the result of size of info for an item into KB, MB and GB. I’ve seen lots of ways of doing this but none seem to reliable. if I use this code:
set the_size to size of (info for (choose file))
the_size / 1024 as integer
then this seems to wok fine for something that maybe 106kb it’ll return a result of 106 but if I choose an item that’s say 4KB then it returns 1 can anybody tell me why this maybe?
Another option I’ve tried is:
set posixpath to quoted form of POSIX path of (choose file)
set filesize to do shell script "du -h" & " " & posixpath
This seems to work fine until I choose a file that has package data and then it returns a value for every item of the package.
Is there any way of accurately getting the size of a file in the same way as selecting an object and doing Get Info?
Thanks for your time,
Nik
set posixpath to quoted form of POSIX path of (choose file)
set filesize to item -1 of paragraphs of (do shell script "du -hc " & posixpath & " | awk '{print $1}'")
Hi James,
Thanks for your response.
When I choose a file, my finder window displays the size of the item I have selected and I’m comparing this size, which I guess is the same as Get Info for, against the result from the shell script. The results all correlate until I select (by chance) an application bundle script. and then I get difference in the size thats displayed in a finder window as to the result from the shell script. Any ideas why this might be?
Thanks,
Nik
Hmm. not sure, but I will look into it. Interesting thing is I’m getting 3 different results myself. Running 10.5.1 and using the Firefox application if I get into on the app I see 47.5 MB. If I run the script the choose file dialog shows me it at 46.5 MB and the results returned from ‘du’ are 48 MB"
Correct Adam, but ‘du -c’ returns the grand total so that should be the same thing as what the finder is returning… so why in my case am I seeing 3 very very close, but different values.
Get Info shows the file’s ‘physical size’ (the size of the disk space allocated to contain the file), not its ‘size’ (the number of bytes in the file itself).
Edit 14.12.07: I was thinking of the “K”, “MB”, and “GB” sizes here. Get Info actually shows the ‘physical size’ rounded to convenient units, followed by the ‘size’ in bytes.
tell application "Finder" to set the_size to physical size of (choose file)
convertByteSize(the_size)
on convertByteSize(byteSize)
if byteSize < 1024 then
(byteSize as string) & " bytes"
else if byteSize < 1048576 then
((byteSize div 1024) as string) & " K"
else if byteSize < 1.073741824E+9 then
((byteSize / 1048576 * ((10.0 ^ 0.5) ^ 2) div 0.1 / 100.0) as string) & " MB"
else if byteSize < 1.099511627776E+12 then
((byteSize / 1.073741824E+9 * ((10.0 ^ 0.5) ^ 2) div 0.1 / 100.0) as string) & " GB"
else
((byteSize / 1.099511627776E+12 * ((10.0 ^ 0.5) ^ 2) div 0.1 / 100.0) as string) & " TB"
end if
end convertByteSize
Hi Nigel
I understand I think but one last question, when we use
set posixpath to quoted form of POSIX path of (choose file)
set filesize to item -1 of paragraphs of (do shell script "du -hc " & posixpath & " | awk '{print $1}'")
is this returning the value of the physical size of a file? and does this mean that if I add a list of Physical sizes together that I can accurately work out how much disk space these items combined would use?
Thanks very much,
Nik
P.S. Interesting the point that Adam makes
you would have thought that because shell thinks a bundle is a directory that in applescript you would have to use choose folder to select a bundle?
The point of packages is that they don’t appear to be a folder to the user. However, if you want the opposite behavior in choose file or choose folder, then you can the the showing package contents parameter that both those commands have.
I’m afraid shell scripts aren’t my strong suit and du’s -h option doesn’t work on the Jaguar machine I’m using at the moment. On this machine, if no options are specified, the last line of the du result is the total number of 512-byte blocks allocated to the file. Multiplying this figure by 512 gives the same physical size as the Finder.
set posixpath to quoted form of POSIX path of (choose file)
set filesize to (word 1 of paragraph -1 of (do shell script "du " & posixpath)) * 512
convertByteSize(filesize)
on convertByteSize(byteSize)
if byteSize < 1024 then
(byteSize as string) & " bytes"
else if byteSize < 1048576 then
((byteSize div 1024) as string) & " K"
else if byteSize < 1.073741824E+9 then
((byteSize / 1048576 * ((10.0 ^ 0.5) ^ 2) div 0.1 / 100.0) as string) & " MB"
else if byteSize < 1.099511627776E+12 then
((byteSize / 1.073741824E+9 * ((10.0 ^ 0.5) ^ 2) div 0.1 / 100.0) as string) & " GB"
else
((byteSize / 1.099511627776E+12 * ((10.0 ^ 0.5) ^ 2) div 0.1 / 100.0) as string) & " TB"
end if
end convertByteSize
Thanks Nigel, Adam, Bruce for all of your input on this. I’d like to continue using Nigel’s suggestion of
set posixpath to quoted form of POSIX path of (choose file)
set filesize to item -1 of paragraphs of (do shell script "du -hc " & posixpath & " | awk '{print $1}'")
It’s efficient and I tend to have more faith in the result of a shell script. Ignoring bundles, is it safe to say that the result returned of the shell script is an accurate representation of the amount of disk space an object will use? I wish I’d never chosen a bundle to use as an example for testing file size now!:rolleyes:
Thanks,
Nik
Great. To be honest the reason that got me thinking about this was from this post http://bbs.applescript.net/viewtopic.php?id=23328 and how I could work out adding the size of each item together whether the size of the item was KB or MB, using finders size seemed to complex a routine. I will give this post more thought tomorrow but for now even insomniacs need sleep.
Thanks,
Nik
Yeah, sorry I realize that the credit should be yours James.
Please accept my apologies, my only defense is that it was very late or very early however you care to look at it!
Here is the result of your efforts, please feel free to dissect it and tell me where improvements can be made. Promise I’ll credit the right person next time
global filesize
global cd_Number
global cd_size
global folder_list
property cd_limit : 665600
property base_file_size : 1024
on open (dropped_item)
set source_folder to item 1 of dropped_item
tell application "Finder"
set folder_name to the name of source_folder
set item_list to every item of source_folder
end tell
set cd_size to 0
set folder_list to {}
set cd_Number to 0
repeat with this_item in item_list
get_file_size(this_item)
if filesize < cd_limit then
if cd_size + filesize > cd_limit then
set cd_Number to cd_Number + 1
my make_CD_folder(folder_list, source_folder, folder_name, cd_Number)
set cd_size to 0
set folder_list to {(this_item as alias)}
else
set cd_size to cd_size + filesize
set folder_list to folder_list & (this_item as alias)
end if
else if filesize > cd_limit then
display dialog name of this_item & return & "is too large to fit on a CD and will be skipped!" with icon 2
end if
end repeat
set cd_Number to cd_Number + 1
my make_CD_folder(folder_list, source_folder, folder_name, cd_Number)
end open
on get_file_size(this_item)
set posixpath to quoted form of POSIX path of (this_item as alias)
set filesize to item -1 of paragraphs of (do shell script "du -hc " & posixpath & " | awk '{print $1}'")
set size_type to last character of filesize
if size_type is "M" then
set filesize to (text 1 thru -2 of filesize as real) * base_file_size
else
set filesize to text 1 thru -2 of filesize as real
end if
end get_file_size
on make_CD_folder(folder_list, source_folder, folder_name, cd_Number)
tell application "Finder"
set cd_folder to make new folder at source_folder with properties {name:folder_name & "_CD" & cd_Number}
move every item of folder_list to cd_folder
end tell
end make_CD_folder
I’ll be interested to see what you discover!!
