• Welcome to the Lightroom Queen Forums! We're a friendly bunch, so please feel free to register and join in the conversation. If you're not familiar with forums, you'll find step by step instructions on how to post your first thread under Help at the bottom of the page. You're also welcome to download our free Lightroom Quick Start eBooks and explore our other FAQ resources.
  • Dark mode now has a single preference for the whole site! It's a simple toggle switch in the bottom right-hand corner of any page. As it uses a cookie to store your preference, you may need to dismiss the cookie banner before you can see it. Any problems, please let us know!

How to Rename to Get Rid of (-1) and (-2) Numbers LR Adds to Some Filenames

Status
Not open for further replies.

Alley Oop

New Member
Joined
Oct 5, 2011
Messages
5
Location
Florida, USA
Lightroom Experience
Advanced
I need a way to rename LR files to get rid of the pesky (-1) and (-2) digits that are added to files names.

I rename using a custom template (0001_YYMMDD), and it does not get rid of these numbers that LR adds making a file number like 2485_111004.CRW become
2485_111004-1.CRW or
2485_111004-2.CRW

Any suggestions are appreciated!
 
I typically run the rename command twice.

What happens that that you, for example, have files named "F1", "F2", and "F3", and you would like to renumber them starting with "F2". In this case, when Lightroom renames "F1" to "F2", the name is already occupied, so it will be named "F2-1". Likewise when renaming "F2" to "F3". "F3" will, however, correctly, be named "F4" as this name has not previously been occupied.

By running the rename command again, "F2-1" will now be renamed to "F2" as this name now is not occupied.

This could be solved by letting Lightroom rename the files in a better order, e.g. by starting with the files where the destination name is not occupied. (In the case of a cyclic dependency (like when renaming "F1" and "F2" to "F2" and "F1", respectively), Lightroom could temporarily rename one of the files to something else.)

Seriously, Adobe, this is trivial stuff -- it should not be a problem in a mature product like Lightroom.
 
Alley, Welcome to the forum. LR does not add the "-1", "-2" to the file names. Your operating system doe. One of the cardinal rules for file systems is that no two files can reside in the same folder and have the same name. To obey this rule, the OS either does not copy the second occurance or the OS adds extra characters to make a unique name. So either your custom template is constructed to make duplicates or the file already exists in the folder whenever you generate the file name using the template in LR. Perhaps you are always writing to the same folder each time and each time your template begins with "00001-YYMMDD" If you run this process twice or more on the same date, you will generate a file names "0001-111004" each time and subsequent files will append the "-1", "-2" to the file names.

Are you doing this on import? If the problem is with your naming template, could you post a screen shot of your "Filename Template Editor" dialog and explain what your desired output name needs to be?
 
Actually.... LR certainly can add the "-1", and I wouldn't be at all surprised to see it add the "-2", though I've not seen it myself.

The cause and workaround are very much as andersl explained. The problem is that at the start of the batch renaming process, LR checks the existing file names in the folder and generates new names with "-1" to avoid naming collisions. But it really needs to consider whether there will be a collision based on what the filenames are going to be at the conclusion of the renaming process and if necessary do the renaming in two passes.

