NAS file locations inconsistent in Organizer

[DenFen]

I'm having an issue with my photos showing up under different paths in the organizer, depending on where they were originally scanned versus moving them and choosing a new location.

If I scan files on my NAS, they show up under the assigned drive letter and associated path, for example: T:\Image Libary 2021\...

If instead of scanning them on the NAS, I move files from a local drive to the NAS, and then I "choose new location", they show up under the NAS name and not the drive letter, for example: \NAS2\Image Library 5\Image Library 2021\...

Is there something I should be doing so they always show up under the same path in the organizer, regardless of scanning them there originally, or moving them and using the "choose new location" option?

I'm on Windows, PM Plus 6 Build 5724.  This was happening in prior builds too.

Thanks.

[Kirk Baker]

I'm having an issue with my photos showing up under different paths in the organizer, depending on where they were originally scanned versus moving them and choosing a new location.

If I scan files on my NAS, they show up under the assigned drive letter and associated path, for example: T:\Image Libary 2021\...

If instead of scanning them on the NAS, I move files from a local drive to the NAS, and then I "choose new location", they show up under the NAS name and not the drive letter, for example: \NAS2\Image Library 5\Image Library 2021\...

Is there something I should be doing so they always show up under the same path in the organizer, regardless of scanning them there originally, or moving them and using the "choose new location" option?

I'm on Windows, PM Plus 6 Build 5724.  This was happening in prior builds too.

That sounds like something we'll have to fix.  We'll look into the issue and see what can be done.

-Kirk

[DenFen]

Kirk, any update on getting this fixed?  There have been a bunch of releases since this post but the issue remains.  My catalog seems unorganized with some of the photos showing up under \\NAS2 and others under T:\ when they are really the same.

Thanks.

[Kirk Baker]

Kirk, any update on getting this fixed?  There have been a bunch of releases since this post but the issue remains.  My catalog seems unorganized with some of the photos showing up under \\NAS2 and others under T:\ when they are really the same.

No, no progress on the issue thus far.  The next build won't address the issue either.  I'll try and address it for the build after next.  Would you be willing to test any fixes that I make?

-Kirk

[DenFen]

Sure, I'd be happy to test the fix(es).  It is pretty quick to recreate.

Thanks.

[cbfaulkner]

Kirk,

I am having the same issue and look forward do the fix.  I would be willing to test the beta as well.

Cedric

[ejhutch]

I'm new to Photo Mechanic Plus, but this sounds to me like an issue where PM stores the path name for some images on your NAS using the UNC path (\\NAS2\...\...\...\Some Image Folder) and stores the path name using the Windows Drive Letter (T:\...\...\...\Some Image Folder) for others -- depending on how you got the images into or moved around in your catalog -- resulting in all images being actually stored under the correct directory structure on your NAS, but appearing in two different file paths in PM Plus.  Does that seem to be the behavior you're experiencing?

I wouldn't be surprised at all if this was what was happening. I used to experience it with plenty of other apps on various Windows flavored systems when mixing both Drive Letter path names and UNC path names.

Is there a way that you can do both operations with explicitly specifying the same path name convention for scanning to the catalog and for moving from the local drive to the catalog?  Try to make sure that either both operations use the UNC path name (\\NAS2\...\...) OR both operations use the Drive letter path name (T:\...\...). But don't use one path naming convention for scanning and a different path naming convention for moving files.

I'm not sure that this would be something that camera bits could fix without converting from one path name convention to the other and back because you could have the same UNC path simultaneously to multiple Drive Letters.  I would assume that the same behavior could happen on macOS or Linux if a user used symlinks or had the NAS volumes mounted multiple times in different locations. Perhaps shared folders might work to make PM recognize that they're both really in the same location? But I haven't used that yet, so I'm not sure.

Ever since Microsoft started reliably supporting UNC path names, I've always tried to prefer using them instead of drive letters for this reason.  Network Locations mapped to Drive Letters could get very confusing when some apps or devices used to automatically map the next available drive resulting in Drive Letters seeming to change randomly for the same Network Location.

Ed

[Kirk Baker]

I'm new to Photo Mechanic Plus, but this sounds to me like an issue where PM stores the path name for some images on your NAS using the UNC path (\\NAS2\...\...\...\Some Image Folder) and stores the path name using the Windows Drive Letter (T:\...\...\...\Some Image Folder) for others -- depending on how you got the images into or moved around in your catalog -- resulting in all images being actually stored under the correct directory structure on your NAS, but appearing in two different file paths in PM Plus.  Does that seem to be the behavior you're experiencing?

It's exactly what's happening.

I'm not sure that this would be something that camera bits could fix without converting from one path name convention to the other and back because you could have the same UNC path simultaneously to multiple Drive Letters.  I would assume that the same behavior could happen on macOS or Linux if a user used symlinks or had the NAS volumes mounted multiple times in different locations. Perhaps shared folders might work to make PM recognize that they're both really in the same location? But I haven't used that yet, so I'm not sure.

Ever since Microsoft started reliably supporting UNC path names, I've always tried to prefer using them instead of drive letters for this reason.  Network Locations mapped to Drive Letters could get very confusing when some apps or devices used to automatically map the next available drive resulting in Drive Letters seeming to change randomly for the same Network Location.

We need what we call a 'canonical path' which is a path without ambiguity.  Currently a path is run through some NT functions that resolve a path, including symlinks, to a final path.  If the path is a network share then it is converted to a UNC path--the drive letter is lost.

