# Lightroom can’t correctly get the original file number



## Mr_Platypus (May 27, 2020)

Hi all,

Let's say I have a file named DSCF1234-2.jpg. If I change its name with a custom setting that includes the original file number, instead of being renamed as customtext_1234-2.jpg, it'll be renamed as customtext_2.jpg.

Is there a way of avoiding this?

Thanks in advance!


----------



## Jim Wilde (May 27, 2020)

I would think that's a bug, i.e. it's only picking up the "-2" part of the original number suffix. Other than renaming manually, I can't see a workaround. Easiest solution would probably be to use "Custom Text_Filename" as the renaming template, then either leave it like that or manually delete the "DSCF" after the rename. 

I'll report it as a bug to Adobe.


----------



## Philippe Coudé du Foresto (May 27, 2020)

LR can identify as the sequence number in a file name an ending numeric pattern if it is separated by a delimiter ("-" or "_"). 
I woudn't call it a bug, because without a delimiter, how to determine what is the sequence number? Searching for numeric characters is not enough. Think of this file name "123Cat45.jpg", what is the sequence number: "123" or "45" or even "5" or...


----------



## Jim Wilde (May 27, 2020)

I don't know how it is coded, but having a delimiter is not needed. All the SOOC file names from my cameras have 4 letters followed by 4 numbers, e.g. JRWR1234.CR3.....and the "Original Number Suffix" is correctly identified as 1234. So it's the addition of the "-2" which is messing up the token, which I can't believe is the intended behaviour.....and if it's not intended then it should be classed as a bug, IMO.

Renaming a selection of images from the same camera, each with the "-2" suffix, e.g. JRWR1234-2, JRWR1235-2, JRWR1236-2, etc., using a rename template of "Custom TextOriginal Number Suffix" the current behaviour would in theory make all the names the same, i.e. "custom text2".....but if they're all in the same folder that can't happen, so Lightroom creates filenames of "custom text2, custom text2-4, custom text2-5, custom text2-6, etc.". I would imagine the same would happen if exporting the images using that rename template.


----------



## Gnits (May 27, 2020)

This is tricky.  When the file is captured by a camera and stored on an SD card, file naming conforms to various standards and is stored in a sub folder of a DCIM folder.  In this way Lr can reasonably be expected to extract the original image number from the file name.

However, when the file is renamed, either manually or via a renaming algorithm, there is no guarantee what numbers might mean as the number may just be a new sequence number and bear no resemblance to the original file name/number.

Further, when Lightroom exports images, if the destination file already exists it provides the user with the option to add a sequence number to the filename to avoid duplicate filenames in the same folder and also overwriting the file already there.

Further, files can be renamed before they arrive in Lr, such as ingesting from card to disk using a program such as PhotoMechanic.

You need a solid consistent file renaming workflow if you intend to use or re-use numbers within a filename.

In my case I ingest my images from card to disk using a format such as XXX_UUUUU_NNNN where 
XXX is my initials
UUUUU is a unique sequential number
NNNN is the original file number.

When I export images, they always go into a sub folder (eg WebJpg) without renaming the output file, so they retain the XXX_UUUU_NNNN.  If I opt to export this file multiple times into the same sub-folder, I will decide to overwrite the destination file or be happy to have a seq no added to the end of the file. No matter what happens I always retain the unique number (UUUUU) and the camera number (NNNN).

Having a unique number means I can look for that unique number and find out easily where I have used that file in multiple different projects and see the raw, PSD, Tiffs or any other variation of this file.

There is one other dimension to explore. There is a field called Copy File Name.   There are a whole bunch of rules regarding this, but it sometimes might hold an old or original filename. Because this was not reliable for my needs I avoided using this field.

At the moment I use PhotoMechnic(Pm) to ingest and rename my images from card to disk before importing to Lr.  I have configured Pm to store the original filename in 2 different IPTC fields ( 1. Job Id and 2) Suppliers Image Id). Both of these fields are visible inside Lr on the metadata tab. In this way I am guaranteed that the original filename as captured by the camera always stays within  the metadata of image(as long as the metadata is not cleared).

Bottom Line.... Someone on the forum may know if the very original filename is buried somewhere in the Catalog database and can be used... If not, treat all numbers in filenames with caution.


----------



## Jim Wilde (May 27, 2020)

The point is, Gnits, as you know Lightroom provides the ability to rename files using a combination of many different tokens. One of which is "Filename Number Suffix", which is based on the current filename, and there's a similar token called "Original Number Suffix" which is based on the "Preserved Filename" (which is the filename at the time of import).

