Long path name issue

[ExpertNovice]

I had no idea where to turn for this question so, here I am.

I am aware of the long path name issue but came across a situation where the same file has an issue on a HDD but not a USB drive.

Easiest tests to see the oddities are (1) right-click the file to get to the properties dialog box and (2) right click a higher folder to see if the file properties are included in the properties detail.

Both tests fail on the HDD where the path/filename length is 262. The surprise is on the USB backup drive where there are no issues even though the length is 295 bytes.

I thought the 260 byte limit was absolute so what happened. (I also know the 260 byte limit is a theoretical max that can't actually be reached for various reasons including the null terminator.)

Drive D (SATA drive, NTFS format)
Full path and filename length is 262 bytes and the tests fail. Shorten the folder name and all is well.

Drive O (Seagate 4 TB USB drive, NTFS format)
Full path and filename length is 295 bytes and both tests work and return correct results. File copied by Cobian Backup 11 which inserts "Rog\D 2016-11-17 14;15;49 (Full)\" after the drive letter.

Neither drive has LongPathsEnabled enabled (based on the registry assuming what I found is correct) or 8.3 disabled (verified using FSUTIL_
Any ideas?

 

[ExpertNovice]

Additional weirdness

On the USB drive, the first portion of the folder structure is "O:\Rog\D 2016-11-17 14;15;49 (Full)\JJO (From M6500, already merged)\"

Properties of O:\Rog\D 2016-11-17 14;15;49 (Full)
returns 325 GB

Change "D 2016-11-17 14;15;49 (Full)" to "D"; Path reduced by 27 bytes.
Properties of O:\Rog\D
returns 340 GB

Change "JJO (From M6500, already merged)" to "J"; Path reduced by another 31 bytes.
Properties of O:\Rog\D
returns 325 GB

I would have thought the size would remain at 340 or increase, NOT decrease.

 

[ExpertNovice]

A couple of items that may be of help to others to find long path names
The following command will find the first path whose full path is over 247.
dir /s "c:\folder1\folder" 1>nul 2>BadFolder.txt
However, the following command should be used. It will SOMETIMES report a folder that is under the 247 byte limit but contains a file that exceeds the 247 byte limit.
dir /s "\\?\c:\folder1\folder" 1>nul 2>BadFolder.txt

Of course, neither will report subfolders subordinate to a reported folder.

There seem to be two limits.
First, the limit, in my test, to a long path size that can be created working top down is 247 bytes. This seems correct. 247 + 12 + 1 = 260. (12 bytes to hold the 8.3 file name and 1 byte for the null terminator.)

However, if created from bottom up the directory command SOMETIMES has no issues finding folders up to a maximum of 329 bytes (330 if the null terminator is considered).

Final weirdness:
264 bytes. Reported only using \\?\
O:\Rog\D 2016-11-17 14;15;49 (Full)\JJO (From M6500, already merged)\!done\Computer (D)\!Done\Seagate\Drive Specific Info\Returned_or_Decommissioned\NA0M5ZHK\Seagate installed files and folders\Seagate (root folder)\SeagateDashboard\Products\Microsoft Redistribute

258 bytes reported using either format
O:\Rog\D 2016-11-17 14;15;49 (Full)\JJO (From M6500, already merged)\!done\Computer (D)\!Done\Seagate\Drive Specific Info\NA0JENL5 - WBC bkp (W) -(long generic fail)\Seagate installed files and folders\Seagate\SeagateDashboard\Products\Microsoft Redistribute

256 bytes, reported only using \\?\. Reducing by 1 byte and it is not reported, even though it contains a file name that is 57 bytes long increasing the full path size from 255 to 313 bytes.
D:\Test\a1234567\a really long folder name to increase maximum size of FQDSN\a really long folder name to increase maximum size of FQDSN\a really long folder name to increase maximum size of FQDSN\a really long folder name to increase maximum size of FQDSN

Hopefully, this will help someone even though it doesn't answer my original question.

FYI: The original folder structure came from another computer and was copied to the new computer and left while reorganizing. The issue came to light when Cobian Backup was used further increasing the depth. In all, about 100 bytes of path sizes were added. =0. All folders have been appropriately dealt with.

 

[johnbl]

NTFS can use a much longer path limit than 260 chars,
The old limit was placed in the user interface to attempt to maintain interoperability with other versions of Microsoft operating systems(DOS, windows, MSnet versions, early lanman versions, OS/2) and installable file systems back in the early days of NT. The limit was not placed in the actual NTFS. You could always exceed the limit if you made the directory with a foreign OS like unix.
(it would then mess up the windows backup programs, unix could also make files that were not allowed on windows, like null.txt, con.txt, aux.txt, prn.txt these would also mess up when people attempted to use the windows apps on the files.)

I had no idea where to turn for this question so, here I am.

I am aware of the long path name issue but came across a situation where the same file has an issue on a HDD but not a USB drive.

Easiest tests to see the oddities are (1) right-click the file to get to the properties dialog box and (2) right click a higher folder to see if the file properties are included in the properties detail.

Both tests fail on the HDD where the path/filename length is 262. The surprise is on the USB backup drive where there are no issues even though the length is 295 bytes.

I thought the 260 byte limit was absolute so what happened. (I also know the 260 byte limit is a theoretical max that can't actually be reached for various reasons including the null terminator.)

Drive D (SATA drive, NTFS format)
Full path and filename length is 262 bytes and the tests fail. Shorten the folder name and all is well.

Drive O (Seagate 4 TB USB drive, NTFS format)
Full path and filename length is 295 bytes and both tests work and return correct results. File copied by Cobian Backup 11 which inserts "Rog\D 2016-11-17 14;15;49 (Full)\" after the drive letter.

Neither drive has LongPathsEnabled enabled (based on the registry assuming what I found is correct) or 8.3 disabled (verified using FSUTIL_
Any ideas?