Moving photos from HDD to SSD

This may have been answered before, but I could not find it so I ask…

I have just installed a new 2TB SSD on my PC. As I write this my PC is busy copying all the photos and the sidecar files from the HDD to the new SSD. It may take a while, it’s a close to a terrabyte of files… some 160 000 photos.
But I have to “inform” the PL database that the location from now on is on the SSD. What is the best way to do that?

If that SSD drive is your new drive that contains the images, then I would delete the database and start from scratch. If you use PL also as a DAM then you’ve to index the files. Can take a while.
You don’t have to inform PL. When you open a directory it builds/updates its database
That are my thoughts. Don’t rely on it.

George

What bone? Windows or Mac?
On Windows, if you keep the same disk letter and the arboresence of the files doesn’t change, that will not have an impact.
The deleting of the database leads to the loss of certain data such as the project and the color tag and perhaps even something else …

I will still have my old HDD installed. The SSD gets another drive letter. Since both directories are identical after the copy, I would prefer to change drive letter in the DB without index it all again…

May be it will also be necessary to modify the ID number of the disk

@TorsteinH, do you feel comfortable with editing database entries?

I probably could edit database entries, but I have gone the slow way. Now PL is indexing the new catalogue on the SSD…

Okay, my Macs index about 1’000 images per minute.

Other than that, is there no “find folder” context menu item in DPL for Windows?

@TorsteinH Pity you didn’t find this PL7.1.0 (Win) Issues when changing a drive.

The heading was “PL7.1.0 (Win) Issues when changing a drive” perhaps I should have made it " PL7.1.0 (Win) Issues when changing a drive/Moving photos from one drive to another".

Sorry you didn’t find it!

@Franky sorry if I have read your posts correctly what you have written is incorrect, the drive letter is immaterial for conventional drives what matters is the drive id, serial number …whatever you want to call it.

This is the controlling identifier in the DxPL database and needs to be “hacked” I am afraid!?

Arguably the same for NAS/network drives but I believe it is possible to swap them if you map the new drive in place of the old or, if both drives are staying then map the old drive to e.g. “OLD-Y” and the new drive to “Y” where Y was the original id…

and currently hacking the database is the only way of achieving this “swap”/replacement/move/ …

So what about just deleting the db. If the drive id can’t be replaced by another, the old db is useless. Maintaining it only results in a containing for 50% rubbish.
Just take care if you’ve keywords that they are written in either dop or xmp.

George

@George But that isn’t the scenario being discussed here!

If you have no use for a database because the changes to the directories etc, have changed beyond all recognition then the database is useless and way to hard to fix!

But if the directories are intact and are an exact copy of the original, as mine are on my USB3 backup drives, then I could “schuck” the drive from its case and fit it in the PC or run with it as a USB3 drive but I could retain the database if it contains something useful, e.g. ‘Projects’ or don’t want to face face hours off (re-)indexing rebuilding a database when I have a perfectly formed database already except the drive ids don’t match!

It is possible to change the id of the disk itself but the OS will object to having two drives with the same id. (as will the DxPL database).

So the safer way is

  1. Take a number of backups of the database (to provide multiple opportunities to get the hack right)
  2. Hack the database as appropriate changing essentially one field, or two if both drives are still attached (using a dummy number to avoid the database rule that there can only be one entry with a given id. in the ‘Folders’ Table at any point in time). The details are in the topic I wrote on the subject.

I believe that there is another way to accomplish the same thing but haven’t checked all scenarios and it still requires a database hack!

It amounts to changing the ‘Id’ field so a new drive effectively “inherits” the database entries of an old drive! It should work to transfer from a NAS to a fixed drive or vice versa (but only if it works, which I believe it did in testing for a specific scenario).

In addition where indexing was not a disruptive process on PL6 on DxPL(Win), it is as of PL7, once started DxPL is out of action until indexing is finished or cancelled.