We have a brand new look! Take a tour with us and explore the latest updates on Adobe Support Community.
I am seeing a regression with import. I have my import set to rename files as it moves them to subdirectories.
I import images from D:\Documents\Amazon Drive\Pictures\SM-N986U\Camera .
I import them to D:\Documents\Amazon Drive\Pictures
I have LRCC set to organize "by date"
"date format" is 2011/11 .
I have set the following rename settings :
The import operation succeeds, and moves the files from the source to the destination directory as expected.
However, the rename fails. Files get moved with their original names. They do not get renamed.
When I click on an image the destination folder in my Lightroom catalog, and right-click "Show in explorer", I get an error that the file is missing.
The issue is that the catalog contains entries to the renamed files, but the files on disk haven't been renamed.
This didn't use to be a problem. It is happening systematically. I can't say exactly when it started happening. Lightroom has been updated multiple times in the last month, including to the current 11.0 version.
The only other thing I have changed on my system is that the 😧 drive used to be a Windows 10 striped volume made of 8x1TB SSDs. I backed it up, and created a new Storage Spaces volume, which has the advantage of supporting TRIM on each SSD. I then restored the data. I have no idea if this is related to the problem or not. It should have been completely transparent to Lightroom, as the file system structure hasn't changed at all.
In any casse, I need the rename function to work. Can anyone from Adobe please look at this ?
Opps, I created a copy of your rename syntax, thought it failed, went back to prep a screenshot of the failure, and heck it worked (just different from what I am use to). My source files had name syntax of img_nnn, result of import has suntax of YYYMMDD_n
So it works on my WIN 10 LrC 11 rig
I just made a video capture where I recorded the problem being reproduced live.
Note that the screen was running at 4K resolution, and the screen capture software only captures 1080p, so not everything is perfectly legible.
Here is the full video :
1) At around 0:49 in the video, I click import.
It moves the file from the source folder (window in the bottom right) to the destination folder (window in the middle right). The file is correctly renamed. So far, so good.
2) After that, I add another file to the source folder.
At 1:30 in the video video, I import that image.
Again, it gets moved and renamed correctly. So far, so good.
3) After that, I add a number of files to the source folder, about a dozen.
a) At 2:10 in the video, I import all those images.
You can see them disappear from the window on the bottom right (source) and appear in the window at the middle right at 2:19 .
They all appear to have been renamed correctly, as far as Windows explorer shows. You can see all the filenames follow the pattern.
so far, so good.
b) At 2:25 in the video, without me taking any further action, other than moving the mouse, something changes. One image file, 2021-11-02_10, gets renamed to 20211102_153405 . It is a picture of my hand, holding a red laser infrared thermometer. The image also switches places to the last image slot in the middle right window. I have files sorted by name, which explains why it's in last position (no separating "-" in the date).
This is bug #1 . Here is a link that starts just 5 seconds before the file renames back :
c) I then click the 2021/11 folder in my Lightroom catalog, and look for that same image. I find it at 2:49.
You can see that the name of the file in the top right corner is listed as 2021-11-02_10.JPG .
At 3:07, I right click on the image and select "Show in explorer".
At that point, I get the pop-up dialog from Lightroom stating that the original file could not be found, and LR is offering me to locate it. The location is D:\Documents\Amazon Drive\Pictures\2021\11 . This is the correct import location. But the file is back its original camera filename, due to bug #1.
This may be considered bug #2 - the Lightroom catalog is not in sync with the file system after the import. It is probably related to bug #1, so you may consider them one and the same.
d) Afterwards, and without me taking any further action, other than moving the mouse, you can see the bottom-right explorer window, which was the source directory for the import, start to fill up again all on its own ! All the images that were previously imported while taking this video reappear, even though they were previously removed. This includes the images that were imported individually in steps 1 & 2 without problem, and also all the files imported as once in step 3. All the images reappear in the source folder with their original camera filename.
That's bug #3. It's one I actually had not noticed before. I only noticed it while making this video to try to reproduce the issue.
It certainly is an odd one !
As a software engineer, I think there is likely a race condition at play here, but probably more than just that.
Needless to say, the import in LR Classic 11.0 is completely broken for me as it is on my system.
A renaming token "Sequence # (1)" only permits LrC one decimal place to work with - from 1 to 9.
Beyond that - whenever there are more than nine images in question, all sharing the same year, month and day - LrC has been left with no possible way to differentiate these files within this particular renaming system. So it has to fall back on some other way to do so.
Other versions of the Sequence renaming token are available, taking up more decimal places but correspondingly less restricted. For example, "Sequence # (001)" makes lots of numbers available: from 001 right up to 999.
Thanks for following up. FYI, I haven't changed my renaming template since I first started using Lightroom Classic at least 3 years ago. I don't recall ever selecting a fixed number of digits for the sequence number. Here is what my June folder looks like for my most recent trip to Paris, for example. I imported them onto my desktop from my SD card upon my return to California. The files were imported prior to the LR 11.0 date, with whatever version would have been current at the time of the import, which was July 6, according to the Date creeted value (I hid that column in Explorer screenshot below).
As you can see, the sequence number for that June folder did not reset for a each day. It was for the overall import operation of the entire SD card. For example, you have 2021-06-18_948.DNG . Then, the next file is 2021-06-19-949.DNG . Later on, you see the sequence increasing to 4 digits, to 2021-06-19_1000.DNG .
Note how the sequence number in that folder also had a variable number of digits, and was not padded with 0s on the left. When it ran over 3 digits, the number of digits in the sequence number increased to 4 .
What I suspect happened here is that there was an issue with migration of my rename preset when LR 11.0 was installed. The rename syntax somehow defaulted everything down to 1 digit. Or perhaps, the issue is that the OS was reinstalled in August, and the import rename preset is saved in the registry, rather than the catalog, and I made a mistake recreating my rename preset manually.
In any case, is a 5 digit limit sequence number OK ? For a single day, I'm sure I'll never run into it. For an entire import ? I might.
My entire catalog is about 50k images at this time, so I'm not likely to run into this. I suspect, however, that it will eventually grow beyond 100k. And if my Lightroom catalog ever gets corrupt beyond repair, and I want to recreate the catalog from scratch, I would create a new one and import/rename all the JPG/DNG/XMP files in a single import step. And then, the sequence counter might overflow the 5 digits. It's not clear if the sequence number has changed to reset daily, or is still a sequence number per import operation, since my test case images for the video were all shot on the same day.
Even if I willfully selected just 1 digit for the sequence number by mistake, does the behavior shown in the Youtube video I linked actually make sense ? Surely, ending up with a catalog having references to non-existing files on the file system, and sending all the original files back to the original import folder, without informing the user of any problem, isn't the right thing to do by default when this happens.
The proper behavior if the sequence increases past the number of selected digits would be to have some kind of interaction with the user informing them of a problem with the import, and offering options to fix it, such as increasing the number of digits in the sequence number. I'm not really sure what viable other choices could be if that happens, to be honest.
Now that I have ranted enough, I reviewed my image folders. It looks like I started getting rename issues in August.
Here is what I edit to fix it.
1. I moved the 08, 09, 10, and 11 subdirectory on the file system in another tree, in D:\Source.
2. I synchronized the catalog, to make remove all the entries for those files.
3. I ran File / Import
4. I edited the rename preset to have a 5 digit sequence number.
5. Finally, I clicked import.
The sequence number doesn't reset daily, but is still for the entire import operation. It started at 1 for the first image in august, and ended at 790 for the most recent image in November. Looks like things worked OK. I will have to redo the face recognition (People tabs) for the last 4 months. Not sure if I lost anything else doing this. All tags were previously export to DNGs or XMPs. The tags on previously recognized faces (manual or auto) are still there. The database in the People tabs no longer knows anything about them, though.
I had to redo the import one more time as I hadn't edited the digits in the sequence number properly. It was pretty late, doing that at 3am.
Now, all the filenames have the sequence numbers padded with 0s on the left. This is different from the behavior in Lightroom 10, when the sequence number wasn't padded.
Padding the number makes sense for sorting files. However, this has been poorly implemented, as the video in my second post shows.
How about :
1. Adding back the unpadded option, which worked fine
2. Not defaulting to a single digit for elements such as Sequence number
3. Not defaulting to a single digit in renaming presets, for example, this built-in preset, which is sure to break if importing more than 9 images :
4. Fixing the strange behavior when number of digits is exceeded
Unfortunately, I'm still experiencing this problem on subsequent imports, even with the following renaming template set to use 5 digits. I think the number of digit settings is just the minimum number of digits, not the maximum. Things definitely used to work fine in the past with just 1 digit set in the template, and doing imports of hundreds of pictures at once.
Almost every import is messed up for me at this point. This looks like a serious regression.
I downgraded back to Lightroom 10.4 . This insane problem has gone away, thankfully. I'm able to use a single digit for the sequence number, and the number still increases past 1 digit; it just doesn't get padded with zeroes.
Please fix this in LR 11.0 ASAP, as that version is unusable without being able to import images.
Testing this further, when Lightroom 10.4 (and below) do an import, and renaming causes a conflict, LR appends a -2 to the filename, or -3, etc, so that it does not conflict.
For example, if I do an import and it creates the file
Then do a second import of another image, and it attempts to rename it to the same name, it will rename it to
This may be a bit counterintuitive, but it does work. It does not result in the catalog having entries pointing to non-existing files. And it does not send back files to the original source.
In fact, due to this, with LR 10.4, I can juse a renaming template like the one I posted, except without the sequence number altogether. In this case, LR 10.4 takes care of appending the -X number to filenames, so that there is no name confllict.
I have not tried this with LR 11.0, as I have now removed it from my system, but I think it would behave identically to the video in my top post.