Lightroom SDK: catalog:findPhotoByPath should not be case sensitive

  • 4
  • Problem
  • Updated 7 years ago
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.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes

Posted 7 years ago

  • 4
Photo of jdv

jdv, Champion

  • 728 Posts
  • 56 Reply Likes
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.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
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...
Photo of John R. Ellis

John R. Ellis, Champion

  • 3589 Posts
  • 928 Reply Likes
I agree with Rob. Also, note that Photoshop CS5 and other Adobe products cannot be installed on a case-sensitive volume.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
|> 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...
Photo of jdv

jdv, Champion

  • 728 Posts
  • 56 Reply Likes
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.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
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...
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
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.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3589 Posts
  • 928 Reply Likes
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.
Photo of Rob Cole

Rob Cole

  • 4831 Posts
  • 379 Reply Likes
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.