LrC operates by explicit folder paths within explicit locally accessed storage. My examples will mention Windows but the principle is AFAICT the same for MacOS.
For example in "[Volume] > files > images > 2024 > 02 > 27 > imagename.jpg"
[Volume] might be a MacOS drive name, on Windows requiring a drive letter, or might be the fileshare name from a fileserver or NAS on the local network.
Sometimes this path navigates into a user specific semi-virtualised "library" resource, for example in Windows each user has a Desktop, a Pictures location, a Documents location and such available. But the actual disk locations for these generic resources are hidden from the user in normal circumstances. Those locations sometimes change behind the scenes without the user ever knowing. For example when you start backing up user files to the cloud using OneDrive, the disk locations for Desktop, Pictures etc physically move (into a OneDrive specific sub-part of the user files). And could move again in the future, depending on whatever cloud sync system is in use. But LrC deals with fixed physical locations so each such 'administrative' move will INVALIDATE its own referencing of the files and folders concerned. Those would then need to be actively reconnected (re-browsed) by the user to bring them back online within the Catalog.
Even worse: depending on disk usage, cloud syncing systems sometimes leave a file pointer in place in the local file system, delete data physically that has not been recently accessed, then on-the-fly download another local copy of it if/when the user does seek access in the future. This scheme is not a great fit IMO with the continuous storage expectations of a LrC Catalog. So would need to be switched off, for the sync client, for all of this data set.
My own position is that any OneDrive (or similar) synced location - I'll go further and say any user-login-specific location - is not the most long term stable and reliable option for files that are imported to a LrC Catalog. For example, sometimes a new computer login must be created if the previous user's profile is corrupted. If the files that LrC relies on are buried inside the older user's dedicated files area, the new user login would be blocked from accessing those and then what. Preferable in my opinion to use a vanilla, non-user-specific storage location that is not synced to cloud so far as LrC managed data. But it's a different matter for exports - I export everything into my user login's Pictures location, OneDrive syncs those, and if Pictures moves its real storage location tomorrow, or if OneDrive manages whether a local copy is present or not for each item, I will not greatly care so long as it all magically continues available to me both locally and online.
Really it is just the processed selective exports that I require general-purpose access to from outside of LrC - not the Raws etc. And cloud sync makes a good job of delivering that access.
Backing up the Raws etc themselves, and the Catalog, are a separate issue entirely, with different requirements and restrictions.
5
Replies
AdChoices