How to Edit Final Cut Project on Two Macs using Dropbox

"Simply use FCPXML to move from one Mac to the other. AirDrop works great for this."

Thanks for the tip. But doing a full XML export/import/AirDrop every time I want to move from the dining room to the family room or a coffee shop would be a royal chore. Much simpler to make sure I quit FCP on one Mac (and let the sync finish; usually very fast with Dropbox) before starting on the other.

"Dropbox, as stated, causes issues with FCPX and can corrupt Libraries and Projects."

I'm not sure that's clear at all. To answer @terryb's question: yes, for any given file on Dropbox, you don't want to modify the same file in two places at once. This is not a reality unique to FCP; it applies to any file. I also don't think it's unique to Dropbox, but rather applies to any cloud-storage provider. Copying files atomically doesn't help maintain integrity when a "library" is composed of hundreds or thousands of separate databases and config files and data files that function as a unit. If half of those files are synced and the other half have not, then any other user accessing "the library" now has an inconsistent view of the data. And since I think most cloud-storage providers do copy individual files and don't have a concept of a "bundle" of files treated in an "all or nothing" fashion.

So the correct practice would ALWAYS be to 1) close the library on one machine and 2) let it sync to the other before opening it on the other. This is a given.

The precise question here is really:

IF you ACCIDENTALLY open a project in Dropbox on two Macs at once, what will happen? @terryb said it should alert the second "user" that the library is already open elsewhere. I still have to try that to see if it's true. And if it IS true, then I don't see how Dropbox would corrupt the library, since it won't allow it to be open at two places at once in the first place. The type of issues like "data write ordering", as @joema raised, should only be an issue if you need data consistency while both users DO have the same file open at the same time, which ostensibly FCP won't permit.

What I'm hearing here are two conflicting answers that people are trying to allow to co-exist: that 1) FCP protects you from an attempt at opening a library in two places, but 2) that doing so still risks corrupting your file. And again, I'm not talking about the case of opening a library that is either still open elsewhere, or which is partially-synced: those are definitely problematic (for any file, and for any cloud storage provider).

If I were to go back to my OP and try to answer my own question about apparent data loss based on this discussion, I would speculate that the following happened:

1) FCP Library opened on Mac #1 and changes made

2) Dropbox was not running properly on Mac #1, and so didn't upload the changes <<< I have seen this happen only on my MacBook; some type of odd issue where sometimes the service silently stops

3) FCP Library opened on Mac #2; FCP didn't complain about the opening of the library on Mac #1 since that didn't sync to Mac #2 yet; also I didn't notice the previous edits from Mac #1 were missing, and new changes were made

4) Dropbox on Mac #2 uploaded the new changes to cloud

5) At this point, one of several things could have happened:

a) If the Dropbox service on Mac #1 was still down, then opening it again on Mac #1 would not show the changes from Mac #2. Then, if new changes are made and Dropbox service is restored, the changes from Mac #2 would be overwritten by these newer ones from Mac #1.

b) if Dropbox service on Mac #1 was restored after (3), then now the cloud was presented with two conflicting sets of FCP changes. Whichever one Dropbox picks as "truth", the other Mac's changes will be lost.

So here's my current takeaway for best practices for using an FCP library on Dropbox or other cloud storage:

1) Configure all those storage location settings such that all dependencies on media and backups also be synced to the cloud

2) AFTER making changes on a given Mac, close the FCP Library and make sure the sync up to the cloud completes.

3) BEFORE making changes on a given Mac, make sure Dropbox syncs fully before opening the FCP Library.

If you think I'm missing anything, please let me know and I'll update! And I will try that test tonight....

"You can mount a shared volume from another mac in the same network"

Okay, I tried this and it works. I used the copy of the library that isn't in Dropbox, though I'm not sure that would matter. I opened it on the serving Mac, and then got this message when I tried to open it on the remote Mac:

If I had to guess, this is working based on filesystem-level file locking features. I haven't tried NAS yet, but if it works there, that's probably also using filesystem-based feature to control concurrency. Cloud storage providers would never use something like that because cloud syncing is done asynchronously. This APPEARS to be why FCP has an application-layer solution with the .lock-info file, but it's not working. So either that's a bug, or those lock files are designed for something completely unrelated, and we just have to Quit+Sync between sessions to prevent collisions. I may report this as a bug and see what Apple says.

"You can set the backups location In Storage Locations."

Oh wow, thanks. Maybe I should have Googled better, but now I see where it's covered in the Manual. I have now used it to move all my "motion" / cache / etc into the Library, too.

"What version FCP and MacOS are you using? "

Should be latest of both:

• macOS Sonomo 14.4.1
• FCP 10.7.1

"FCP wants assets to be local."

What exactly does "local" mean? Dropbox can be configured to sync cloud files locally, at which point I think it should be undetectable to FCP that the source of truth is the Dropbox cloud.

But really, this isn't even a cloud-storage question. What about an NFS share on my LAN that both Macs share? What happens when two Macs open the same FCP library at the same time and make changes?

"If the library is open on one Mac, you should get a error dialog on the other one if you attempt to open the same library."

Thanks again for this tip. Finally got to experiment with this tonight. I tried about 8 rounds of tests and cannot reproduce this error dialog. Typical test pattern:

1) Open FCP on Mac 1

2) Let Dropbox sync to the cloud any lock file that may exist

3) Let Dropbox sync to Mac 2

4) Open FCP on Mac 2

>>> No error message raised.

I have since done some more research. Every time FCP is opened (or per Library?), the following 3 "files" get updated in the root level of the library's "package":

