P: Allow Catalog to be stored on a networked drive.

Google symbolic links Lightroom - I know Sean McCormack wrote something on the topic.

Unfortunately that's a windows only solution. It requires the "subst" DOS command. There is no OSX / linux equivalent. I've been unsuccessful in tricking Lightroom to access a network drive using symbolic links on OSX.

Here's an article about using symbolic links in Windows to locate your catalog folder on a network drive:

http://www.davedaniel.com/index.php/2...

The principles are the same on Mac but with different details of course.

Mark, I think you've nailed it - in theory, accessing a Lightroom catalog on the network is just like accessing it on a local drive, except you have a network instead of a sata cable, and a server computer instead of a disk controller (assuming non-concurrent access).

Quoting Dan Tull of Adobe (from above):

"If I recall correctly, my experiment was a Mac file SMB share with a single Windows XP client. I pulled the cable in the middle of an import and the next time I tried to open the catalog, it was corrupted such that I was unable to fix it in the usual way (doing a SQLite .dump into a new catalog). It wasn't great for performance either, but I didn't investigate that in detail as I was primarily concerned with validating or dispelling concerns about robustness against network failure. Our use of SQLite has changed significantly since then, so it's possible the results of repeating that experiment may be a bit less dire than previously. It's also possible that the (relatively new) WAL mode might be more resilient against this condition. My experiment is more than a little dated at this point. It's probably over 4 years old now."

I suspect you'd have the same problem if your sata cable became disconnected in mid-import - dunno...

Note: (also from above) - kada jawi tried it for a while over wi-fi, but network latency degraded the performance. I don't know how performance is over a wired network, or if that would be an option for you.

Summary:
-------------
Most people don't access catalog from network as a long-term solution, due to performance hit, and potentially reduced reliability, but its doable...

I've been trying to figure out how to do this with symbolic links.
Can you provide any more detail on how to set that up.
I'm assuming this solution is for a Mac as Windows doesn't have symbolic links.
(which is perfect for me)

I don't see how the database could become corrupted unless the network drive becomes disconnected while the database is being accessed.

Our whole workflow runs across a network without a hitch. I can't see how this could be an issue for a single user database.

FYI I have a computer engineering degree and have quite a bit of experience with databases and network applications.

Going through the SQlite readme & FAQs seems to indicate that the locking problems all relate to multiple processes (concurrently) accessing the database. This shouldn't be an issue if a lock file is used as a gate to prevent another process from gaining access to the database until the lock is deleted. I'll admit that I haven't read everything written but this is what I have found so far.

The issues of the OS not flushing buffers to disk or disks reporting that the data has been written when it actually hasn't are common to a local disk as well as on the server. Of course there could be corruption if a network goes down, the server crashes, etc just as the database is being written. That problem exists with any application

A lock file wouldn't address the underlying issue of feared database corruption that might result when accessing a SQLite database from a network drive. See the discussion earlier in this thread for details -- there's a reasonable belief, not backed up by recent testing, that networked LR SQLite databases can get corrupted with at least some combinations of clients and servers.

If you want to live dangerously, you can trick LR into thinking a networked catalog is on a direct-attached disk by using symbolic links.

The one machine restriction is ridiculous. Just drop a lock file into the folder so that only 1 instance of lightroom can access the catalog and you're done. Don't need multi user I just want my catalog on the network so it's backed up and accessible from anywhere.

Sounds easy, but the beauty of software that's user friendly is usually very difficult to implement, so I guess LR will just remain a one machine software.........

I see three scenarios:
1. Catalog Sync: for single-user/multi-computer use. A automatized sync of a catalog between lets say a laptop and a studio computer. That would satisfy a lot of users
2. Networked Catalog: I'm not sure if this is doable (avoiding db corruption) but I would imagine that the performance of such a catalog would be 'less then desirable' even over Gb-network
3. Lightroom Server: a real client/server application for larger working environments. But this would then require a dedicated SQL server AND file-server (to store the RAW images and previews) and a new client application. But I would expect a hefty price tag on such a version

I'm sure there are people at Adobe that have already looked into this - but I'm also sure it is not easy to come up with a real good solution, especially because the possible scenarios are going in very different directions.

I see where this will probably boil down to a 'multi-user' vs. 'Multi-machine' issue. Not being a programmer, this sounds difficult to easily satisfy all users. Large/small portrait studios would most likely only be working on one client's folder of images at a time. e.g. downloading and first edits. I doubt 2 or three employees would be doing the same job to the same client at a time.

From a business standpoint, most 'studios/photographers' work by themselves or with staff of three or smaller. Most of us smaller operators would be thrilled to be able to leave our catalog and images on a 'server' and then access from our laptops and maybe one or two desktops in our work area.

Having the mega stock photo business with large databases and then everyone else would seem that having two different versions of LR would be your answer.

Is this unreasonable? I don't know.