As the vast majority of SOOC filenames end with 4 digits, those two tokens would typically relate to those 4 digits....and in the vast majority of cases that's indeed what happens. The problem for the OP is that he's managed to get into the situation whereby the filenames are ending with the additional "-2" suffix, which can be caused in various ways, one of which is by copy-importing into a folder which already contains files with the same name. In that situation Lightroom continues with the copy import but has to differentiate the name from the original, so appends the "-2". And it's that "-2" which causes the problem outlined in the OP when subsequently trying to rename those files whilst including the original number suffix. Clearly, the rename alogrithm is getting tripped up by that "-" delimiter between the original 4-digit suffix and the added one digit suffix. 

Anyway, I've flagged it to Adobe and will see if/how they respond.


----------



## Gnits (May 27, 2020)

Anything which provides clarity to the options for use  of metadata is exceedingly useful. I welcome any comments Adobe might have on this.

Is the 'Preserved File Name' available generally as a tag for use in Lr, say in export filename or search criteria, as this would be most useful for many scenarios.  Maybe 'Preserved File Name' may also have a different tag name.


----------



## clee01l (May 27, 2020)

I think the method that Lightroom uses  is to inspect the file name part in reverse order.  Numeric characters are peeled off and added to the vaiarable for the numeric suffix.  the process continues to loop until it encounters the first non-numeric character.   *This is not a bug*, this is simply how the function works, It is a common C++  API built in function and for other languages.   This works fine for files that meet Design rule for Camera File system (DCF) is a JEITA specification (number CP- 3461) which defines a file system for digital cameras.   Copy the file to Windows and name it something else that does not follow DCF  and these are the results.   Since no file can have the same name and path (folder) Microsoft appoint a -2 to the first duplicate filename in the folder.


----------



## Mr_Platypus (Jun 8, 2020)

It looks to me like Adobe's algorithm simply reads the original filename from right to left and conserves all the numbers until the first non-numerical character. So if the photo is named IMG_1234 the extracted number would be "1234", if it's IMG_1234-2 the extracted number would be "2".

I can think of several ways Adobe can easily and quickly fix the algorithm. It's just a matter of wanting to.

And yes, I say "fix" because this behavior is indeed problematic, no matter if they deliberately programmed the software to work this way or not. In other words, it doesn't really matter if it's a bug or a feature — imho they should just modify this.


----------



## clee01l (Jun 9, 2020)

Mr_Platypus said:


> It looks to me like Adobe's algorithm simply reads the original filename from right to left and conserves all the numbers until the first non-numerical character...
> 
> I can think of several ways Adobe can easily and quickly fix the algorithm. It's just a matter of wanting to.
> .



See my last post. It is not a bug and does not need fixing. It works for Image files that meet the standard JEITA naming rule. It may fail if the image file has been renamed and it will fail when the file has been renamed by the OS. 


Sent from my iPad using Tapatalk


----------



## Gnits (Jun 9, 2020)

1. I would welcome  if anyone could point me to the documentation or explanation for the differences between  Original filename, Copy Name and Preserved Filename. I have run into trouble in the past trying to use the Copy Name, probably because I misunderstood the proper meaning of this tag.

This is a screen grab of the F2 Rename function in Lr.






2. I understand (and make use of)  JEITA naming rules, but I have a certain sympathy with the scenario where Lr is adding the extra -2 to the filename and indeed it would be very easy for Lr to amend the algorithm to recognize a dash between two numbers at the end of a filename, maybe by creating a new token for such a scenario. It is probably a common scenario for people re-naming image names.

3. Maybe the OP could take advantage of the combination of Filename Suffix (now 2) with the Original Number Suffix (1234) for the renaming scenario in question.


----------



## clee01l (Jun 9, 2020)

Gnits said:


> Lr is adding the extra -2 to the filename


Lightroom does not add the "-2" to the filename.  The operating system does that to prevent name collision in the same folder path.   Two files can not have the same name in the same folder path.   This can happen when you import twice or copy any file to a folder that already contains  a file with that name.   Often but not always the OS will warn you  when two files are being added to the same folder path.  
Should there be an image file with the "-2" appended and the original file without the"-2" is no longer in that folder, it is because the original named files been deleted or moved. 

Similarly, when you upgrade the Lightroom catalog, the upgraded catalog has the "-2" appended to the catalog name because the old version of the master catalog file remains in the same folder.


----------



## Gnits (Jun 9, 2020)

