P: SDK: Unable to add photo to catalog when parent folder name has a dot at the end.

[areohbee]

Lightroom SDK: Unable to add photo to catalog when parent folder name has a dot at the end.

For example, this works:

catalog:addPhoto( "C:\dir\subdir\file.nef" )

but this does not work:

catalog:addPhoto( "C:\dir\subdir.\file.nef" ) -- hangs forever.

Rob

[dorin_nicolaescu]

Official response:

We decided to defer this bug because it is a clear edge case. Windows explorer won't let you create a directory like this, nor will it allow you to view it. Even in the Windows command shell (cmd.exe), you can't move into such a directory. In order to create a directory such as the one listed in the bug you have to go through some hoops, thus the decision on this being an edge case that we aren't sure makes sense to support.

[areohbee]

This bug report is NOT a request for support. As it stands, Lightroom (or the plugin anyway) will hang forever if such an attempt is made - *that* is the problem.

Consider throwing an error instead. - that is what "should" happen, and would be consistent with the documentation.

[dorin_nicolaescu]

Rob, how do you create a directory with a name like that?

[areohbee]

You're missing the point, which is:

Code like this:

* create dir with (inadvertent) dot
* if ok, copy photo file to said dir
* if ok, add said file to catalog.

which is perfectly legitimate code, or so it would seem, will hang forever.

Yes, plugin authors like me who've been bitten, will now check explicitly for dots at the end of subfolder names, to make sure their plugin doesn't hang forever. But other plugin authors (like me before I was bitten), or their users, will just wonder why the plugin keeps hanging.

Do you see the problem? -

code should either add the photo, or throw an error, like the documentation says...

Either that or amend the documentation to read:

Function will either
* add the photo
* throw an error
* or hang forever if there is a dot suffix in subfolder name.

The later would of course be too embarrassing, so I recommend the former.

This seems so obvious to me that I can't imagine not fixing it, or rationalizing not fixing it. Maybe I'm too much of a perfectionist, or was it just not clear before what the problem is?

PS - I just noticed that the import dialog box disallows subfolder names that end with dots - I guess the Lr programmers have already been bitten by this "bug" too.

Rob

[dorin_nicolaescu]

Ah... you mean it hangs if you just pass a "dot-folder" as a parameter to the addPhoto method?

[dorin_nicolaescu]

OK, but where does the dot-named folder come from? Is it user-generated?

[areohbee]

Yes, and yes.

- typical case would be target path computed based on user input.

~R.

[John R Ellis]

The bug is simple and has a trivial fix: catalog:addPhoto (path) should call LrPathUtils.standardizePath (path) before doing anything else.

Details

In general, Windows ignores directory names with a trailing dot, e.g. if you type "c:\users\ellis\desktop\a.\test.docx" into the Microsoft Word Open dialog, it will treat that the same as "c:\users\ellis\desktop\a\test.docx".

The LR application also ignores dots at the end of directory elements. For example, if you do Add in the plugin manager and type "plugins.\myplugin.lrplugin", that will be treated the same as "plugins\myplugin.lrplugin".

The LR SDK generally applies the same rule. For example, LrPathUtils.standardizePath() will remove trailing dots from directory elements in the path. LrFileUtils.createAllDirectories() will also remove trailing dots from directory elements.

So the correct behavior of

catalog:addPhoto( "C:\dir\subdir.\file.nef" )

should be the same as:

catalog:addPhoto( "C:\dir\subdir\file.nef" )

That is, the implementation of catalog:addPhoto (path) should first apply LrPathUtils.standardizePath() to the "path" argument. This is a trival fix that I hope the LR team could find the time to apply.

[areohbee]

That would be great. So, trailing dots in subfolder names are simply ignored - consistent handling that way across the board... The example pseudo-code above would then not fail. User (or software) would not get the dot he/she thought might be there, which may have potential for trouble as well, but nevertheless it would solve the main problem and seems very appropriate.