rob_cole_2221866's profile

4.5K Messages

 • 

76.3K Points

Mon, Oct 24, 2011 3:48 AM

Closed

Lightroom SDK: catalog:findPhotoByPath should not be case sensitive

This function is called when working "back" from a disk file to a corresponding photo in the catalog.

The disk file path is case insensitive, but the method is not.

Thus, if a user changes the case of files on disk, this method fails.

Champion

 • 

704 Messages

 • 

8.5K Points

10 y ago

This depends on the host operating system and filesystem. Mac OS X since 10.3 can be installed and run on HFSX, which is case sensitive.

Typically, the solution in cases like this is to make your API case-sensitive, even if the filesystem is only case-aware and case-preserving (which is the case for both supported platforms.)

This is a non-trivial problem to solve, actually. You have to rationalize what the host OS returns for system calls with what is in the DB from the time of table updates to what may have changed since.

Simply making the SDK function case-insensitive will just move the problem to somewhere else, unless it is done very, very carefully.

4.5K Messages

 • 

76.3K Points

I'd prefer the function be case insensitive, since 99.999% of installations running Lightroom are on case insensitive file-systems. For the .001% of users running Lightroom on a case sensitive filesystem, having a case insensitive function would only be a problem if user is naming different photos with the same name, but different case - *not* a good idea anyway. What happens far more frequently is that an unwitting user switches the case of the extension they are using for exported, published, or even source photos, and expects not to have a problem, but does...

I recommend changing the function to case insensitive and making a note in the fine print for people running on case sensitive filesystems - "don't use case to distinguish different photo files". I suppose if one really wanted a 100% solution the function could be adaptive, but I don't think its worth the bother.

Summary: it would be far better to have the function work properly for the vast majority, and leave the potential problems for the vast minority, than the vice of that versa...

4.5K Messages

 • 

76.3K Points

10 y ago

I'd prefer the function be case insensitive, since 99.999% of installations running Lightroom are on case insensitive file-systems. For the .001% of users running Lightroom on a case sensitive filesystem, having a case insensitive function would only be a problem if user is naming different photos with the same name, but different case - *not* a good idea anyway. What happens far more frequently is that an unwitting user switches the case of the extension they are using for exported, published, or even source photos, and expects not to have a problem, but does...

I recommend changing the function to case insensitive and making a note in the fine print for people running on case sensitive filesystems - "don't use case to distinguish different photo files". I suppose if one really wanted a 100% solution the function could be adaptive, but I don't think its worth the bother (I haven't bothered in the work-around solution I've programmed - which works now for case insensitive filesystems but is extremely inefficient).

Summary: it would be far better to have the function work properly for the vast majority, and leave the potential problems for the vast minority, than the vice of that versa...

Champion

 • 

6K Messages

 • 

103.7K Points

I agree with Rob. Also, note that Photoshop CS5 and other Adobe products cannot be installed on a case-sensitive volume.

4.5K Messages

 • 

76.3K Points

|> Photoshop CS5 and other Adobe products cannot be installed on a case-sensitive volume.

Case sensitive installations are surely confined to very limited circumstances - like on a partition separate from the main system when somebody needs compatibility with an old unix disk or something...

Champion

 • 

704 Messages

 • 

8.5K Points

The problem with a 99% solution is that the 1% can contain really big problems that you have just created a sort of lobster trap for your users.

Also, case-sensitive is only one part of the story. It is the combination of case-preserving and case-aware that really complicates the story. This is why you make assumptions about how the files will behave on unknown future file systems at your peril.

4.5K Messages

 • 

76.3K Points

catalog:findPhotoByPath is used to check if a file found in the filesystem is already in the catalog or not (and if so, get a reference to it...). Since the filesystem is not case sensitive, the function needs to be too, otherwise the function fails if the user or other software has changed the case since it was added to the catalog. All the theory in the world won't change that.

I mean, if Lightroom itself no longer recognized a photo due to a case change, it'd be a different story, but alas that's not how it is, nor should it be.

