Yesterday and today (yesterday with the previous version, and today with the latest version) Panorama X has announced that a file could not be saved (or in the case today, autosaved, as the file was not even the frontmost document.) The alert says,
«The document “.pandb” could not be saved.
It comes in waves. I never get through the month without a couple of dozen instances in which i had to restore from backups. It is getting quite tedious. Does anyone else have this experience?
It just happened again, with a file I had saved as a copy. Some days I feel that I should write to James Rea every time the problem occurs, just so he can get a feel how often it happens, and I could post to this forum every time it happens, but that’s an abusive use of the communications channel. On the same hand, Panorama is abusing its customers by corrupting data in files and rendering them unsaveable. Does anyone on this forum have experience with this problem, and how it might be avoided?
I thought I had a clue, but maybe not. A particular database has a custom icon. I copied a backed up copy which is thought to be good, opened it, edited it, and saved it without a problem. Then, I changed the icon to a custom icon. Opened it, edited it, cannot be saved.
I did this a couple of times.
But then, Panorama decided that even with the new icon, it could still be saved.
We’ll see how long Panorama has that opinion.
Only once that I can remember in more than four years of fairly intensive usage, which is as rarely as I’d expect any individual single-file document might become corrupted randomly, let alone a package such as a Panorama document which contains many individual files.
Are you saving the documents to a mirrored Dropbox folder or similar? That is one situation in which packages may easily become corrupted. See Data loss in b26 4060?
My files are on an internal disk. Mr. Rea has told me that he never hears of my experience, which is interesting, because it is the most common problem I have had with Panorama X since upgrading nearly a year ago.
There is a subroutine somewhere that puts up the dialog that says a file can’t be saved; it would be neat to have a debuggable version that would say exactly what piece of data was causing the file to be unsaveable.
rtin,
It can be frustrating to have such a persistent bug and be alone on that “bug island”. But usually, a particular bug - if native to the app itself - is experienced by a variety of people.
In my experience, if that “critical mass” of other people’s experience is not there, then I have to look at my own particular situation; i.e. what am I introducing to the mix.
That said, reading posts here, you will find bugs that maybe only one SUPER user (coughing into my hand while whispering “Jim Cook”) experiences. But it would take me half a lifetime to configure my (single-user) system to mimic their environment.
In your case, you seem to have traced the problem back to a custom icon. Unfortunately, just that information throws up a bunch of question marks or red flags. "Custom could mean you got it from an independent vendor or created it yourself with some app. Given all the recent hardware and software changes, whatever one uses, diligence requires making sure it is compatible with your current hardware, OS, and apps that will be interacting with it.
One place to start is to make two test environments. In one, with a small number of records/fields, put the custom icon. Also, duplicate that database, but without the custom icon. Work with them both and see if the bug appears.
If it doesn’t, then there might be something else going on in your real database and the icon might be a red herring.
Without more detail, not much more can be said. When I need to solve an “unknown”, first I back up to a point of goodness. That means removing as much as I need to - even if it is back to just the datasheet and a few records - to get to a place where everything at that point works.
Then I slowly add components back in, testing as I go, on a march towards the final database setup that has the problem. Somewhere along that path, the problem will occur. When it does, then, just to be sure, go back one step from the last thing you added, and verify that things work. Go forward again and verify that they don’t work. If all that checks out, you’ve found the bug.
And, if the bug occurs when an icon from a third-party source is added, it certainly deserves a discussion with that third-party source.
Now maybe by custom icon you mean it’s from the FontAwesome collection that comes with Panorama. But I don’t know that. And though it appears the icon might be an issue, unless there is a rigorous A/B test (with and without), we can’t be sure of that either.
OK, this is a good observation.
Most of the files I use have custom icons, and most of the time they work. I’m not sure that I have experienced the problem on files without custom icons. I will just do without custom icons for a while, and see if the problem recurs for sure without a custom icon involved.
This is certainly confusing. I have a copy of a file with a custom icon, and one without a custom icon. The one WITHOUT the custom icon, if I look at it in the finder and say “view contents”, it shows a file named “Icon?” with 16.7 megabytes.
But the shell does not agree. ls -l says,
-rw-r–r–@ 1 rts staff 0 Nov 15 07:35 Icon?
Also, my hex editor thinks that file is blank.
The one WITH the custom icon, if I say show package contents, does not show a file named “Icon?” at all. Terminal reports there is a file named Icon? with 0 bytes of content.
At the moment, both files are allowing themselves to be saved, but few minutes back, the file WITHOUT the icon was saying it couldn’t save the content.
These machines sure do gaslight you.
Yes - but tell us more about this custom icon. Where did it come from? How is it used?
And again, the icon might not be the issue at all.
Also, what version of Panorama are you using? If PanX, what build number?
Riddle: When does a custom icon identify as a woman?
, when it’s amiss. As it appears to be in your case.
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.
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.
I created a copy of a small database with the Save as … command in the File menu; then I added a custom icon to this database (that was still open). When I tried to save the database now a warning appeared: “The file has been changed by another application.” with options to save it anyway or to revert it.
If you say I’m the only person with the problem, then I’m the only person with the problem. Interesting. I will be paying close attention to the correlation between custom icons and the failure mode. Looking around at the various instances of failure, I find that all of them have been in files with custom icons. I can well understand your not wanting to budget time to delve into the vicissitudes of Apple’s file structure if the problem only affects one user and can be avoided.
Thanks for all your suggestions
Note that this dialog is not generated or managed by Panorama’s code, it is entirely from Apple.
rtln,
It’s not that Jim doesn’t want to budget time to delve into Apple’s code. Jim, as both President of ProVUE Development and the Chief designer/maintainer/updater of Panorama, has demonstrated time and again his willingness to “get to the bottom” of any PANORAMA problem.
But if the messages you are getting are generated by Apple, the tech source to call is Apple. Or the developer of the custom icon or app used to create the icon for a discussion about its compatibility with current Apple standards.
Jim has no power or control over Apple’s code. And though in the far past, Panorama employed a variety of internal workarounds to deal with Apple’s anomalies, that good-hearted effort put Panorama owners more and more in jeopardy whenever Apple changed something.
PanoramaX was a decade-long effort of recoding it so it follows Apple’s rules. What that guarantees is, usually, when Apple changes something Panorama continues to work without some hurry-up fix needed. As with most things in the world, that’s not 100% of the time. But it’s a great deal true most of the time.
In your posts, you have still not given us any information about this custom icon, Where did it come from? How is it being used? Are you pasting it in as a decorative graphic? Are you layering it in a display object?
From what little experience I’ve had with Tech Support, I can tell you that it is very difficult to find a problem that doesn’t show itself. Many people on this forum are willing to help, but to do that, more information than what you are providing is necessary. For example, how would I set something up so that I can experience the same error message? What OS are you using? What is the Panorama Build Number? Are you on an Apple Silicone Mac or one with an Intel CPU? Yes, most likely none of that information matters. But it might.
It helps to think like this:
This is my machine (computer hardware)
This is the Apple OS
This is Panorama Version (Build Number)
This is the Suspected Icon (I believe you can upload a .jpg)
It was created with or supplied by this … (version numbers if available)
I’m using it this way in Panorama …
As I mentioned before, a possible first step is to isolate the problem in its smallest environment. For example, if someone’s 50,000 record database won’t sort as expected, you don’t need 50,000 records to solve the problem. You just need a few records that display the unexpected sort.
If your custom icon is in a form, when you copy just that form to a separate database does the problem come along with it?
I’m not so good with “emotions”, I’m better at Fibonacci numbers. But I can sense that your frustration is tied to the idea that this is a Panorama problem and because you are the only one experiencing it, you are not given the time of day. Let me assure you that is not the case. But again, for others in this forum to contribute their knowledge, they need to know more about the components and ideally be able to duplicate the problem.
One simple “tell” is to just remove the icon. Again, because we don’t know if you are using it as a button, or just a static graphic, I can only suggest generalities - like using a Panorama Button object in its place - assuming you are using the icon as a button - and see if the message goes away.
And in that testing, it’s best to restart the computer between have and have not. In the olden days, things were simpler. It’s like looking under the hood of a car. Back when my neighbor was rebuilding his Ford every weekend for a date, all the parts were visible - not so much now when you look under the hood. Things - remember, it’s a feature - can be cached so they are retrieved on the next launch - reinfecting the situation even though it seems you’ve eliminated it. Probably that’s not the case at all. But we don’t know.
I’m not ready to declare the custom icon the problem. Not enough is known about it. But a first step would be to run the database with it and without it and see if the problem goes away. If the problem is still there without the custom icon - then we can drop it out (simplify) of the picture and focus on other aspects.
Paul, I’ll admit he never flat out said this, or explained exactly what he did, but I’m pretty sure he has added the custom icon in the Finder, not inside Panorama. Probably using the Get Info window.
Me either.
I just tried adding a custom icon to a database, it worked no problem. I didn’t get the dialog that @kjm saw, but maybe he had the database open when he added the custom icon? I did it with a closed database.
Of course maybe if I keep using the database with the custom icon for a while a problem will happen later. But for starters, it worked fine.
I did look at the contents of the database file and found the Icon? file, the finder said it was 900k. Tried to open it with a file dumping tool, looks like it has no data, but it has a resource fork that contains a PNG image.
Holy 2001 (OSX), or 2005 (OSX Tiger), or 2017 (OS High Sierra) Batman!
and the AI says, “Overall, while resource forks have not been entirely removed, their use has greatly diminished over the years as Apple encouraged developers and users to adopt newer paradigms.”
You mean like a custom icon instead of that Rubics Cube looking one? A custom desktop icon for launching the PanX app or a custom icon for a PanX database; that kind of custom icon?
So it’s not involved with the innards of the database per se - just how Apple manages its file icons, and what structures it allows.
Hopefully, rtln will get the error without this pesky icon and the flashlight of goodness will be able to focus on a more guilty corner of the room.
I appreciate everyone’s concern, but if I am truly the only person in Panorama Space who experiences this particular problem, we must ask at the outset how much time it is responsible to spend on it.
The icon issue is a possibility, but it may also be a red herring. My custom icons are made in an old copy of Photoshop, or in Graphic Converter, and they are inserted either using the Info window of the finder (which sometimes doesn’t work, another problem which is unlikely to be a Panorama problem) or using Image2Icon, which always applies the icon but who knows what else it does? And I don’t expect unpaid total strangers to make big files on Macbook Airs running 14.3 (23D56) to try to reproduce an issue that only happens, say, once a week on any given file, which is a lot if you’re trying to use the program, but pretty rare if you’re trying to reproduce a bug.
I will continue taking notes. I’ll be very interested if I lose data on files that don’t have custom icons, now that the possibility has been raised that icons could be a part of it.
And to clarify for your amusement, the nature of what happens (it hasn’t happened today, this being the way of the gods):
When an attempt to save a file brings up the alert that it cannot be saved, sometimes a duplicate can be saved and sometimes not. Reverting the file does not always do any good. Sometimes the reverted file can be opened and used normally, but more often it is permanently in the state that any future edits made to it can’t be saved.
Often, the last few saved versions have gone bad as well, “bad” meaning specifically, that when you open the “bad” files, and make an edit, an attempt to save the file will lead to the alert. They can always be opened, and you can often perform operations on them (including exporting as text, which is how I have saved some data), but when you try to save, you get the alert.
Hmm, continuo
Have you checked your disk with Disk Utility? Sometimes you need to try the old methods.
Isn’t this interesting. I have a collection of “bad” panorama files on my disk, by which I mean, files which can be opened and manipulated, but which cannot afterwards be saved.
I made a copy of such a file; verified that it could be opened and edited but not saved, and then did “show package contents” in the finder. There is a 16.7 megabyte file - or whatever the entity is - in the package, called “Icon?”
I deleted that file - using the finder - “Icon?” is now in the trash.
When I return to the finder view of the directory it’s in, it now displays with the system Folder icon. But double clicking that folder icon causes it to open in Panorama. And I can edit it. And I can save it, without the system dialog that it cannot be saved.
The file now displays with the default Panorama icon. I can open it and the changes made by the edit are still there, and I have edited it again and saved it again - no telling if the cannot-be-saved problem will recur, but I have performed the steps described here three or four times, and the same results were observed.
(Curious as to why Panorama files are a package at all. My .xlsx files aren’t packages. Some of them have custom icons, too. Somebody else’s design decision.)
