Skip to main content
D
Dick W
Inspiring
February 21, 2024
Answered

Organizer chaos with case-insensitive SMB filesystem

  • February 21, 2024
  • 3 replies
  • 672 views

Somehow, Organizer thinks the same NAS folder(s) is (are) multiple different folders depending on case variations (UPPER, lower, Mixed) of the path. Somehow, apparently depending on (something I still don't recognize so am still not able to avoid) about how/when they got added, images are getting different case(s) (as in UPPER/lower/Mixed) of the path and Organizer is too dumb to recognize that the SMB filesystems are case insensitive. Folders "View as list" shows all of them. Folders "View as tree" only shows one of them. This problem has existed in Organizer for years/many Organizer versions and I've never found a good workaround/fix. I've complained about it in every pop-up "Would you recommend Photoshop Elements to a friend?" survey for probably a decade now. Just dragging the images from one folder to the "other" in Organizer causes more chaos because the image is already in the destination folder (hint to Adobe: it's the same file/same folder) so it creates a copy. Many years ago, I fixed one round of this by spelunking in the catalog with SQLlite. Yuck. There has to be a bettter way, right? Bueller? Anyone?

 

One of the versions of the same folder (via Folder "View as list") with a subset of the cataloged images:

Another version of the exact same folder (also via Folder "View as list") with a different subset of the cataloged images:

 

Here's the root of all Folders "View as tree":

 

