Lightroom: batch renaming bug when virtual copies present in folder

So, should renames ignore virtual copies?

What's happening is that the first copy is renamed as 3, then the second copy is renamed 4. But they're actually the same file, so that second rename is overwriting the first.

But what if you're renaming just a single copy? Should it be skipped? What is the behavior you'd actually want here?

Hi Sean,

I have entered this bug in our database. Until such time as it is fixed, however, you can work around it like this:

1. Go to Edit>Select None.
2. Go to Photo>Stacking>Collapse All Stacks

Then select the range of photos that you wish to rename, and go to Library>Rename Photos. In this way, the virtual copies will not be selected when the rename is executed, and the bug will not occur.

I should add that this only works if you've left the virtual copies stacked with the originals, which is what happens by default. If you haven't, however, you can omit the virtual copies from the selection via other means, for example by using the Library filters to hide all virtual copies.

-Ben

Ben (and Sean), I can see why you call this a bug. But I can't come up with better behavior... What do you think is the proper behavior?

The least bad thing I can think of is only rename any file once (in a given rename action) -- if this file has already been renamed, skip it. But that's still imperfect and confusing for the user in the case where, say, your new filename includes metadata which is different for each version.

It seems the only clear solution is to throw up a modal dialog box explaining to the user that there are multiple versions of the file that would get different names, if only they were different files, and allow the user to select which name the file should get.

Alternately, only rename masters (not VCs), and throw up a dialog box if someone tries to rename a VC. This results in the unfortunate mismatch if a filename was renamed with metadata as above, then a different VC was made the master. It's the user's fault in this case that they confused themselves, but it's still inelegant.

It's worth considering the case where a user is renaming a single file that happens to be a master or VC. Should they be warned that other copies will inherit the new filename?

Every approach I can think of is at least a little ugly. I'm not convinced that any of these are much better than the current behavior.

Hi Mark,

"Rename Photos" is perhaps something of a misnomer as a menu item. What you're really doing is renaming the files on disk. The virtual copies do not exist as files on disk, so where a virtual copy is concerned, there's nothing to rename. The name of virtual copies, as displayed within the UI in Lightroom, should always be the same as their "master photo," which does have a file on disk.

You certainly can create custom naming schemes which reference metadata which could be different between a master and a virtual copy, but again, the virtual copies do not exist as files, so when renaming the actual file on disc, the metadata from the master photo should be used.

Of course we could conceivably rename the virtual copies as well, solely in terms of the name that's displayed within the Lightroom UI, but then the "file name" of the virtual copies would not actually be the name of the file that they're referencing, which doesn't seem ideal.

It is also true, as you point out, that you could rename a photo using metadata, then subsequently promote a virtual copy (with different metadata) to "master" status, thus causing some level of confusion, but that's getting pretty deep. I think it's reasonable to think that the user expectation (certainly Sean's expectation!) is that virtual copies are ignored during renaming, and inherit the new name of the master (and file on disk). In the case where you have only virtual copies selected, then the "Rename Photos" option would be grayed out.

-Ben

Ben, that makes sense, thanks for the detail.

In the case where a user tries to rename a selection which includes a VC, perhaps using a sequence number... Will LR put up a dialog box explaining that what happens isn't what they expect to happen?

(Clarification: This is the same scenario that frustrated the OP. The new behavior is different, but would still probably feel like a bug to him.)

Hi guys,
You have been busy while I've been sleeping!

As Sean pointed out my main issue is the fact the renaming skips a number. It's just messy and the client thinks something has been deleted or omitted.
Having 2 files with a similar name I.e 3-1, 3-2 especially if they are obviously the same image processed differently is easier to explain then a missing number!

The only work arounds I have found for this so far are:
1. Don't use any VC's
2. Rename at the start of the workflow before VC's may be created - only problem here is I regularly cull images as I work through the folder, so would still end ip with non-contiguous naming
3. Export all the final images with the original names, and the rename the jpg's - however then my final images names differ from those in my LR library, making it harder to find them later if they need additional work.

Hi,

I've got the same problem. Currently my workaround is that before renaming my images I set the filter to see master photos and videos only.

My desired behavior would be like Sean says so that there are no gaps in the numbering. From my point of view this should work even if no filter is set as virtual copies by definition ("Virtual") do not have their own filename. They always relate to exactly one master photo. So why not just renaming master photos?
The problem with different filename due to inclusion of metadata in filenames should only occur on export, but not on virtual copies.
Or am I missing something?

The solution of skipping VCs when renaming works great if you have both the master and one or more associated VCs in your set. But:

• 
  
• What if you have only the VCs?
• 
  
• You still need to explain to the user that yes, there were 234 photos in the set, yet the last one gets #233. It's still confusing unless you understand what's happening.

I think maybe I misunderstood your first question, Sven. A selection could have a VC but not have its master, and the proposed solution would mean that the VC wouldn't get renamed -- that could be a problem if you're renaming with a sequence number ahead of delivery to a client.

You are right about what happens with filenames when renaming only one VC today. In the proposed solution, if you select only a VC, rename would be grayed out in the menu (and, I presume, would fail in some way if you press the F2 key).

I proposed an idea which I believe would solve the challenges associated with this common use case.

All we need is a check box in the rename dialog that, when checked, will force to rename the stacked images with the same name as the image on top + a sequence number (the same way LR behaves when you Edit In...)