Add ability to map DB and Photos to subst or mapped drive like RunPicasa

[GoogleCodeExporter]

When PS and photos are on NAS or portable drive, the drive letter assigned to 
the drive may not be constant.
We could add the functionality to map the photos and database to the correct 
drive letter using the subst command or eq or the Net Map command before 
starting Picasa if the drive letter is open.

If the drive already exists, can we use something like symlink to just map the 
2 folders to the correct location?

I realize the trick to this will be making it user friendly or maybe even user 
possible!

Original issue reported on code.google.com by earlb...@gmail.com on 3 Nov 2011 at 9:27

[GoogleCodeExporter]

There are questions about how or if this should be done.
- The Pictures are all that really needs to be mapped, the database might be 
able to stay in source location. (But need to think about Collages and movies 
put there)
- Could PS just stay at its started location? (might even be local drive using 
shared settings).
What other features of RunPicasa should we add?

Original comment by earlb...@gmail.com on 5 Nov 2011 at 10:36

[GoogleCodeExporter]

I don't know what RunPicasa does now. Is it best to just mimic the drive letter 
assignments as it is done now in the .bat or not?

Original comment by pieter.r...@gmail.com on 8 Nov 2011 at 10:33

[GoogleCodeExporter]

What RunPicasa does now is map the directory or drive that contains the 
pictures directory to the drive letter those pictures were referenced to in the 
index.
By convention (or consensus) that folder also contained the database for those 
pictures, so:
root dir\
  \Pictures
  \PicasaStarter
  \Database base folder 
         (Bryan used PicasaStarter\ as the database base folder)

When these were set up they were set up for a drive (like P:\) as the root dir, 
and then they were copied to a network or shared folder.  RunPicasa maps this 
network or shared folder back to P: so the pictures will be in the correct 
place for the database.

When you think about it tho, the only thing that really needs to be mapped to 
the drive is the pictures folder because Picasastarter can create the symlink 
for the database no matter where it is (subject to the limitations of symlinks 
and the XP work-around.)

I think, in order for PS to do this mapping it is going to need to know where 
the Picture directory is now and where it needs to be mapped to.  RunPicasa had 
it easy because we specified that it had to be in the root dir as shown above, 
so it knew where the folder was coming from and we only had to tell it the 
destination.

For PS we are probably going to have to either specify all these directories or 
do it by convention.  PS is not necessarily going to be in the 
root\PicasaStarter directory, It's settings xml file is not necessarily going 
to be there either, although maybe this could be a convention (But a settings 
file could have entries for several databases)
(to be continued, I was called to dinner! ;-)

Original comment by earlb...@gmail.com on 9 Nov 2011 at 1:31

[GoogleCodeExporter]

This stuff is making me dizzy, there are too many options! 
Is it reasonable to require that any set of pictures/db that are going to be 
mapped to a different drive letter be in the format shown above? (that is a 
"root" folder with a subdirectory for pictures, one for PicasaStarter, and the 
database folder somewhere in that root path.
This way, at least the PicasaStarter settings xml file would be in the 
PicasaStarter folder and PS would therefore know the "From" root folder, Then 
we would only have to tell it the "To" drive (might even be able to get that 
from the txt file in the DB).  

This would be a LOT simpler.
Maybe all we would need is a "Remap if necessary" Button.

Original comment by earlb...@gmail.com on 9 Nov 2011 at 2:54

[GoogleCodeExporter]

Yep, indeed loads of options...

Just to add some more:
1) We could save the name or the serial number of the external disk and search 
for it, and remap it when starting PicasaStarter?
2) We could show a popup when starting PicasaStarter or pushing runPicasa if 
the drive letter is not available asking which drive corresponds to the one 
needed...

For what cases did you make RunPicasa.bat?

Original comment by pieter.r...@gmail.com on 9 Nov 2011 at 7:09

[GoogleCodeExporter]

It is a good idea to think about why it is needed. Here is my take on it.
- A Picasa Picture and DB set must be set up to run from a particular drive and 
directory.
- When you plug in a USB or network drive the drive gets mapped to the next 
available drive letter by default, and this drive may not be the one the 
Pictures were set up to be on.
-Run Picasa's #1 job was to Map or Subst the network or USB drive\directory to 
the correct drive letter it was set up for.
- A secondary purpose was to allow the user to have several Picture/DB sets all 
designed to run on the same drive (Like P:) and automatically map the one we 
want to use now to that drive. This allows you to have a number of different 
picture sets.

Original comment by earlb...@gmail.com on 9 Nov 2011 at 7:57

[GoogleCodeExporter]

