Filesize( & Fileinfo( don't work with Panorama X files

Panorama X
1

I believe this was touched on some time ago but I thought I would resurrect it at this time. Neither of these functions will return a usable result for a Panorama X package file (or a folder for that matter). Fileinfo( simply returns a 0 for that item while filesize( generates a rather strange error when used on a folder or package (Panorama X database file):

filesize(“/Users/garyyonaites/Documents/Test.pandb”) The file “Test.pandb” couldn’t be saved in the folder “Documents”.

Could not be saved? Oh well, here is my work-around that works for both folders and package files to return file or folder size in bytes and properly formatted:

pattern(val(tagarray(shellscript("ls -l "+unixshellstring(path)), "total "," ",cr()))*512,"#,")

Removing the *512 will leave it as blocks.

2

I cannot duplicate the error message you are describing. I get an error message like this (sometimes the error number is #3)

- filesize(“/Users/jimrea/Documents”) The operation couldn’t be completed. (Cocoa error 2.)

Your workaround uses a feature of the ls shell command that I wasn’t aware of, that the # of blocks is displayed on the first line of the generated output, like this:

total 88
-rw-r--r--  1 jimrea  staff  2423 Aug 25 14:33 data.archive
-rw-r--r--  1 jimrea  staff  2269 Aug 25 14:33 data.plist
-rw-r--r--  1 jimrea  staff  4454 Aug 25 14:33 fieldconfig.archive
-rw-r--r--  1 jimrea  staff   236 Aug 25 14:33 forms.archive
-rw-r--r--  1 jimrea  staff   644 Aug 25 14:33 printinfo.archive
-rw-r--r--  1 jimrea  staff  9235 Aug 25 14:33 procedures.archive
-rw-r--r--  1 jimrea  staff   233 Aug 25 14:33 settings.plist
-rw-r--r--  1 jimrea  staff   367 Aug 25 14:33 variables.archive

If the folder contains a file name that contains “total” within the name, using tagarray( could calculate the wrong value. I thing using tagdata( would be better. I’ve spread the formula out over multiple lines to make it more readable.

pattern(
    val(
        tagdata(
            shellscript(
                "ls -l "+unixshellstring(path)),
                "total ",cr(),1
            )
        )*512,
    "#,")

However, in my tests I found that the output of the ls shell command isn’t reliable, or at least it doesn’t always agree with the Finder’s Get Info window. When I tried to use it on my Documents folder it was way off, nearly an order of magnitude. I don’t know if the problem is in ls, or in Get Info, or both. I did verify that the calculation manually using the terminal output, so I know that ls is the problem and not the Panorama code.

Another question would be “what is this number good for?” It’s not the actual amount of data in the file, which is generally much smaller. You could theoretically calculate that from the ls output, though that would be quite a bit more complicated, and could be quite slow if a folder contains hundreds or thousands of files (don’t forget that folders can be nested within folders within folders).

Still, Gary’s solution is quite clever – bravo for noticing that ls has this feature.

3

Here is the procedure and the error message it generated:

image
image963×268 71.2 KB

Yes, I forgot to change the tagarray( to tagdata( from a previous experiment with the code.

It seems every method I try to get a size value produces something different. I kind of thought of this simply as a guesstimate.

4

Ok, I tried the same procedure and I still didn’t get that weird error message – I got the same error message I described above. I have no idea why we are getting different results.

What other methods did you try?

I did get the same result every time – it just didn’t agree with the Get Info window.

5

I did some additional Google’ing and found out about a shell command I had never heard of – du. It looks like it will produces the desired results. Do a google search for

macos shell du command

and you’ll find the details. I was able to get the correct number of blocks in my Documents folder with this. (I am not sure, however, whether it is always valid to multiply by 512, I found references that some systems may use 1024 or other sizes. I’ll leave that further research to someone else.)

It looks like the du command is also easier to parse, probably no tagdata needed.

I am not inclined to include this as a built in function in Panorama X, however. So far I have managed to avoid having anything in Panorama X rely on AppleEvents, which means nothing relies on shell scripts. If I do use AppleEvents, that becomes an issue with Mojave and later. It’s not impossible, but requires the user to make changes to system settings, and I’d rather not require that unless absolutely necessary.

6

The du unix command returns the disk usage statistics for the target folder or file. If you use the -k option it will return the number of 1024 byte blocks. If I use du without any options it returns the number of 512 blocks on my system. Using the du with the -h option returns the size in rounded kilobytes (#.#K) or megabytes (#.#M).

The Finder’s Get Info shows two values: the file size and the disk usage. The disk usage is shown as a rough, rounded value while the file size is shown in bytes. I haven’t found a unix command that shows the actual file size although this might be available via AppleScript.

7

I quit and restarted Panorama X and still got the same strange error message. Still using OS X 10.13.6.