How it is: Lightroom still recognizes the photo, but plugins can't - this is not a good thing for a plugin, no not good at all...

4.5K Messages

 • 

76.3K Points

10 y ago

Adobe - make no mistake: plugin programmers would much prefer it if this function is not case sensitive, so their plugins work correctly, without a lot of extra effort and a big performance penalty.

4.5K Messages

 • 

76.3K Points

10 y ago

Here's just two of the many functions I have used over the years to help with this problem:

--[[
Synopsis: See if photo obtained by disk path, is in the catalog, even if under different case extension.

Notes: - Use when file found initially on disk and may be in catalog under a different case.
- There is another technique I've used called "find photo in catalog by desparate means" which
iterates every photo in the catalog doing case-insensitive compare - it should be reserved
for case when photo really should exist but not found first try.

Returns:
--]]
function RcCatalog.getPhotoByPathIgnoringExtCase( path )
local photo = catalog:findPhotoByPath( path )
if photo then
return photo
else
local ext = LrPathUtils.extension( path )
if ext == nil then return nil end
ext = LrStringUtils.upper( ext )
local _path = LrPathUtils.replaceExtension( path, ext )
photo = catalog:findPhotoByPath( _path )
if photo then
return photo
else
ext = LrStringUtils.lower( ext )
_path = LrPathUtils.replaceExtension( path, ext )
photo = catalog:findPhotoByPath( _path )
if photo then
return photo
end
end
end
return nil
end

--[[
Called when high-performance photo find methods fail.
Objective: Find photo even if it takes a long time.
Does this by comparing base path of every photo in catalog
to base path of incoming photo.

Without the alt-source-ext
confirmation, we cant be sure if a photo with same base is found, it really
represents the source of the target. Nevertheless, we return whatever is found.
hoping its right and logging a warning in case it isn't.

*** Logs warning if found. - caller should log warning or error if not.
--]]
local function makeDesparateAttemptToFindItemInCatalogByPath( sourcePhotoStartPath )
local basePath = LrPathUtils.removeExtension( sourcePhotoStartPath )
local allPhotos = catalog.allPhotos
local catBasePath = nil
for _, photo in ipairs( allPhotos ) do
catBasePath = LrPathUtils.removeExtension( photo.path )
if catBasePath == basePath then
local extension = LrPathUtils.extension( photo.path )
local returnPath = LrPathUtils.addExtension( catBasePath, extension )
logWarning( "Item found in catalog by desparate means, assuming: " .. returnPath .. " - Hint: Update alt-ext in site-config file to get rid of warning." )
return returnPath
end
end
return nil
end

Y'all gettin' the idea yet?

If not, I can provide more examples. The desparate means one must go through to make a robust plugin depend on individual circumstances, but none are nearly as elegant as:

local photo = catalog:findPhotoByPath( path ) -- don't worry: like the filesystem and Lightroom itself - its not case sensitive.

Rob

Champion

 • 

6K Messages

 • 

103.7K Points

10 y ago

Unlike CS5, Lightroom has no formal requirement one way or the other regarding the case sensitivity of volumes. (CS5 requires case-insensitive system volumes.) But it's safe to say that at a minimum, Adobe intends LR to support case-insensitive volumes, which are the defaults on both OS X and Windows. Unfortunately, LR has some bugs implementing case-insensitivity that continue to bite end users now and then:

http://feedback.photoshop.com/photosh...

Without knowing Adobe's intended requirements for LR and case sensitivity, it's hard to say what the APIs should be. But it's obvious that the current SDKs don't make it easy for plugin developers to obey case insensitivity for files residing on case-insensitive volumes.

Thus, I agree with Rob that it would good if LR provided more robust APIs that made it possible to, at a minimum, support case-insensitivity on the overwhelming majority of OS X and Windows installations that are case-insensitive.

4.5K Messages

 • 

76.3K Points

I have no objection to maintaining case sensitive functioning (for the rare times when that might be preferable), as long as case insensitive functioning is added somehow, for the overwhelming majority of the time when that behavior is preferable.