One more possible thing for this drive mapping is, right now we tell the user 
to put a physical drive on the drive letter he wants to use for the pictures, 
and then use Picasa to move all his pictures to the new drive. PicasaStarter 
could map a folder to that drive letter, and the user could move the pictures 
to that subst drive rather than have to have a partition put on that drive 
letter.

Original comment by earlb...@gmail.com on 9 Nov 2011 at 8:14

[GoogleCodeExporter]

I wonder...
What would happen with Picasa if it moved a folder to another drive, and then 
found out it couldn't complete the move because it couldn't erase the source 
folder??
If this happened in a copy of the database for that folder, would the copy have 
it's database updated to the new folder location?  If so, the copy would be on 
the new drive, and if you went back to the original database it would still be 
pointing back at the original folder with the pictures still there.
This might be useful for duplication a set without having to restore the 
original.

Original comment by earlb...@gmail.com on 9 Nov 2011 at 8:24

[GoogleCodeExporter]

My Comment 7 doesn't work, because when you try to run PS for the first time on 
a subst drive, when PS asks for elevated priveleges to initialize the Symlink, 
it fails with "Admin priveleges not allowed by operator".

I think I remember something about the subst drive only being for the current 
user, not admin.

This could be a real problem, that there must be a real drive there for the 
first time??

Original comment by earlb...@gmail.com on 9 Nov 2011 at 10:01

[GoogleCodeExporter]

It works fine though with a network dir mapped to a drive letter.
Then after that is used once creating the Symlink the subst drive works just 
fine, it just won't create the link from the subst drive

Original comment by earlb...@gmail.com on 9 Nov 2011 at 10:20

[GoogleCodeExporter]

One more observation on the Symlink / subst thing (Comments 7 & 9)
If I subst a folder on D: to make it the N: drive, then try to run PS on that 
drive, it fails with the error in 9 above.  BUT if I go to an elevated command 
prompt (Run CMD as admin) and do the same subst, then PS creates the symlink 
ok. It sounds like we will need to do the subst thing in admin and in user the 
first time s the drive will be found when the link is to be created.

Well, that was fun!....Yeah, riiight...I think I'll do something else for a 
while..

Original comment by earlb...@gmail.com on 10 Nov 2011 at 12:00

[GoogleCodeExporter]

Nice catch!

Original comment by pieter.r...@gmail.com on 10 Nov 2011 at 8:49

[GoogleCodeExporter]

Pieter:
I was trying to play with the code a little, but can't so far get it right.  
When PS calls itself to do the symlink thing with elevated privs, before 
checking for /createsymboliclink, PS loads all the settings etc and does the 
checks for the settings file.  None of this stuff is needed for creating the 
symlink, and it really gets in the way if the target drive is a subst drive, 
because the drive is no longer there when elevated to admin. So anyway I am 
trying to move the create symlink stuff to the beginning, but haven't gotten 
there yet.

Original comment by earlb...@gmail.com on 10 Nov 2011 at 9:23

[GoogleCodeExporter]

Yep, code refactoring is sometimes needed, but isn't always easy...

Original comment by pieter.r...@gmail.com on 10 Nov 2011 at 9:42

[GoogleCodeExporter]

I think basic functionality would be that if the picture drive didn't exist, 
you would map the root of the settings directory to the picture drive root ( P: 
for instance).

Root of the settings would be X:\Pics if the settings was in 
X:\Pics\PicasaStarter, or X: if the settings were in X:\picasastarter)

This does require that the pictures and PicasaStarter have the same root folder.

We have 3 cases to worry about, settings dir is on local drive, mapped network 
drive, or UNC path.

Original comment by earlb...@gmail.com on 11 Nov 2011 at 5:02

[GoogleCodeExporter]

Added the basics for this feature, and calling it Virtual Drive feature instead 
of RunPicasa features.  The user sets the virtual drive to be mapped in the 
database configuration window and checks a check box that allows remapping of 
drive if necessary.  When the database is selected, PS checks to see if the 
drive exists, and if not, it maps the directory the PicasaStarter folder is in 
to the virtual drive letter.
This assumes that the directory below the PicasaStarter directory contains the 
picture directories, and it will usually contain the database "base" directory:
Containing folder\ <-- The folder to be mapped to the Virtual drive.
  \PicasaStarter   <-- Contains the PicasaStarter settings file & PicasaStarter.exe.
  \Pictures\       <-- Contains all Picture folders & pictures.
  \Database        <-- Contains the Database for the Pictures (on Virtual drive).

Original comment by earlb...@gmail.com on 2 Dec 2011 at 3:29

• Changed state: Implemented
• Added labels: Milestone-Release2.0.0