To prove LR has a problem (which I've moaned about) set up a folder of 10 images and name them using a YYMMDD_{2 char seq} {title} naming scheme *. Now delete one image - the 4th - and try renaming them again. You'll see the 5th image onwards has a "-1" in the name.

You avoid it by renaming twice - once with a random renaming scheme, and then with the correct one.

John


*This naming scheme is quite common amongst those who show clients all their keepers and the gapless sequential numbering means the client won't see breaks in the sequence and ask to see substandard images.
 
Last edited:
I run into this problem basically every day. Currently, I scan old slides from boxes -- the boxes are fairly complete, but sometimes an odd slide is missing.

After I have scanned a box I run a plain rename command that includes a sequence number, this initial rename is done on all slides starting with number 1. The next step is to locate the missing slides. If, say, slide 14 is missing I mark the subsequent photos (starting with the one incorrectly numbered 14) and re-run the rename command starting with number 15. Here, the result of the operation will be files named "xxx-1", despite the fact that after the operation, no file is named "xxx".

Cletus, I do not agree that it's the fault of the operating system. Lightroom has got full control over all the files that are involved in the rename operation. It will perform the rename operation on one file at a time, at any order. All Lighroom would have to do is to pick files where the destination file does not exist first, then the result of the operation would be correctly named files. To me, as a programmer, this is trivial stuff, and I'm sure that once the development team gets the information it will be fixed within minutes.

The "-1" naming scheme is a good idea -- but only to prevent files not involved in the rename operation to be overwritten.
 
Last edited:
...Cletus, I do not agree that it's the fault of the operating system. Lightroom has got full control over all the files that are involved in the rename operation....The "-1" naming scheme is a good idea -- but only to prevent files not involved in the rename operation to be overwritten.
It is not a fault of the operating system, it is a feature as you point out to prevent collisions. LR uses the standard OS filesystem API to pass a name off to the file system when the file is to be written. LR and any other application does not do any file operations natively. This is left up to the file system and the file system functions like read, write, move, copy and delete. This is why LR can be compiled for OSX or Win and not need to do anything special or even know about what file system is managing the HD. It was not too many versions ago that Windows would just fail with an error message whenever your application attempted to write a new file and there was already one existing with that name and path. It may have been Vista that first provided the 'soft landing' by appending additional characters on a file name. I'm not that familiar with earlier versions of the Mac OS or when Apple started providing this same functionality in the API that all applications use to write to the HD.
 
Thanks for the useful info

This is the first mention of the appended numbers issue that I have found and to tell you the truth, my head is spinning!

I am assisting a friend who has a Catalog of what he thought was some 35,000 images from a recent field trip during which the .LRCAT file or the LR installation developed a problem and it all ended up a bit of a mess. The solution has been to build a new catalog from the DNGs and JPGs on his backups but after doing this I find almost 60,000 images reported by LR. Many have identical base file names but with -2 to -7 appended so I had assumed that somehow most of these were duplicates.

His files are re-named on import to DD-MM-YYYY_HourMinuteSecond and many of the appended files are sequences taken at 12FPS on a Canon 1D4 so am I right in thinking that it's likely that the seconds are recorded in EXIF with no decimal places and that the issues outlined in this thread are the cause of the problem? Sorting out what are intended sequences and what are duplicates is a nightmare at 12FPS :cry:

If my supposition is right, can anyone suggest a better date/time template that would avoid these issues - it's important to define each shot as exactly when it was taken (although to the second is good enough!).
 
It's not a matter of a better date/time template - DD-MM-YYYY_HourMinuteSecond is fine. The problem is Lightroom's renaming feature. To avoid it or fix it afterwards, run the renaming twice - once with DD-MM-YYYY_HourMinuteSecond-UtterRandomGarbarge and then "YYYY-MM-DD_HourMinuteSecond Correct Text" (note year, month, day).

John
 
Thanks, John. I've run an experiment with a burst sequence of 20 shots taken over a three second period and now understand what LR is doing, but can't see how the current template can be made to work unless there is a way of including fractions of a second. (We do use YYYY-MM-DD by the way, my posting error!) When more than one shot is recorded as captured during a single second the file name is going to potentially wind up the same as its neighbours which is why LR renames it although I see that sorting by capture time appears to recognise the correct order so I suspect that maybe tenths of a second are recorded in EXIF but not displayed.

I appreciate that I could include the original file name as a prefix in the naming template but the new file name is starting to get quite long and unwieldy.
 
Actually, I'd not thought that sub-second was the key to this problem, and there's no way to get at it in LR. I have a vague memory about the reason being partly inconsistency between camera makers and models, but I'd also wonder about the real value of fractions, at least in most cases. Assuming the hour down to the second does have some real importance for you, the way I'd approach this is "YYYY-MM-DD_HourMinuteSecond_seqNo Text", so with a sequential number that would be for the shoot as a whole. Sequential numbering is a control in its own right (proving all images are still present) but it also provides you with a more visual cue - it's easier to remember you liked image 515 in a shoot than the 123005-05. You'd also only have to run one renaming process.

John
 
A False Dawn

Sorry for the delay in picking up from your reply. I thought I'd found the way forward but now it looks like a false hope....

Firstly, the naming schema we adopted on import was clearly a mistake for the reasons above (ie it was bound to cause some conflicts when several frames were recorded in the same second - I thought that the naming would work in the same way as the sorting which gives the correct order every time as far as I can tell) and, although it was done to meet the requirement of the the author, there are other ways to meet his criteria so doing a rename to something bulletproof is a given. The core of the problem now is that the catalog has a lot of duplicates and I can't see a logic behind what has happened and how to correct it.

Mostly, files with a suffix of -2, -3, -4, etc will be duplicates of the main file name that precedes them and, just when you begin to think it's simple, 2011-07-31 032048-3 and 2011-07-31 032048-5 turn out to be duplicates but of a different image to 2011-07-31 032048-2 and 2011-07-31 032048. There also appears to be some where the original shot has acquired a suffix so just searching and deleting files with hyphen number dot won't work although it gives a clue to the size of the problem (big, it must run to 10's of thousands of files). It seems to me that I need a really reliable dupe finder that will look at the image rather than just the metadata and present the results in a usable form, or a LR Fairy to grant my wish that somewhere in the database the name of the original CR2 files still lurk.

Your ideas much appreciated...
 
Rename to Original

@Sprocket : open up the File Rename dialog box, choose "Edit..." from the drop-down menu, and you should see "Original Filename" as an option - insert that and delete all others and apply, and you should have your original filenames back.

Let us know if that works for you.

Filename Template Editor.jpg
 
Sorry for long delay in posting the response to your suggestion. Original filename seems only to revert to the name that was given it on import. To truly sort out the problems I have, I would need the original filename that the camera assigned the image when it was shot (ignoring the extensions, of course which are now all .dng).
 
Status
Not open for further replies.
Back
Top