And when I drill down in Folders "View as tree", there is only one "misc 2024" folder and it doesn't have the images from the "other" path to the exact same folder shown above and offers no way via "View as tree" to get to them:

 

    This topic has been closed for replies.
    Correct answer Dick W

    Once again, I resorted to hacking in the catalog.psedb SQLite file to, for now, repair this. I used a SQLite ODBC driver and MS Access to make it easier.

     

    Adobe PSE Organizer stores a volume_table and and a media_table. media_table rows have a volume_id column that is a foreign key to volume_table.id.

     

    The problem is that Adobe PSE Organizer stores //SMBHOST/photo, //SMBhost/photo, //smbhost/photo, etc, all as separate and distinct volume_table rows even though they are the exact same volume on the exact same host.

     

    So the repair, until it happens again, is to identify--or edit or add, for that matter--the volume_table.id values for both the correct and incorrect the correct volume_table.serial rows. (volume_table.serial matches volume_table.description for volume_table.type="network_drive" rows, but the serial field value is what shows in the Organizer Folders View as tree view.) Then UPDATE media_table SET volume_id=[good volume_table.id] WHERE (volume_id=[bad volume_table.id] [OR volume_id=[another bad volume_table.id ...]); That's Access SQL, there might be slight changes if you are using the SQLite console and their SQL directly. (I used a more complex set of queries to make all my changes that started by finding all the variations of hostname for the same volume.)

     

    This leaves the wrong volume_table rows in the catalog with no related media_table rows, but they don't seem to matter. My catalog has volume_table rows that no media_table rows relate to going back to machines I haven't had for ten years or more.

     

    As always, keep a copy of the catalog.psedb file you start with in case something runs amok. If you are not familiar with databases in general or SQLite in specific, you probably shouldn't go there.

     

    I'm going to mark this as an answer, but it is only a temporary repair. What's broken is Photoshop Elements Organizer. Still. After many updates where this problem has not been fixed.

     

    Along the way, I found some other interesting things in my catalog including 669 media items in volume "no_drive" which appear to be valid media, all video files of multiple formats, that PSEO flagged as "damaged or in a format that cannot be included", "skipped because they are not supported...HEIF & HEVC media" or similar, on import. Not sure what to do with these in the catalog. But many other apps on the machine play these media with no problems. There are also 62 media items in volume serial "amoc:cloud_drive" that appear to be in media that was in this catalog a decade or more ago but was moved to its own catalog along with many other media that are not kruft in this catalog. Why the the kruft ones are still in this catalog, and what "amoc:cloud_drive" is, remain mysteries.

     

    The volume that had all the problem media_table rows updated to relate to now has related 84775 media_table rows.

     

    I also edited the volume_table.serial and volume_table.description for that one oddball volume shown in mixed case in the View as tree screenshots above to all upper case.

    3 replies

    D
    Dick WAuthorCorrect answer
    Inspiring
    February 29, 2024

    Once again, I resorted to hacking in the catalog.psedb SQLite file to, for now, repair this. I used a SQLite ODBC driver and MS Access to make it easier.

     

    Adobe PSE Organizer stores a volume_table and and a media_table. media_table rows have a volume_id column that is a foreign key to volume_table.id.

     

    The problem is that Adobe PSE Organizer stores //SMBHOST/photo, //SMBhost/photo, //smbhost/photo, etc, all as separate and distinct volume_table rows even though they are the exact same volume on the exact same host.

     

    So the repair, until it happens again, is to identify--or edit or add, for that matter--the volume_table.id values for both the correct and incorrect the correct volume_table.serial rows. (volume_table.serial matches volume_table.description for volume_table.type="network_drive" rows, but the serial field value is what shows in the Organizer Folders View as tree view.) Then UPDATE media_table SET volume_id=[good volume_table.id] WHERE (volume_id=[bad volume_table.id] [OR volume_id=[another bad volume_table.id ...]); That's Access SQL, there might be slight changes if you are using the SQLite console and their SQL directly. (I used a more complex set of queries to make all my changes that started by finding all the variations of hostname for the same volume.)

     

    This leaves the wrong volume_table rows in the catalog with no related media_table rows, but they don't seem to matter. My catalog has volume_table rows that no media_table rows relate to going back to machines I haven't had for ten years or more.

     

    As always, keep a copy of the catalog.psedb file you start with in case something runs amok. If you are not familiar with databases in general or SQLite in specific, you probably shouldn't go there.

     

    I'm going to mark this as an answer, but it is only a temporary repair. What's broken is Photoshop Elements Organizer. Still. After many updates where this problem has not been fixed.

     

    Along the way, I found some other interesting things in my catalog including 669 media items in volume "no_drive" which appear to be valid media, all video files of multiple formats, that PSEO flagged as "damaged or in a format that cannot be included", "skipped because they are not supported...HEIF & HEVC media" or similar, on import. Not sure what to do with these in the catalog. But many other apps on the machine play these media with no problems. There are also 62 media items in volume serial "amoc:cloud_drive" that appear to be in media that was in this catalog a decade or more ago but was moved to its own catalog along with many other media that are not kruft in this catalog. Why the the kruft ones are still in this catalog, and what "amoc:cloud_drive" is, remain mysteries.

     

    The volume that had all the problem media_table rows updated to relate to now has related 84775 media_table rows.

     

    I also edited the volume_table.serial and volume_table.description for that one oddball volume shown in mixed case in the View as tree screenshots above to all upper case.

    MichelBParis
    MichelBParis
    Legend
    February 22, 2024

    "Somehow, Organizer thinks the same NAS folder(s) is (are) multiple different folders depending on case variations (UPPER, lower, Mixed) of the path."

    Yes, the organizer MUST recognize case information because the paths recorded in the database must keep that information to retrieve and access the file in the OS (Windows, I don't know about Macs).

    Once the information has travelled between NAS units with a protocol removing that case information, how do you think the organizer can find the real location on your original drive ?

     

    Other similar discussion:

    https://community.adobe.com/t5/photoshop-elements-discussions/elements-15-can-not-get-a-connect-to-the-nas/m-p/8854854

    D
    Dick WAuthor
    Inspiring
    February 22, 2024

    Thanks for the reply, but I can't make sense of what you are saying.

     

    The issue is not one of connectivity to the NAS--that seems to be the thrust of the "similar" thread you cite. The issue is that, while keeping track of the path to the image--which, yeah, of course it has to do--it treats those paths as case-sensitive. No path in Windows/SMB or MacOS/SMB is case-sensitive.

     

    c:\users\me\pictures\dsc0001.jpg is THE EXACT SAME PATH, functionally, as C:\USERS\ME\PICTURES\DSC0001.JPG. \\DS218PLUS\photo\ours\misc 2024\dsc0001.jpg is also the exact same path, functionally, as \\ds218plus\..., as \\DS218plus\..., etc.

     

    Yet, for reasons I still don't understand after reading your reply, Organizer treats them, incompletely, as somehow paths to different places.

     

    As shown in my screenshots in the OP, Organizer has stored the paths to two different cataloged images in that reside in the EXACT SAME folder as:

    \\DS218PLUS\photo\ours\misc 2024\DSC04232.JPG

    and

    \\ds218plus\photo\ours\misc 2024\DSC01917.JPG

    Ok, whatever. I don't care how they *store* it. The problem comes in when I look at "View Folder as tree" or "View folder as list".

     

    What I think you are saying suggests to me that they should show two separate "Network" roots in the tree view, \\DS218PLUS\photo\ and \\ds218plus\photo\, with the first able to drill down to DSC04232.JPG and the second root able to drill down to DSC01917.JPG. They do not. They only show "\\DS218PLUS\photo\" and not ""\\ds218plus\photo\" and not "\\DS218plus\photo" or any of the other case variants they've stored as paths to individual images. "View as tree" provides *no way* to traverse down a folder path to get to image \\ds218plus\...\DSC01917.jpg. "View as list", however, shows two "different" end-node folders, "misc 2024" and "misc 2024", each with its unique subset of the images store in that one folder.

     

    Note that they even show these singular network roots in mixed case:

    Anything it has recorded as stored in \\ds218plus\home\..., or \\DS218PLUS\home\..., or \\ds218plus\photo\..., or \\DS218plus\photo\..., etc, is unreachable in this folder view. They're not unreachable because of connectivity problems. When I'm in "View as list" I can get to both images just fine because it shows two separate "misc 2024" folders. The variants roots are unreachable because Organizer shows the roots as though they are case insensitive (only one case variant shown, even if showing the same SMB host in oddly different case) but doesn't traverse down through the mixed case paths they have stored starting case-insensitively.

    Greg_S.
    Community Expert
    Greg_S.Community Expert
    Community Expert
    February 21, 2024

    Adobe has never recommended the use of a NAS for the Organizer's storage.  In your case, I suspect that the problem revolves around your use of an SMB file system rather than NFS.  If that is the case, and as you have already found, it is highly unlikely that Adobe Elements would address such an issue.  Yours is the first complaint I have ever seen about it, and while I consider myself reasonably computer-literate, I had to Google what SMB is.

      D
      Dick WAuthor
      Inspiring
      February 21, 2024

      Of course Adobe never recommended it. So what? It's not like the platforms people use the product on are not networked these days.

       

      SMB is the standard network filesystem for Windows--from the jump decades ago--and, for the last four or five years at least, MacOS.  I suspect 100:1 the files that people are using Organizer with over a network are using SMB not NFS. That guess might be orders of magnitude low since Organizer does not exist for Linux and Linux clients and servers are the only place likely to be all NFS--and even many of those environments use SMB (Samba) for interoperability reasons.

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices