This is going to be a fairly detailed how-to guide, so if you are not using Google’s Picasa program, you’ll probably find it boring – and if you are, I strongly suggest you start at Part 1, where we define the problem (Picasa being hopelessly single-user, single-PC focused), why earlier solutions, whether sync-based or network based are far from perfect, and where you can read important disclaimers. If you’ve read Part 1, let’s move on to the solution…
Sharing Picasa Between Multiple User Accounts on the Same Computer
You may only be interested in the multi-computer setup, but please read this chapter anyway, as we will build on the logic outlined here when we expand to a network setup.
Move your photo library to a public location
By default most photos are stored at user account specific image libraries, with a default path similar to this in Windows 7 and Vista:
You could fiddle around with sharing / security properties to enable other user accounts access this image folder, but moving your photos to the public folder is a much cleaner solution. The new destination is:
Although the easiest way to move folders is from Windows, it’s always better to do it within Picasa, to allow it’s databases be updated properly. If you use nested folders, you’re in luck, you can just right click on the top-level folder, select “Move Folder”, pick the new destination, and you’re done. (If you have nested folders but don’t see them in Picasa, change from “Flat View” to “Tree View” in the main View menu.) If you have a lot of flat folders, this may be a cumbersome process, but it’s one-time only.
This was easy … now close Picasa and let’s get really started Two reminders before we start:
- you’ll need to do all this using an account with Admin privileges
- backup, backup, backup (your photos and system folders / files)
Move Picasa’s internal databases to a public folder
The internal Picasa databases are originally in two system folders in Windows 7 / Vista:
You’ll need to create a new home for these two folders, for example this:
Now move the Picasa2 and Picasa2Albums folders to the newly created PicasaLib folder, so their new locations are:
Well done. Too bad Picasa is still looking for these databases in the old place…
Trick Picasa into finding the new database location
At this point you should no longer have a Picasa2 and Picasa2Albums folder in your C:\Users\username\AppData\Local\Google\ folder – if you do, you likely copied them to the new destination instead of moving. If that’s the case, please delete them now – we can’t have real folders with those names here, since we are going to replace them with Symbolic Links that look just like the deleted folders but will actually redirect Picasa to the new location.
For the next steps even though you’re logged into a user account with Admin rights, you will need an elevated command prompt. If you’re like me and can’t remember hot-key combinations, here’s how to get it: Click the Start menu and type cmd in the run box, but do not hit enter. Instead, find cmd.exe at the top of the list, right-click on it, then left-click Run as Administrator.
Now you’re in a command box that reminds you of good old DOS. Navigate to the original Appdata folder:
- cd \Users\username\AppData\Local\Google
Now type these lines exactly as you see them (of course without the bullet point):
- mklink /d Picasa2 C:\Users\Public\PicasaLib\Picasa2
- mklink /d Picasa2Albums C:\Users\Public\PicasaLib\Picasa2Albums
You have just created two entries that look like the Picasa2 and Picasa2Albums folders but actually point to their newly created location.
Update and verify Picasa for each user
Open Picasa, go to Tools > Folder Manager and make sure only the new public destination is selected, nothing else – certainly not user specific libraries.
Repeat the above relocation steps for all other users on the same computer, and check their Folder Manager setting in Picasa.
You’re all set! All users now have shared access to all public photos, and edits, changes, thumbnails..etc are all maintained in a central database instantly available to all users.
Warning: I have not tested what happens if multiple users try to update the databases at the same time, but I assume it is not a very good idea. Best practice is probably avoid using quick User switching all, rather log out of one user before logging into another one, but at a minimum, even if you do quick switch, don’t leave Picasa open in two user accounts at the same time.
Picasa on Multiple Computers
This is what you’ve been waiting for… we’re actually very close, the logic is surprisingly simple: map the drive that has our Picasa library and databases as a network drive, say P, then apply the tricks we’ve just learned doing the multi-user setup on the same computer, but now the symbolic links will point to the public folders on the P: drive, and voila!
Well, almost…too bad there are a number of quirks that we have to deal with first. Let’s take them up one by one.
Your network layout
If you have a NAS drive, which is for passive storage only, accessed by several computers on the network, than the above solution will work, since you can map the NAS drive to the same drive letter on all computers. But if your network is like mine, i.e. there is no NAS, Picasa resides on one of the actively used computers which all others access, then you run into all sorts of trouble. Here’s why: Picasa stores the result of your “watched folders” configuration in a plain text file named watchedfolders.txt in the Picasa2Albums folder. But we’ve just moved that folder to our shiny new PicasaLib to be shared by all instances of Picasa – that means they can not have different “watched folders” set per instances.
The problem is, the “main” computer will consider Picasa storage as its C: drive, while all others have to refer to it by another drive letter, since C: is reserved for their own hard disk. If you have both P: and C: drives as “watched folders”, all hell breaks loose: Picasa will start copying the folders to the local computers, in the wrong folders, wrong labels, resulting in total chaos (I’ve been there…). So once again, we’ll cheat: find a way to refer to the central PicasaLib under the same drive letter from all computers.
Re-mapping the “server”
Not a true server, but playing that role in this case: this is the computer that has all the Picasa files and that we’ve just set up for multi-user access in the previous exercise. We want to use the P: designation, but can’t simply rename our main hard disk, nor can we map it as a network drive, so we’ll apply the symbolic link trick again: set up a link from the root folder to the public folder. Steps:
- Get an elevated cmd prompt (see details above)
- cd \ (back to root folder)
- mklink /d P C:\Users\Public\ (create the symbolic link)
You now have what the system thinks is a P folder, and can use it in the Picasa “watched folders” definition. Which means you need to start Picasa, then navigate to Tools > Folder Manager, and select \P\Pictures as the folder to watch – unselect everything else. For a few minutes you’ll see heavy activity, and for a while Picasa may show duplicate folders, double the number of pictures you really have, but will eventually sort it all out.
Setting up the “clients” or “satellite” computers
These are the computers that have no local Picasa information, we just use them to access our main libraries from the “server”. Ideally we would just map the public drive on the server as a network drive under P: but we’ll run into a syntax problem. On the main computer Picasa will overwrite our watched folder setting, changes \P\Pictures to C:\P\Pictures, which works just fine on the main computer but not on the satellite ones. Picasa’s watchedfolders.txt does not accept a \\Computername\Foldername designation, it has to look all local.
So we go back to our friend… yes, you guessed it right, symbolic links. But now even this old friend lets us down: we cannot define a symbolic link to a network folder, only a local one. Oh, well, we’ll outsmart the system again, by combining network mapping with symbolic linking: we’ll map the network drive to an interim name first, then link to this interim drive-name. Steps:
- From windows, map the \\MainComputername\Users\Public\ folder as drive O:
- Make sure there is no Picasa2 or PicasaLib folder in \Users\username\AppData\Local\Google
- Get an elevated cmd prompt
- cd \
- mklink /d P O
- cd \Users\username\AppData\Local\Google
- mklink /d Picasa2 O:\PicasaLib\Picasa2
- mklink /d Picasa2Albums O:\PicasaLib\Picasa2Albums
Repeat the last three steps for all user accounts that should access Picasa from this computer. Logically now you would have to open Picasa and changed the watched folders to P\Pictures, but there’s no need: it’s already set up on the server machine and you’ve just told Picasa to pick all parameters and data from there.
In other words, you’re all set. Needless to say, this only works as long as your “server” is turned on:-) but then all computers on your network will see the very same photos, and all editing, manipulation, face or geo-tags, albums… are immediately updated in the central database and reflected on all computers, no matter where you originate them.
We’ve just turned a hopelessly single-user, single-computer product into a networked one. Sort of. It’s obviously just a workaround, and all my disclaimers from Part 1 apply.
Now, let’s remember, Google isn’t really a PC or local network software company. They are The Web Pioneers. I think the long term solution will be much stronger integration with Picasa Web Albums. Currently you can mark your folders / albums to synchronize with the Web version, but it’s one way, from PC to Web only. That’s not what I call full synchronization. If you change anything in Web Albums, it’s not reflected back to your local Picasa library. I believe the future is full two-way – actually multi-directional – synchronization, where Web Albums become the conduit between any number of client computers that access Picasa. It’s not impossible, services like Syncplicity do similar synchronization – Google Picasa has to embed it in their Web capabilities.
(Cross-posted @ CloudAve)