I suspect Lr and not the operating system adds the -2. Lr is sensitive to the context of various copying files operations such as import, copy or export.

In this example, Lr does not allow the process to continue when duplicates are found.





In the Lr Export option, if duplicates found then Lr gives you the option to Overwrite or to make sure the file name is Unique (in which case it adds the -2, etc). So it is a Lr option which is creating the -02 suffix.

Most professional apps which are dependent on the integrity of file copying will not allow the operating system make the decision what to do.  In Lr's case it will want to control the unique name it is creating, check that file is copied correctly and then update its database with the new filename. The application logic will also check if the -02 file exists, if so, check if -03 exists, etc until a new unique number is found.

Most -02 scenarios arise in Lr during export operations.


----------



## clee01l (Jun 9, 2020)

Gnits said:


> I suspect Lr and not the operating system adds the -2..


Lightroom and all similar C++ programs use the FileSystem function built into the API. For all File System operations Again it is the OS API that determines file names and what to do when there is a name collision. 


Sent from my iPad using Tapatalk


----------



## Jim Wilde (Jun 9, 2020)

clee01l said:


> Again it is the OS API that determines file names and what to do when there is a name collision.


I'd suspect that there's communication between the OS and LR in this situation, i.e. LR instructs the OS filesystem to write the file in Folder "x"  and call it filename "y", but the OS determines filename "y" already exists in that folder and asks LR what to do. We all know what happens with the export operation, but import is more opaque....normal filesystem options would be to overwrite, skip (i.e. abort), or "keep both", but in this case LR decides to "keep both" (without troubling the user), and the OS does that by creating filename "y-2".
The outcome can be different depending on the operation, but I'd guess it's Lightroom that instructs the filesystem what to do when a filename clash occurs.


----------



## clee01l (Jun 9, 2020)

Jim Wilde said:


> I'd suspect that there's communication between the OS and LR in this situation, i.e. LR instructs the OS filesystem to write the file in Folder "x" and call it filename "y", but the OS determines filename "y" already exists in that folder and asks LR what to do. We all know what happens with the export operation, but import is more opaque....normal filesystem options would be to overwrite, skip (i.e. abort), or "keep both", but in this case LR decides to "keep both" (without troubling the user), and the OS does that by creating filename "y-2".
> The outcome can be different depending on the operation, but I'd guess it's Lightroom that instructs the filesystem what to do when a filename clash occurs.



Apps call the filesystem function and get back a return code denoting success, conflict or failure. You are correct that the options are overwrite, abort or keep both. If the keep both option is chosen by LR, the the Filesystem function will automatically append the “-2” to the existing file name as this is the 2nd file with that name in the folder. Before making the second call to the File system function, Lightroom could pause and ask the user which option to do. This would slow down the processing. Some users might like that and others would complain. You know how that goes. 
The thing is the function to rename files is based upon the assumption that the files being renamed are conforming to the JEITA standard. And that process is not in error 


Sent from my iPad using Tapatalk


----------



## Gnits (Jun 9, 2020)

" Apps call the filesystem function and get back a return code denoting success, conflict or failure. "

It is not as simple as that.  Any I/O function to disk must be wrapped in the application logic.  A return code from an I/O operation might reveal an error such as not having security access to the drive, disk failure, disk full, not enough memory and 1000's of other possibilities.   So as well as wrapping the copy function  in application logic, well written apps will have standardized code to deal with exceptions, that would otherwise cause the app to crash.  The last thing an app designer want to happen is to default to decisions taken by the o/s.

I have written or specified  many such routines  on a whole range of platforms and would audit development of new systems to ensure our test scripts catered for such scenarios.

I have just written one such routine (by co-incidence.. copy a file from an SD card to disk)  where the application logic caters  specifically for 13  specific error conditions and then has a failover routine to cater for unexpected errors.

For example, before I copy a batch of files (say 1000), I check that a duplicate does not already exist.  If I find duplicates, I report the number of problem files to the user with the choice.... Cancel, Overwrite or Create Unique FileNames...  

Based on the users choice, the batch copying of each file takes place, but the app still has to have logic to deal with i/o issues that did not exist before the copy process started but may happen during the copying.... an obvious scenario is if the disk fills up, a network drive goes offline, etc... A second obvious piece of logic is a smart app will recognize a batch job failed mid stream and may give the user the option to restart when the problem is corrected.

Copying files using Finder / Explorer... Mac and Windows will have their standardized logic for dealing with exceptions.  Copying the same files inside an App will invoke logic specific to the app.


----------