Currently there is an inconsistency as to when paths undergo this conversion and thus the problem.

I'm not sure if it's better to use a different method (when used consistently) that preserves the assigned drive letter or to do the conversion to UNC consistently.

I'm open to suggestions.

-Kirk

[cbfaulkner]

Kirk,

I think ideally if the user specifies a UNC path for the Catalog Scan that should persist without changing to a drive letter.  I suspect there would be a reason they chose a UNC over a drive letter.  And obviously if they chose a drive letter that should persist and not be changed to a UNC.


However, if I could only pick one of them I would say consistently use the UNC.  Imagine the following exaggerated folder structure.

\\Nas\Pictures\Client1
\\Nas\Pictures\Client2
\\Nas\Pictures\Canon Camera
\\Nas\Pictures\Nikon Camera
\\Nas\DataFromOldComputer\Pics\Vacation
\\Nas\DataFromOldComputer\Pics\ExcludeMe
\\Nas\Andy\Shooter1
\\Nas\Andy\Shooter2
\\Nas\Andy\CellPhonePics Exclude From S
\\Nas\FamilyArchivePics\Potential Delete Candidates Exclude From Scan
\\Nas\Child1\AndroidBackup
\\Nas\Child2\iphoneBackup

It would be frustrating to have to map a drive letter for each main shared folder.  And trying to remember which folder was assigned to one of 5 or 6 different drive letters sounds a little scary.

Those are my initial thoughts.

Cedric

[Kirk Baker]

Cedric,

I think ideally if the user specifies a UNC path for the Catalog Scan that should persist without changing to a drive letter.  I suspect there would be a reason they chose a UNC over a drive letter.  And obviously if they chose a drive letter that should persist and not be changed to a UNC.

However, if I could only pick one of them I would say consistently use the UNC.  Imagine the following exaggerated folder structure.

\\Nas\Pictures\Client1
\\Nas\Pictures\Client2
\\Nas\Pictures\Canon Camera
\\Nas\Pictures\Nikon Camera
\\Nas\DataFromOldComputer\Pics\Vacation
\\Nas\DataFromOldComputer\Pics\ExcludeMe
\\Nas\Andy\Shooter1
\\Nas\Andy\Shooter2
\\Nas\Andy\CellPhonePics Exclude From S
\\Nas\FamilyArchivePics\Potential Delete Candidates Exclude From Scan
\\Nas\Child1\AndroidBackup
\\Nas\Child2\iphoneBackup

It would be frustrating to have to map a drive letter for each main shared folder.  And trying to remember which folder was assigned to one of 5 or 6 different drive letters sounds a little scary.

Those are my initial thoughts.

It was never the case that a UNC path was converted to a drive letter.  It is the other way around: a drive letter would sometimes be converted to a UNC path and sometimes it would remain as a drive letter.

My thinking also aligns with yours.  If a UNC path is chosen, it should remain a UNC path.  If a drive letter path is chosen, it should remain a drive letter path.  But if we do that, then it would be possible for two different paths to refer to the same item(s).  If the drive letter path is on a share and items are cataloged that way and later the user uses a UNC path to add items to a catalog and they're the same item, that item will be represented in the catalog twice.

That problem could be significant once we add a feature to remove duplicates.  The paths differ, but the image is the same instance.  Deleting it from one location would delete it from both locations.  That would be catastrophic.

We may have to go all UNC or nothing.  I will think on this for a while.  I would like to hear others' thoughts in the meantime.

-Kirk

[DenFen]

The "all UNC" approach seems to make the most sense to me.  At least in my case, I change drive letter mapping on occasion, depending on different computer configurations.   Anything that makes the catalog consistent regardless of how it is added to the catalog will help.  It just seems like I'd run into fewer maintenance/update issues over the long-term using the UNC name rather than the drive letter.

[cbfaulkner]

The UNC path approach sounds good to me.

[ejhutch]

A quick and dirty google search led me to https://support.microsoft.com/en-us/topic/a-mapped-drive-network-location-is-changed-to-a-unc-path-when-you-trust-the-location-in-word-2007-or-word-2010-069a242f-7d3e-45aa-019e-664c09d8d126 (A mapped drive network location is changed to a UNC path when you trust the location in Word 2007 or Word 2010) on the Microsoft support site, and similar pages.

If you have a TechNet subscription, you might be able to find something there, but I suspect if Microsoft started doing internally converting drive letters to UNC names in 2007, then PM should probably consider that, too.

Or possibly if PM can identify when a user is using a network share mapped to a drive letter, warn the user with a dialog and recommend that they change it to UNC and possibly offer to do it for them. And strongly recommend to Windows users to start using UNC paths and not drive letters for remote shares.

Quite frankly, I was surprised that this issue wasn't been noticed years ago. Except for the fact that PM Plus is still relatively new.

I don't know off the top of my head how LR, CO, or other catalog software handles this, but a search should be pretty easy to determine how other folks do it.

There may still be use cases for supporting drive letters, so getting rid of them automatically may not be the most comprehensive solution.  But that's more of a business decision than a technical one.

[Kirk Baker]

Thanks for the feedback everyone.  I will make it so that mapped network drives are converted to UNC representation consistently throughout PM Plus.

It won't be in the next build, but I'll get test builds out to you and once the kinks are worked out, we'll put out another release.

-Kirk