Lightroom: LR4 map module does not work on case-sensitive OS X filesystem

  • 2
  • Problem
  • Updated 6 years ago
  • (Edited)
I just upgraded to LR4, but the new map module does not work at all. All I get is a blank screen. I searched around a bit, and the most relevant information I could find was that during the LR4 beta someone else also reported that problem, and got as reply that case-sensitive OS X filesystems were not supported.

I can't really believe this is true. This restriction is not mentioned in the technical requirements for LR4 (or any other official documentation afaik), I never had a problem with LR3, and I don't see any technical reason for this limitation.

And no, reformatting my disk to a case-insensitive filesystem is not an option: I work with collections of files that cannot be stored on such a filesystem. Not to mention that it would a big pain to do.

So, can anyone from Adobe confirm or deny that this is an official limitation of LR4? Or that this is a bug that will be fixed?
Photo of Kees van Reeuwijk

Kees van Reeuwijk

  • 3 Posts
  • 0 Reply Likes

Posted 7 years ago

  • 2
Photo of John R. Ellis

John R. Ellis, Champion

  • 3734 Posts
  • 976 Reply Likes
This Adobe support article states that LR 4 cannot be run on a case-sensitive partition:

http://helpx.adobe.com/lightroom/kb/m...

The LR 4 beta posts you read were from Adobe employee Baichao Li:

http://forums.adobe.com/message/41926...
Photo of Kees van Reeuwijk

Kees van Reeuwijk

  • 3 Posts
  • 0 Reply Likes
Hello John,

Thanks for the links. I looks like Adobe does not consider this a bug, which I find very disappointing. Since this limitation is not mentioned in the technical requirements I am considering filing a bug report nevertheless, or ask for a refund. I have to think.

I really wish I would't have to do this, but Adobe should not get away with this. Case-sensitive filesystems are a normal part of OS X, so Adobe has to do more than just let people discover this flaw after they have bought the software.
Photo of John R. Ellis

John R. Ellis, Champion

  • 3734 Posts
  • 976 Reply Likes
I agree that the Adobe marketing collateral should mention the requirement for case-sensitivity. Versions 3 and prior didn't have that requirement. I'm guessing that they weren't even aware of the "requirement" for LR 4 until they got into beta and discovered that some code (perhaps third-party code they've licensed) requires case-insensitivity. And then they forgot to tell marketing to update the Web site.

But I wouldn't have any expectation that Adobe will eliminate the requirement. The Creative Suite has long required case-insensitive volumes.
Photo of jdv

jdv, Champion

  • 728 Posts
  • 56 Reply Likes
"Case-sensitive filesystems are a normal part of OS X"

This is not strictly true. The kind of filesystem we are talking about here is controlled by a custom option on installation or disk setup. The great majority of OS X users will never even know about this option or ever enable it.

It is an option maintained by Apple mostly for use with legacy software ported from other platforms, mostly for server applications.

If you want to run Lr 4, you may as well install a new volume formatted with defaults and run it from there.
Photo of Kees van Reeuwijk

Kees van Reeuwijk

  • 3 Posts
  • 0 Reply Likes
Hello John Verne,

It is true that a case-insensitive filesystem is the default. However, I am not aware of any official document from Apple that declares the alternative "an option [...] mostly for use with legacy software ported from other platforms, mostly for server applications". Can you point me to such a document?

Creating a new volume just for LR4 is not an option. I use it on a laptop with a SSD, and space it tight enough as it is without partitioning it. And I need the filesystem on that SSD to be case-sensitive, because I work with file sets from the Unix/Linux world, where case-sensitive filesystems are standard.

Apart from all this, if LR4 does not work on case-sensitive filesystems, Adobe should say so in the list of technical requirements, rather than letting people discover the problem after they have paid for the software.

Or they could just fix the problem.
Photo of jdv

jdv, Champion

  • 728 Posts
  • 56 Reply Likes
See here, and other places: http://support.apple.com/kb/TA21400?v...

Apple has made it (as clear as they ever are on these things) that it is not recommended for most people.

Even some of Apple's own utilities have failed to run on case-sensitive filesystems in the past. It has been a perennial problem since as far as I can remember, and I've been using OS X since the first release.

Note that I was responding to Rob's comment that such configs are "normal". Well, it depends on what your definition of normal is. My definition includes things like "very common, likely to be found in the wild, constituting a large percentage of user population, promoted by the vendor" which is simply not the case. There are many ways I can install OS X such that it is "supported" by Apple that would render it hostile to any number of apps.

This has no bearing whatsoever on whether it is /possible/ or that there is actually a problem.

My guess is that there was a disconnect between a decision made early on in the pre-release cycle and messaging. Either this was a late regression, or the intent all along was to not support it (which places them in fair company -- many apps simply do not support this configuration -- like I said, this is a perennial problem) and this never made it to the release notes.

But no one has a perfect crystal ball. We should await what Adobe says about this.
Photo of David Gatwood

David Gatwood

  • 4 Posts
  • 1 Reply Like
That is absolutely incorrect. That article applies only to version 10.3 of Mac OS X. At the time, case-sensitive HFS+ was very much in its infancy, and you could not boot from it. Hence, for version 10.3, it was intended only for very limited use because of those limitations. Those limitations were fixed in later versions of the OS, and as a result, that kbase article is no longer consistent with Apple's current policies and recommendations. Further, the kbase article in question has been retired for precisely that reason.

Apple's *current* file system usage guidelines for developers clearly state that apps are expected to work correctly on both case-sensitive and case-insensitive volumes. This guidance is repeated in multiple places in Apple's file system documentation, and apps that do not work correctly on case-sensitive volumes are potentially in violation of the Mac App Store guidelines (2.30, specifically).

Apple's developer documentation mentions case sensitivity in multiple docs.

*****

The File System Programming Guide:

http://developer.apple.com/library/ma...

in a section called "Assume Case Sensitivity for Paths", says this:

When searching or comparing filenames, always assume that the underlying file system is case sensitive. OS X supports many file systems that use case to differentiate between files. Even on file systems (such as HFS+) that support case insensitivity, there are still times when case may be used to compare filenames. For example, the NSBundle class and CFBundle APIs consider case when searching bundle directories for named resources.

*****

And Technical Note 2096 (Debugging Case-Sensitivity Bugs in Applications):

http://developer.apple.com/library/ma...

says this:

Because case-sensitive HFS Plus performance is comparable to that of standard HFS Plus, case-sensitive boot volumes are becoming much more common. ... With this rise in popularity, it no longer makes sense to assume that only a handful of your application's users will use case-sensitive volumes.

(Incidentally, that technical note also provides scripts that should make it fairly easy for Adobe to figure out what they're doing wrong.)

*****

Finally, Apple's Secure Coding Guide:

https://developer.apple.com/library/m...

says this:

If your program periodically accesses a file on a case-sensitive volume using the wrong mix of uppercase and lowercase letters, the open call will fail... until someone creates a second file with the name your program is actually asking for.

If someone creates such a file, your application will dutifully load data from the wrong file. If the contents of that file affect your application’s behavior in some important way, this represents a potential attack vector.

This also presents a potential attack vector if that file is an optional part of your application bundle that gets loaded by dyld when your application is launched.

*****

No, this is a very real and serious bug that Adobe needs to fix ASAP. Case sensitivity bugs are not only serious flaws in the functionality of the app, but also represent potential code injection attack vectors just waiting to be exploited.

Finally, I would like to add that iOS uses a case-sensitive volume format. Given that Mac OS X is steadily evolving to be more and more like iOS, the clear trend in Apple technologies is *towards* case-sensitive disk formats, not away from them. Adobe would be wise to start fixing these bugs sooner rather than later. If they do not, there's a high probability that it will come back to bite them.
Photo of David Gatwood

David Gatwood

  • 4 Posts
  • 1 Reply Like
Just to follow up on my previous comment, now that I've downloaded LR4, it took me just under one minute to find and successfully work around this bug.

In Terminal, type:



cd /Applications/Adobe\ Photoshop\ Lightroom\ 4.app/Contents/Support/APE/adbeapecore.framework/Versions/A/Libraries

sudo ln -s WebKit.dylib Webkit.dylib


After you do this, the map module will work correctly.

Adobe, please edit your Xcode project file and fix this typo. That single errant lowercase 'k' in your Xcode project file (probably in a couple of places) is the only thing standing between your app working on case-sensitive volumes and not.