Running Windows 10 Pro.

I am trying to work around the 260 character MAX_PATH limitation native to the Win32 API.

I have created a series of backups, which we'll say are designed to back up "TRUNCATED" filenames.

For example, we'll reference a file with the full filename:

D:/Folder1/Folder2/Folder3/Folder4/Folder5/Folder6/Folder7/Folder8/Folder9/file.txt

To start, I have theoretically shortened this filename by means of moving the file into a hidden folder Short_Name closer to the root, such that the file would now LITERALLY exist as

D:/Short_Name/Folder9/file.txt

However, in order to keep my original file structure intact, such that I can re-use this tactic to perform the same path shortening elsewhere, but still use the same configuration files and software to perform file duplication and synchronization WITHIN the original folder(s)

( such as D:/Folder1/.../Folder9/ )

I have included a symbolic link named "Folder9"

( achieved using C:\Windows\system32> mklink /J ( or /D ) "D:/Folder1/.../Folder9/" "D:/Short_Name/Folder9/" in the command prompt )

within

D:/Folder1/Folder2/Folder3/Folder4/Folder5/Folder6/Folder7/Folder8/

such that the link looks like

D:/Folder1/.../Folder9/

but points to D:/Short_Name/Folder9/.

NOW, obviously, I could instead have used a regular, run-of-the-mill

Right-click > "Create Shortcut"

but the link target pathname of such a symbolic link would be absolute.

( i.e. A shortcut on D: pointing to D:/Short_Name/Folder9/file.txt would get copied to C: but the copied shortcut duplicate on C: would still point to D:/Short_Name/Folder9/file.txt. )

Symbolic links, on the other hand...

(i.e. the ones created via C:\Windows\system32> mklink ... )

... copy relative links over no problem...

( i.e. D:/Folder1/.../Folder9/ would be copied as C:/Folder1/.../Folder9/ )

... and the link target would copy from

D:/Short_Name/Folder9/

to

C:/Short_Name/Folder9/

... BUT --

The problem HERE is that NOW the LITERAL filenames are STILL INTERPRETED as their longer, UN-TRUNCATED versions, which would NOT occur by using the

Right-click > "Create Shortcut"

method.

As far as I can tell, when using mklink to create a symbolic link to a directory ( NOT a file - I do not know if it works differently for files ) , the LITERAL system filename of any file housed within a directory such as D:/Short_Name/Folder9/ seems only ever to be the entirety of the mklink symbolic path, i.e., namely that of

D:/Folder1/Folder2/Folder3/Folder4/Folder5/Folder6/Folder7/Folder8/Folder9/file.txt

even if the ACTUAL location of the file is only

D:/Short_Name/Folder9/file.txt.

QUESTION:

Is there ANY way of creating a symbolic link which will function as a standard folder, but which will ALSO maintain the RELATIVE, LITERAL, TRUNCATED version of a filename when copied to a new drive?

Please and thank you.

  • I don't really get what your problem is. But you might want to read Naming Files, Paths, and Namespaces which has specifics on how to work with paths that are longer. In addition the obvious and easy solution would be to shorten the paths or use software that is able to work with those paths. An example would be to not use Explorer but something like Total Commander. Furthermore there is a heavy difference between using mklink with the options /J and /D. – Seth Apr 12 '17 at 6:09
  • 1
    the 260 MAX_PATH limit is not related to NTFS. It's just the limit of the old Win32 API. Windows NT has support 32767-character path for a very long time, and Windows 10 also support longer paths – phuclv Apr 12 '17 at 7:46
  • @Seth, the difference here is between shortening 1,000+ file names individually and just shortening the longer directory via a symbolic link. Yes, /J and /D are different, but the ISSUE I'm having remains the same, regardless of whether it is a junction or a soft link. I am aware of alternative file explorers. But I want NATIVE Win32 API support because that is the environment in which most 3rd-party developers develop their applications; switching methods I use to browse files does not guarantee the 1,000+ files I have will remain viable for their respective applications. – Stephen Hanson Apr 12 '17 at 15:50
  • @LưuVĩnhPhúc Thank you for correcting me on the point of Win32; I have updated the original post, accordingly. – Stephen Hanson Apr 12 '17 at 15:57
  • @LưuVĩnhPhúc With respect to the compatibility of Windows 10 as it relates to longer file names, while I am sure that I could disable the setting which currently disallows filenames greater than 260 characters, I am worried that doing so would cause application instability. Is there a way to confirm one way or another how manipulating the MAX_PATH setting would affect the ability of certain applications to make use of the affected files? – Stephen Hanson Apr 12 '17 at 16:01

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.