The Booking Confirmations folder contains three text files only
Even though there are apparently only 3 files in the folder, foldercount( returns 4
I’ve seen this a couple of times recently and have stopped using foldercount(, fortunately there are workarounds.
Foldercount( is counting the files listed by this function.
filecatalog("~/Downloads/Booking Confirmations","hidden","true","insidepackages","true")
You will notice that includes hidden files, so that might account for the discrepency.
Yes, it’s odd.
If I take a folder containing two files (and no folders, and no hidden folders or files), foldercount( correctly returns 2.
I create a blank folder there (to make 3 objects including 2 files) it still returns 2.
However, if I then I copy a file to that folder (to make 4 objects, 3 or which are files) it now returns 4.
I delete the folder, leaving just the original two files, but foldercount( now returns 3, and if I delete those files it returns 1 for the empty folder.
Restoring the original two files, it again returns 3.
If I create a new empty folder within the original, and another nested within that and another nested within that, thus now a total of 5 objects including 2 files) it still returns 3.
However, if I now copy a file into the deepest folder (so there are now 6 objects, 3 of which are files) it now returns 6
If I delete the newest file to leave 5 objects (2 files and 3 empty, nested folders) it still returns 6.
If I delete the three nested folders to leave just the original 2 files, it once again returns 3.
While doing all this I had hidden files visible and there were none at any stage. But it seems that a folder containing a file (even if more deeply nested) is wrongly being counted as a file itself, and when files are deleted that error is corrected but the total ends up 1 more than it should be. Experimenting further after the above, repeatedly adding and deleting files and nested folders, I always end up with an error of 1 when I get back to the original folder contents.
I assume this must be an OS error, nothing to do with Panorama, but it‘s still bizarre.
… especially because the function gives the same answer before and after quitting and restarting Panorama.
The extra file seems to be .DS_Store. Even when invisibles are being displayed, that file doesn’t show up in the Finder, but FileCatalog( with invisibles included, and ls -a in Terminal both show that it is present.
Well, thanks Dave, this was news to me. I’ve looked up .DS_Store, and wonder why it is counted by foldercount when it is not by listfiles, and what use this could possibly be to Panorama users (other than sowing confusion and dismay), given that Terminal is available to wizards when you need to access this level of the underworld.
As Dave has established, this is not an error in Panorama nor is it an error in macOS. This feature works as intended. The count is the number of files that would have to be duplicated if you made an exact copy of the folder, so of course hidden files must be included.
I’ve added a note in the documentation that hidden files are included.
Even if there weren’t any hidden files, you would usually not expect foldercount( to return the same value as listfiles(. The listfiles( function is “shallow”, it only lists files (and folders) directly in the specified folder, but not any subfolders. In your example there were no subfolders, but the foldercount( function was created for use when there are subfolders, and you want to be able to count all of the files at every level. If you want to count the files directly in a folder without any subfolders, you have always been able to use a formula like this:
linecount(listfiles(...))
In general, I don’t think I’ve ever needed to do this, though I have written code like this many times:
looparray listfiles(...),cr(),filename
...
... do something with this file
...
endloop
This allows the code to process each file without even needing to count the files.
Wiki gives some history on those system files for folks unfamiliar with it. Sounds like OSX 10.12 started the practice of the Finder never displaying it, no matter what “show hidden files” trick was used with the Finder. I recall old tricks once showing .DS_Store within every FInder window. When seen you delete it, but the system would soon generate a new one. Some Finder options reverted to default values with the new one. With that behavior changing at 10.12 perhaps some folks clinging to old systems to run Pan6 still see the prior behavior. Not really a Mac ‘bug;’ Apple design style changes over time.
Apple still provides methods to variously see only non-hidden files, visible plus other hidden files or (via terminal) all files including .DS_Store. PanX tools provide all three options. Pick the option you need. If you know you don’t want .DS_Store in your result you can filter that out with Arrayfilter(.
