Metadata availability dependent on path length?

The attached archive contains three different screenshots of mouse-hover display of thumbnail and metadata for the same metadata-populated PNG file, but in three different locations on the same hard drive. As seen in the screenshots, varying amounts of existing metadata are displayed. Some specifics:

“2020-08-05 13;32;21 - MAZE - DOpus PNG Hover.png”

• Path (59) + filename (65) = 124; Original location of file next one below was copied from
• ALL metadata displayed during mouse-hover, AND in Set Metadata panel

“2020-08-05 13;30;34 - MAZE - DOpus PNG Hover.png”

• Path (200) + filename (65) = 265 characters; Location of file last one below was copied from
• NO metadata displayed during mouse-hover, NOR in Set Metadata panel

“2020-08-05 13;33;48 - MAZE - DOpus PNG Hover.png”

• Path (35) + filename (65) = 100
• Only camera metadata displayed during mouse-hover; All metadata except Comment displayed in Set Metadata panel

Known path length limitation(s) or bug(s)? Couldn’t find anything about it in quick search of help. ExifTool seems to confirm that all expected metadata exists in third file (13;33;48), but I’m unable to run it in location of second file (13;30;34), presumably due to its own path length limitation (haven’t confirmed that yet).

Note that I have read this post, in which another user was attempting to deal with metadata for files with path > 260. What I don’t get is why all the metadata doesn’t become visible again after copying to a shorter path.

Attached: “2020-08-05 - MAZE - DOpus PNG Hover.7z” (280,844)

Contents:

“2020-08-05 - MAZE - DOpus PNG Hover\”
“2020-08-05 13;30;34 - MAZE - DOpus PNG Hover.png” (76,051) [583 x 190 x 24]
“2020-08-05 13;32;21 - MAZE - DOpus PNG Hover.png” (135,223) [1079 x 317 x 24]
“2020-08-05 13;33;48 - MAZE - DOpus PNG Hover.png” (80,543) [654 x 426 x 24]

A lot of things throughout Windows, including parts of the OS itself, will not work with paths greater than 260 characters

We aim to guarantee that basic operations (copy, move, rename, delete without recycle bin*) work with arbitrary path lengths, but that is about all we can guarantee, as we cannot control all the APIs and libraries made by other people, many of which we don't even have the source code to. We don't consider this a bug, unless it affects basic operations. (The basic operations need to work since otherwise you have no way to tidy up things with long paths.)