Daves-Mac-mini:DaveLibrary.fcpbundle dkitabji$ ls -latr
-rw-r--r--@  1 dkitabji  staff     368 Apr 10 19:14 .lock-info
drwxr-xr-x@  2 dkitabji  staff      64 Apr 10 19:14 .lock-dir
-rw-r--r--@  1 dkitabji  staff       0 Apr 10 19:18 __Sync__

__Sync__: This empty file shows up after quitting FCP and then is auto-deleted. Most likely, it's a semaphore to track when sync is complete. This may be FCP's application-layer solution to ensuring data integrity across cloud-storage providers (this could prevent corruption, but not conflicts).

.lock-dir: This hidden directory's time stamp gets updated when opening a library, but I have not yet found anything in it.

.lock-info: This hidden file also is updated when a library is open, and has the info you would expect in XML format:

Daves-Mac-mini:DaveLibrary.fcpbundle dkitabji$ cat .lock-info
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>FFFileLockIdentifier</key>
	<data>
	4c6dw1cd4pJs4tfbXQRz/A==
	</data>
	<key>hostname</key>
	<string>daves-mac-mini.local</string>
	<key>user</key>
	<string>dkitabji</string>
</dict>
</plist>

Specifically, the User and Host that has the library open are updated.

In my tests, inspecting the contents of this file in Terminal, every time one Mac opens the FCP library fresh, the hostname gets immediately updated in this file on the local Mac and almost immediately on the other Mac via Dropbox sync. And yet, even though FCP on the other Mac clearly knows the library is open on a remote Mac, it still doesn't complain or raise the error message you mention.

Do you have any more documentation about this error message that should pop, preventing the second user from opening the library?

"Yes, the NAS error when the library is open can be easily reproduced. You don't need a NAS, just two Macs or a desktop and laptop are sufficient."

Curious, how are you opening the FCP library at the same time on the two Macs without using a NAS or some cloud storage like Dropbox?

"In one Dropbox sync test, I saw that an FCP library synced using the old version of Dropbox can apparently be opened even if the "lock" files and contents of those files are present."

Right, that's exactly what I said, and I showed the actual output in a previous post :-)

"If so, that is even worse than I thought. That implies there is no protection from corruption if a Dropbox sync updates an open library..."

Yes, now you're following my point :-) But to be clear, Dropbox in my test synced the lock file just fine, and very fast (and before I tried to open on the other Mac), and the lock file shows that the library is open on the other Mac. So in this case, Dropbox has done its job, and it's a mystery to my why FCP has apparently ignored this information and allowed me to open the second instance anyway. This appears to be FCP failing to respect its own application-layer locking mechanism.

Thanks for your detailed reply.

"Unlike the NAS case where there is a single server-located library, with Dropbox there are two local copies of the library which is synced by Dropbox."

Yes, this is fair, and good point. But since the locking mechanism is at the application layer, not the file system layer, I'm not convinced it makes a difference. Support for cloud storage may, in fact, be why they implemented an application-layer solution rather than trusting the underlying file system from protecting the data.

"FCP has no idea the library is part of a Dropbox sync operation. If FCP machine #1 opened the library, the lock files would be created and after some unknown delay they in theory would be synced to FCP machine #2. In theory if you waited long enough for the lock files to sync, then FCP machine #2 might see those and it might raise the error trying to open its copy of the library."

Yes, I thought about that, which I why I ran the tests I posted in detail last night. Not sure if you read that post? I proved that the other Mac had the synced locked file showing that the library was open on the first Mac, and yet it still opened the library without complaint. So, are you able to produce the error message about the library being open on a NAS? I don't have a share handy to try it on, but I'm tempted to set one up to see if that behaves any differently than Dropbox regarding library locking...

"The current version of Dropbox uses Apple's "File Provider" API."

Thanks. Yes, I've been tracking this in painful detail, and you can read more about that here:

https://talk.tidbits.com/t/dropbox-is-moving-their-folder-and-you-cant-change-it/21521/50

In short, Dropbox has, for some reason, chosen not to roll it out to everyone yet, even with updated Dropbox installations and the newer OS. But it could be because there is a lot of push-back about File Provider API, not the least of which being that it appears to eliminate the possibility of storing a cloud-synced files on external drives (and Apple charges a premium for internal storage). And I have personal history that shows that iCloud Drive behaved very badly when syncing large volumes of data, which is why I use Dropbox. So you can understand my concern about now having Dropbox forced to use Apple's APIs. One upside, however, is that (quite ironically), iCloud Drive does not use File Provider (last I checked). So if we're lucky that FP is less buggy than whatever iCloud Drive is using, then maybe it won't be so bad when Dropbox jumps ship and starts using it :-)

"The FCP library locking system is a private scheme known only to FCP. Part of that is creating hidden files in the library, such as ".lock-info", etc. This only works if the library on shared storage such as a NAS. It has no effect on any other app such as Dropbox sync, Finder file copy, etc. "

Going back to this. I wanted to prove my theory (and apparently yours) that .lock-info was indeed managed by FCP as an application layer mechanism and was not create by Dropbox. So I just copied my FCP library to a folder outside Dropbox, removed the lock file, and opened the new copy of the library. As expected, a new .lock-info file was created. This confirms that file has nothing to do with Dropbox.

That's why I don't see how your comment "This only works if the library on shared storage such as a NAS. It has no effect on any other app such as Dropbox sync" can be valid. FCP is the one that creates .lock-info. And as long as the underlying storage layer (NAS, "old Dropbox", "new Dropbox", whatever) syncs or commits the file BEFORE you try to open it on the other Mac, that storage layer has done its job, and there is no excuse for FCP to have ignored the data in that .lock-info file and allowed the library to be opened without warning.

Does this make sense to you?