Mac Air M1 2020 running 12.4 Monterey – good news is this seems faster in the 15 minutes I’ve used it. Oddity is though in a fairly simple catalog of opera information where some fields have “number (integer)” data that is simply hand-entered.
The first time I opened the file (which lives in DropBox) 2 or 3 of these fields (there are maybe 10 such fields) displayed only zeros. I retrieved a backup copy and the next time I opened it only 1 of the fields was zeroed. The Dropbox file that I opened with b26 also now shows the zeros when opened with the prior version of Pan on an older computer.
There seem to be varying results with 1 or 2 of the 3 problem fields each time I open a copy of the undamaged file. A sample – now (grasping for ideas here) perhaps the slash in the field name causes a new problem with b26?
There is no fair way to test a Panorama file that resides in Dropbox. Before any analysis or bug report is made, ensure that the file is residing on a computer.
Dropbox is a fine place to store files. It is not designed to be used for live updating of file data. You are essentially ensuring corruption of data by using a Panorama file if it is being used while in a Dropbox.
I think you have code in your database that you have forgotten about that is intentionally recalculating these values to zero. Perhaps in an .Initialize file. If the database was corrupted, Panorama would detect that when opening the database. (I’m assuming you haven’t disabled the database integrity option in the Advanced preferences panel.)
I agree with Robert that it’s risky to keep live files in Dropbox. However, if a file does get corrupted by Dropbox, Panorama X 10.2 will detect that.
No.
One other point – since you have the file on Dropbox, that presumably means you are accessing the file on multiple computers. So perhaps it was opened on another computer where the field was modified.
ive been using dropbox to store panorama databases since the beginning of time with no ill effects.
now, i am not allowing any file to be open in more than one place, but im pretty sure there wont be any issues using dropbox as a place to park single user databases.
i’ve stored multiuser databases on dropbox too- a panorama shared database is only ever open in one spot so dropbox has always worked fine .
Chris, I appreciate your experience and knowledge but I’d like some clarification on your ‘coached’ words. When you say 'as a place to park single user databases, does that mean for them to reside on Dropbox while you open, modify, and Apple continually auto saves those files to Dropbox?
You also mention ‘stored’ user databases.
My experience tells me that Dropbox is great for parking & storing files, but actually using it as a place for a file to reside while in use by an application can cause problems.
Jim might correct me here, but I suspect the reason to avoid opening a Panorama X database direct from Dropbox (as opposed to storing it there, but copying it to a fixed location and opening that copy) is that a Panorama X database is not a single file but a package, which appears in the Finder as a file but is actually is a directory structure containing many individual files and folders.
When using Dropbox or other similar cloud storage solutions such as NextCloud, the desktop client maintains a mirror, in a dedicated directory on a local drive, of the files stored in the cloud. Any changes made to the local copy are automatically mirrored to the cloud copy and vice-versa. However, this process does not happen instantaneously. When a single file such as PNG or a ZIP archive is mirrored in either direction, either the old or the new version will be available in any location at any point in time and there is no ambiguity. The same goes for something like a Microsoft .docx file which is a directory structure saved in a ZIP archive: the archive is a single file, thus an attempt to open it will always find either the old or new version complete. But to Dropbox, a Panorama X database package is nothing special, just a normal directory containing many files to be mirrored one-by-one. Every time the database is saved — and of course macOS auto-saves frequently — the local copy is updated quickly but the remote mirror will catch up more slowly, and until it has completed it will be in an indeterminate, effectively corrupted state, containing a mixture of old and new files. Similarly if the remote server contains a later version than the local copy: during the process of mirroring from the former to the latter the status of the local copy will be indeterminate — there will appear to be a Panorama X package there, but its internal file structure will not be valid until mirroring is completed. Thus any attempt to open it during that process might either fail or, worse, lead to more insidious problems that don’t come to light until too late, after that damaged version has been resaved.
Most of the time this will not happen, because if a database is only used on one machine at a time, during that session it will be opened from and saved to the local copy only; all mirroring will be from that to the remote cloud copy, and it will only be the local mirrors on other machines sharing that Dropbox folder that might be in an indeterminate state while they catch up with the remote mirror. However, there is the potential for things to go wrong because, with Dropbox controlling the folder in which the database resides, you can’t completely guarantee that the local copy will always be in a stable state when opening or saving.
Hence it is safest to copy/move the database from the Dropbox mirror folder to a normal folder which Dropbox doesn’t control, open that copy, and copy/move it back to the Dropbox folder after it has been saved and closed.
I have a couple of Panorama databases that I keep in Dropbox, making them accessible on my various machines. And I keep them there. I have one that is my daily log for hours worked on projects that I make entries into every day. It works fine and is instantly synched if opened on another computer.
Obviously opening it on two computers at once and making changes would not work.
A folder on dropbox is where i keep all my panorama files during development, deployment, and for backups. The dropbox folder is used ONLY by me, in that i use it as a remote drive on all my devices. I do NOT try to open the same file on multiple devices or use dropbox as a way for multiple people to access Panorama files. When i have a multiuser database, each user gets her own copy, and can keep it anywhere, including on her own dropbox.
I’ve never run a server from a dropbox volume, but that would be kinda silly anyway.
I have never encountered a problem with this workflow, Panorama sometimes has issues, and Dropbox sometimes has issues, but in my experience there are no problems with using Dropbox as a place from which to develop, store, and actively use Panorama files.
I understand there are different ways to configure dropbox, I have mine set up so that cloud files are mirrored on local drives, and that modified files on local drives are automatically updated in the cloud. This would definitely cause a problem if multiple users, or multiple devices were attempting to write to their local cop[ies at once. This has never been a problem in practice, so it’s not something I think about often.
Hope that clarifies things. Also, the fact that Panorama files are packages isn’t a problem. Packages are folders that will contain open files and unopened files just like any other folder and dropbox handles this just fine.
Nope, I will commend you. I think you did a better job of explaining this than I would have.
No, @pcnewble is correct, as far as I know Dropbox does not guarantee that packages will be transferred atomically, and the contents of a package can be in an indeterminate, partially updated state during the transfer process. This was not the case for Panorama 6, which used a single file rather than a package with multiple components.
I live close to Pacific Coast Highway (PCH) here in California, a busy 4 lane highway that runs next to the beach. Every day, dozens of people jaywalk across this highway to get to the beach, dodging the traffic. In 40 years, I’ve never heard of anyone getting seriously hurt. But I certainly wouldn’t advocate that this is a good practice for getting to the beach (even though I’ve occasionally done it myself).
Of course working with files in a Dropbox folder (or other sharing service) won’t get you injured or killed, and it can work if you are always vigilant – but please do not recommend this practice on this forum. Many users will not be careful, will not understand the risks even after explanation, and if there is a problem, I know that Panorama will get the blame, and I don’t want to hear it. And for that matter, I don’t want people to have a bad experience.
i don’t think i recommended the practice, i just said ive had no problems. because i close my files before i switch computers there is always a minute or two for the local copy to get updated.
There is a checkbox at the bottom of the Dropbox widget because sometimes Dropbox can not do what we’d like for it to do and keep things synched. I interact with hundreds of users of Dropbox and when there is a problem they…
Well, many really don’t do anything. They wait for me to come along and resolve the issue. I have seen many times where their synching was not happening for many reasons that they did not want to bother to figure out.
Some users choose to retain local copies of their Dropbox files, others choose to run from the only copy on the Dropbox site. Some users are not attached to their network at intermittent times while others have reliable connections. The differences just add up to too many issues out of the control of Dropbox to assure continuity of file updates for some users who want to expect data reliability. My thoughts and I’m sticking to it.
Sorry, I didn’t mean to single you and Jim out, your posts were convenient for me to quote at the moment. There definitely have been posts in the past where this practice has been essentially recommended.
The link you sent was quite interesting.
However, I’m not sure if this one quote from this long paper:
Finally, folders and files support atomic moves independent of their subtree size.
really indicates that Dropbox will reliably sync packages atomically. Maybe it does, but I’m not sure I’m convinced from just that one reference. Especially since it says “support”, not “guarantees”.
Presumably if the checkbox is checked then we are good to go. Though really you need to make sure that checkbox is checked on both the source and the destination computers. Sometimes I will do that, but I very much doubt if most Panorama users would check this box on both computers before proceeding to open a Panorama database. And just looking at the checkmark isn’t really enough - you have to check the list of recent files. Sometimes the box is checked because the destination computer doesn’t even know any files have been updated.
Bottom line, Dropbox is a great tool (that I rely on), but you must use it very carefully.
Might be important to know if the file is dropbox only or local. Mine are local. In literally thousands or tens of thousands of accesses of scores of files using two computers, by me, never at the same time, there has never been a problem. Ever.
Not accessing at the same time, ever. Just so I can access the files in the old days, before I started using my Air as my only computer with a large monitor, about 3-4 years ago. I am very careful not to access at the same time, even though all Panorama files are local, not lodged only online in dropbox. I really don’t think this is an issue. But if it is, it only started on the date I posted with the latest update.
If it were so, it would oddly only have happened with a file that dates back 20+ years once I installed the new update. So there’s that.
But there are not .init items in this ancient file. And if there were, again, they’ve worked fine for years. The affected fields were siimply hand-entered numeral fields counting how many times a particular opera had been attended. About the most basic sort of thing one can imagine.
Anyway, since the initial shock and the hours spent recovering data from archives and updating, there have not been any problems. I have no idea what or how this was caused. It happened; I fixed it; it hasn’t happend on any other of the 30+ files I use frequently, and some I depend on for important operations. For now, I’m not worrying any more about it, nor do I think dropbox can be implicated in any conceivable way with how I (and others) have been using it.