(*The recycle bin API is one of the things in Windows which does not work with long paths. It's not just obscure things; it's fundamental things, even after Microsoft's claims to have improved things in this regard. Add in third party libraries and the issue is probably always going to be present on Windows.)

If you have paths that long, the first thing you should to is shorten them. You will run into other problems with them, not just this one. If something else is forcing a directory structure with paths longer than 260 characters, and there's no way to reason with the developers who are doing that, then you could use softlinks or junctions to create alternative, shorter paths to the same things.

Yes, noted. But the other interesting symptom here was that the file in question would not display its metadata properly even after it had been copied to a location with path < 260. I understand that whatever code is used for that may not be your own, but can the details of this symptom be passed on to the actual owners/developers of the code?

And, I forgot to attach the file: 2020-08-05 - MAZE - DOpus PNG Hover.7z (274.3 KB)

Are you sure the path length is actually the issue here?

It sounds more like the files just have different data in them. Or maybe the thing which set the data did different things to each file (possibly due to path length, possibly due to something else).

I'm not sure exactly what I'm meant to look for in the zip file. I see three different files with different metadata in them.

If you're expecting the infotips to display the same thing as the metadata panel, they won't by default. Infotips don't display as much by default. You can configure them via Settings > File Types and the Images file type group to change which fields are displayed.

(PNG files don't usually have much camera metadata at all, FWIW.)

As far as I can tell, it is at least a factor.

The files I was having problems with are all exactly the same, or should be, anyway. File in location A (full path = 124) was copied to location B (full path = 265), where I noticed it wouldn’t display its metadata at all. I then copied it from location B to location C (full path = 100). All of this information was in my first post. In all three locations, the file has the same filename and size.

The files in the zip are just screenshots of the mouse-hover infotips displayed for that same file in the three different locations. Each displays different amounts of metadata. I guess we’ve firmly established at this point that the infotip for location B (path = 265), which only displays the thumbnail but no metadata, is due to the path length. But the infotip for location C (path = 100) fails to display the Comment, which is also curiously empty when I open the Set Metadata panel on it in that location.

FYI, I’ve also tried copying the PNG directly from location A to location C, in which case it correctly displays all metadata in the infotip and in Set Metadata.

Yes, I’m aware. It usually displays the comment, if there is one, and a handful of the camera fields.

This particular PNG does, because it was converted by DOpus from a camera-produced JPEG.

The files in the 7z archive are not the same. They aren't even the same size.

The files in the 7z archive are screenshots of three separate mouse-hovers over the one file, with same name and filesize and metadata, though in three different locations on my hard drive. The screenshots are different from each other. The file they show mouse-hovers over is the same, but in different locations.

I understand now. I thought they were sample images which could be used to reproduce the problem.

We'd need some of those to tell you anything, since we can only makes guesses based on screenshots without some real files/tags to inspect.

Unfortunately, I’m not authorized to share the image in question, which was provided by someone else and contains personal information. I tried reproducing the conditions with a different file, but failed to get the same results, other than no metadata visible when path was > 260. I’ll be in touch if I find another example I can share.

FYI, this reminds me of this issue that I brought up a few years back.

Ok, I’ve managed to create an elaborate working example I can share. The attached 7-zip contains a mock-up of my full hierarchy of folders from root, so it should be extracted in the root of a volume to create conditions identical to my use case. The same set of PNG files exists in all three relevant locations [A, B, C] within the archive.

As specified in my previous post, I had copied a file from A to B, saw that metadata wasn’t being displayed in the infotip, then copied the file from B to C, where I found that Comment was MIA, both in the infotip and the Set Metadata panel, but all other metadata appeared to be present and accounted for.

Yesterday’s attempt to create a shareable PNG which exhibited these same symptoms was unsuccessful, in that when I copied it from B to C, the Comment was displayed the way it should be, not MIA. After some additional experimentation, I found that the fate of their Comments going missing is not suffered by all files copied in the same way. Out of the 13 PNGs included in the attached archive, four of them continued to display their Comment after being copied from B to C, while the rest of the files’ Comments were MIA.

Also, I found that when I copied the 7-zip to another volume’s root and extracted it there, all the same files’ Comments in location C remained MIA, which took me by surprise. And, same results when I copied the 7-zip (via Google Drive upload/download) to the root folder of a volume on my other laptop and extracted it there (this laptop is Windows 7, other one is Windows 10).

Attached: “Metadata&Path_Length_Test.7z” (49,082)

Contents:

“Test1\”
  “Test\”
    “Downloads\”
      “Temporary1\”
        [Location C]
        “2020-06-10 13;56;17 - Smith, Jones - Temp Photo Book - A1.png” (10,037) [1 x 1 x 1]
        “2020-06-10 13;58;17 - Smith, Jones - Temp Photo Book - B01.png” (8,474) [1 x 1 x 1]
        “2020-06-10 13;58;25 - Smith, Jones - Temp Photo Book - B02+03.png” (12,892) [1 x 1 x 1]
        “2020-06-10 13;58;30 - Smith, Jones - Temp Photo Book - B04+05.png” (10,742) [1 x 1 x 1]
        “2020-06-10 13;58;36 - Smith, Jones - Temp Photo Book - B06+07.png” (9,654) [1 x 1 x 1]
        “2020-06-10 13;58;41 - Smith, Jones - Temp Photo Book - B08+09.png” (9,813) [1 x 1 x 1]
        “2020-06-10 13;58;46 - Smith, Jones - Temp Photo Book - B10+11.png” (10,096) [1 x 1 x 1]
        “2020-06-10 13;58;50 - Smith, Jones - Temp Photo Book - B12+13.png” (9,815) [1 x 1 x 1]
        “2020-06-10 13;58;58 - Smith, Jones - Temp Photo Book - B14+15.png” (9,844) [1 x 1 x 1]
        “2020-06-10 13;59;03 - Smith, Jones - Temp Photo Book - B16+17.png” (8,869) [1 x 1 x 1]
        “2020-06-10 13;59;12 - Smith, Jones - Temp Photo Book - B18+19.png” (10,669) [1 x 1 x 1]
        “2020-06-10 13;59;20 - Smith, Jones - Temp Photo Book - B20.png” (8,810) [1 x 1 x 1]
        “2020-06-10 16;52;47 - Smith, Jones - Temp Photo Book - B20a.png” (8,883) [1 x 1 x 1]
        “Smith, Jones\”
          “Archive\”
            “2020-08-05\”
              “2020-08-05 13;46;49 - Smith, Jones - [0] Photo Book Retry pp10-15\”
                “PNG\”
                  “2020-06-10 16;52;47 - Smith, Jones - Temp Photo Book - A1-B20a\”
                    [Location B: All PNG files as above]
          “Photos\”
            “PNG\”
              [Location A: All PNG files as above]

Metadata&PathLengthTest.7z (47.9 KB)

Am I understanding correctly? It sounds like the issue is that the comments aren't being set on files which have excessively long paths.

If they are then moved somewhere else, it won't matter, as the comment doesn't exist on the file.

Or is there more to it than that?

Negative. Comments, along with a multitude of other metadata fields, were already set on ALL PNGs, while they resided in location A. Then the files were copied to B, where no metadata was visible. Then they were copied from B to C, where Comments appear to have disappeared, but all other metadata was intact. But all PNGs in C have file sizes identical to their counterparts in A and B, so the Comments should still be there, and ExifTool confirms that they are.

Looking at the archive, the files in each location all identical (to their respective copies) at the binary level.

The ones in the longest paths are not showing as much metadata, which makes sense (the paths are too long; the involved APIs/libraries won't work on them).

Ignoring duplicates, only three of the files appear to have descriptions at all, at any path length. Is that the same for you? If not, you may have descriptions stored in NTFS ADS, outside the main file data, which would be lost when archiving the files. Those NTFS ADS comments could also be lost when copying the files from extremely long paths (I'm not sure off the top of my head), which might be what's happening.

At the end of the day, the advice is still the same: Avoid excessively long paths. Windows APIs and many libraries will not work on them. They will cause you problems. Just avoid them, and only assume basic file operations will succeed on them as it's all that can be guaranteed.

That’s not correct. All of the files, in all three locations, have comments/descriptions/etc. This is easily verifiable using ExifTool, though ExifTool likewise can’t be used directly in location B (path = roughly 265). But as you acknowledge, the three sets of file copies are bit-identical, so if the comments/descriptions live in all files in locations A and C, they also do in location C — but Directory Opus isn’t displaying them for all files.

However, I hadn’t thought previously to verify comments/descriptions visibility in location A files as extracted from the 7-zip until your recent post, and can now verify ALMOST the same for me as you seem to be indicating: only four of the files in locations A and C are displaying their comments. In their original incarnations on my hard drive, which were used to create the 7-zip, ALL files in location A display their comments.

If I do, I have no idea how they could have gotten there. I used Directory Opus’ Set Metadata panel, or custom SetAttr META commands, to write the bulk of the metadata, including comments/descriptions, in the copy of files in location A. Would Directory Opus ever write comments/descriptions to ADS for PNG files under any circumstances? I don’t believe ExifTool even deals with ADS at all, ever.

Noted, and it’s certainly worthwhile advice. In my case, I don’t normally think of it until there’s some anomaly, and then I have an “Oh, yeah, duh!” moment. But I wouldn’t have expected comments to vanish from files inadvertently stored in an excessively long path even after they were subsequently moved or copied elsewhere. Thankfully, in this case, I still have the original copies in location A.