Symlinks fail to create properly when target path is over 254 characters long (Windows)

[MD2K23]

This is an Operating system limitation - when a path is over a certain length, which is supposed to be 260, but I believe it to be 254 from my own tests, it will use \?\ in front of the path name to allow it to exceed the character limit, but this does not appear to be compatible with os.Symlink because while it does create a symlink in the downloads folder, it does not actually link anywhere.

Neither mklink or PowerShell can create a working symlink with a path that exceeds the limit.

If there's no way to get around this limitation with the symbolic link creation itself, could you perhaps do a workaround and have the program just use an incrementing number for the folder names in the webdav mount like you do with the .nzbs folder, instead of duplicating the name of the file?

[MD2K23]

I created a rudimentary workaround by adding this inside CreatNzbFolder in utils.go

// Truncate folder name if it would cause Windows MAX_PATH issues
	// Keep first 80 chars to stay well within limits
	if runtime.GOOS == "windows" && len(nzbBaseName) > 80 {
		nzbBaseName = nzbBaseName[:80]
	}

and this in processor.go

// Ensure we don't put the file directly into a category root folder
	// We MUST create a release folder so Sonarr/Radarr can find the "Job Folder"
	if proc.isCategoryFolder(virtualDir, category) {
		if runtime.GOOS == "windows" && len(releaseName) > 80 {
			releaseName = releaseName[:80]
		}
		virtualDir = filepath.Join(virtualDir, releaseName)
		virtualDir = strings.ReplaceAll(virtualDir, string(filepath.Separator), "/")

	}

and in aggregator.go - because Windows wasn't matching the subfolder path to the root path so never collapsing it.

virtualDirBase := path.Base(virtualDir)
//virtualDirBase := filepath.Base(virtualDir)

[javi11]

Can we just cut the filename? I believe the path limitation is over the filename, not over the entire path

[MD2K23]

Yes i suppose it doesn't matter what gets trimmed as long as the resultant path is under 254, which of course includes the absolute mount path, which could be any length, so perhaps it's worth trimming on both folder and filename, using an algorithm to detect how long the resultant filename path will be to work out how much to trim. I did the folder so I didn't accidentally trim the file extension off the filename, but I'm not familiar with your code, or golang particularly so I am sure you can achieve a better result.

[iPromKnight]

this limitation only exists today because of old win32 apps
I wish microsoft would pull a finger out of their a... and actually enable them by default, as its no longer 1999...

You can reg patch to do it: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

You can also just run altmount under wsl 😸

[MD2K23]

this limitation only exists today because of old win32 apps I wish microsoft would pull a finger out of their a... and actually enable them by default, as its no longer 1999...

You can reg patch to do it: https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

You can also just run altmount under wsl 😸

The reg path allows long paths to be accessed via \ \?\D:<path> for example, but Symlinks can't be created using those paths, they just translate them back to absolute paths and then don't create properly.

[iPromKnight]

Yeah you are right, and the app has to be longpath aware which i just did in PR #610
However it "may" require dev mode as if memory serves SeCreateSymbolicLinkPrivilege is required with CreateSymbolicLinkW

#610 addreses Go's os.Open, os.Stat, os.Symlink, etc. so they all work with long paths

It may require you running altmount as admin, unless you explicitly allow symlinks with secpol.msc too

[javi11]

fixed here #610