Most likely the icon is stored in the files extended attributes.
If you read this, you’ll see that the ls shell command knows nothing about extended attributes, so will not report the correct size.
You can find lots more about these by doing a google search for
macos extended file attributes
This alert is not generated by Panorama – it is generated by Apple code. If Panorama encounters an error when saving a file, it generates an error message and passes that back to Apple, which displays it. For example, if the data in memory is somehow corrupted, Panorama will detect that and pass the error message to Apple, and the message is displayed. Also in that case, the file on disk is not touched - so you can still open it, it just won’t have whatever the most recent changes are. But there is no need to go to a backup.
In your case there is no Panorama specific error message, so I don’t think Panorama has anything to do with it. This seems like a purely Apple involved error. Maybe there is a permission problem with the folder you are saving to.
I do think it is interesting that the message has no filename. You say this wasn’t the frontmost document, how do you even know what document it is? Panorama has no concept of a database without a filename - so again, this seems to be a purely Apple problem.
This subroutine is in Apple’s code. ProVUE cannot generate a debuggable version that provides any additional information about this situation. Maybe there is something in the console log.
I don’t know anything about custom icons. Panorama has zero knowledge that a file even has a custom icon - Panorama does not deal with extended attributes in any way. In fact, Panorama doesn’t directly access the disk at all when saving - it simply passes data to Apple’s code which handles all of the file operations. These operations are completely isolated from our code.
On the other hand, ProVUE has done zero testing of databases with custom icons attached. Panorama’s code knows nothing about custom icons, but maybe Apple’s code that we rely on has a bug in this situation. Not impossible, I suppose.
Let me elaborate further on this. If the file in memory didn’t save, then that means that the original disk copy of the file is untouched. It should be fine - no need to restore from backup. One thing you haven’t said is why you are restoring from a backup, it sounds like that means that you were unable to open the original file on disk. Was there an error? did it crash? did the metadata change so that it Panorama no longer recognized that it was a Panorama database?
I just did a search of this entire for "could not be saved". Out of thousands of posts, there are 10 matches. One is this topic right here, it is the only one that mentions having to restore from a backup, and the only one that indicates that there was no filename in the error message.
There is one from 2023 that was definitely caused by using Microsoft Onedrive.
Before that, the most recent two were in 2021, but those were specifically about not being able to save due to in-memory corruption.
There’s a topic in 2019 that has nothing to do with saving.
The remaining topics are from 2016 to 2018. In one case the user was attempting to save the database inside the /Applications folder. In another case the person saved the file inside the Application Support folder, then moved it to the desktop. None of these really match the symptoms you are describing, none of them required restoring from backup, and in any case, all of them occurred on what are now ancient versions of macOS, in some cases before it was even called macOS.
- The document “SN X.pandb” could not be saved. The file doesn’t exist
- The document could not be saved
- Document could not be saved. The file doesn't exist
- Panorama X getting tired when working hard?
So yes, I’m sticking to my story - you are the only person that has reported this.
This is way out of line. Further comments with this tone will not be tolerated.