Yesterday I was contacted about errors in another sharing system. And again, I turned to the logs for clues - aware that we don’t want every nuance being routinely recorded.
One of the first symptoms of the problem was a dialog on a client machine:
The log was showed two different errors recorded many times.
UPLOAD FILE ERROR: FileAppend error: You don’t have permission to save the file “TempTransfer” in the folder “Documents”.
SYNCHRONIZATION ERROR: FileSave error: The file “2025-04-03-15-29-02-933-3302823829.data” doesn’t exist.
I used that to track down …/Library/Application Support/PanoramaX/Server/Documents/TempTransfer where I found 2,315 .data.zip files. For some dates there were none, other dates have from 1 to 4 such files. Occasionally there were 20 or more for a given date. I have no idea what to do with them, if anything.
What I did do was set Permissions on the enclosing folder to give everyone read and write privileges.
I also ran a Critical Update New Generation for the client file that first encountered the error in the hope that might clean something up.
Their office will be opening for the day soon, so we’ll find out if the problem persists or if I managed to jiggle the handle adequately.
I’m a bit puzzled - it sounds like this system is unusable, yet if they managed to generate 2,315 files they must be using it. Are these errors occurring on all client machines, or a subset? What action was being performed when the error occurred?
This error message originates in the code used to upload a file to the server. It’s used when you first upload a database to the server, when you upload a new sharing generation, and when you upload a form or procedure.
If the file is a significant size, it is uploaded in pieces. As each piece is uploaded, it is appended to the portion that was uploaded previously. So that it why the error message mentions “append”. The file is uploaded into the folder you tracked down -
Certainly Panorama needs full read/write access to this folder. In fact, Panorama would expect to have full read/write access to everything inside
/Library/Application Support/PanoramaX/
This error originates in the code that handles synchronization on the server side. This includes not only synchronizing the data, but possibly also the entire database structure (forms, procedures, fields, etc.) if the client requires an update due to a new sharing generation.
On the server, the synchronization process works by figuring out what needs to be updated, then assembling a file containing that updated info. That is what the 2025-04-03-15-29-02-933-3302823829.data file is. After it creates that file, it compresses it into a .data.zip file, and then erases the .data file. It then sends that compressed file to the client. When the client has finished downloading the file, it signals the server, which then deletes them. So normally there should be none of either the .data or .data.zip files in that folder except for a very short period. That’s why the folder is called TempTransfer - it’s for temporary files.
I am puzzled by the existence of these files. The synchronization process first does a filesave to create the .data file, and then compresses them into a .data.zip file. But if there is an error in the filesave, the process should be aborted at that point and no .data.zip file would be created. So where did those files come from? I guess in some cases maybe it did work - but there was an error on the client so it never signaled the server to delete these files??
You should just be able to delete them. But before you do, I am curious - do they have anything in them? Are they empty? Maybe try manually unzipping one to see what is inside? It should be a non-zero size .data file, or possibly a .pandb file.
By the way, though having these files sitting around in the folder indicates there was a problem of some sort in the past, these files won’t cause future errors. If you don’t delete them, the only consequence will be a bit of wasted disk space. Conversely, deleting them won’t fix any future problems.
Once the server has prepared a .data.zip file, the client downloads it, and then uncompresses it. To do that, it checks what sort of compression it is, using this simple code:
So what this tells me is that the file that was downloaded was not .data.zip, but ended in .local:8080. Yeah, I’d say that is unknown. Actually, it is the IP address of the server, or at least it would be if the client software is running on the server. But that should not be the filename. Maybe the server problems are winding up with this bogus filename being sent to the client? It should handle the error. Of course, I never did test the system with broken permissions on the server!! No one expects the Spanish inquisition.
Well, I guess that won’t hurt. However, if the folder already gave read and write privileges to the current user, this won’t change anything. There is only one “user” on the server computer, the user that is logged in on that machine. The server doesn’t know or care about the users that are logged in on the client machines. All requests to the server come in as anonymous TCP/IP packets. Yes, those packets contain information about the various users, but that information is privately handled by Panorama and doesn’t interact with the server’s file system. In other words, all file activity on the server is performed by the user logged on to the server machine, NOT by the client users.
It does sound like there is some problem with file access permissions on that machine. Keep in mind that this sort of problem can originate with ANY folder up the chain, not just the immediately enclosing folder. Also keep in mind that permissions can also be controlled by Access Control Lists (ACL), which are rather mysterious to me and most others. Perhaps an easier solution would be to simply delete the entire.
folder. Panorama Server will automatically recreate this folder the next time it launches. Or, even more radically, you could delete either the
/Library/Application Support/PanoramaX/Server/
or even the
/Library/Application Support/PanoramaX/
folder, but those will not be automatically recreated. For example, you would have to re-upload all databases after deleting either of these folders (or perhaps copy and then restore the Public Databases folder).
I don’t think this would fix anything, but it seems encouraging that this worked without generating an UPLOAD FILE ERROR, I assume you checked the log after doing this.
Thanks for the lengthy explanation. It does help to understand more about what’s under the hood.
This error just began yesterday on a system has been in daily use by several people for some time. The dates of the .data.zip files went back several months. I will delete them per my expanded knowledge.
The one database I “up-gen’d” was synching fine for me. Not everyone was in their office at the time but I sent it to the one who was working and experiencing the errors. She reports that the replacemnt copy resolved the errors. Server or client side we may never know, but at present it seems conquered.
I’ll watch that temp folder to see if there are any future back ups of un-deleted files.
And I will unzip a couple of those files and let you know what I find.
That’s all very concerning. Fingers crossed that the problem is resolved. It certainly does sound like a permission problem of some sort, but why should that start happening one day out of the blue? Anything change on their system yesterday? A system update perhaps?
I would like to second this and confirm that my TempTransfer folder contains 1823 .data and .data.zip files dating back to March '23.
I unzipped some of the files and confirmed them as non-zero size files.
Unrelated, but I started investigating a noticeable decrease in server speed when opening and syncing DBs, and locking and committing records to the server, when I came across this thread.
After reading the explanation, I decided to delete these files as well, unless there is any reason to keep some of them for further investigation.
Regarding the slowing server, be sure to have Instrumentation off on a busy system. I found that the log can become immense, such as in Gigabytes. It causes increasingly serious slowdowns everytime something gets added.
That said, the server I was dealing with the other day has continued to retain the TempTransfer files. My own server does not.
And there’s a third server on which I continue to pursue the cause of more frequent beachballs as it’s used each day. I’ll share anything I find with you, Hugo.
