Mac Read Windows Path

[JRMMusic]

I've just moved from Windows to Mac. Windows paths look different than Mac. So Kontakt Libraries (loaded via the browser, not licensed via Native Access), custom HALion presets, track presets in Cubase are all looking for a Windows path like "S:/Samples/[library]/samples..." while the location on Mac would be "Samples/[library]/samples...".
I knew this would be a problem going into it. But it is a huge task to load up each presets and resave to the new path.

Is there a solution to this or a trick anyone used when transition between operating systems? I have so many libraries in use this way and track presets saved in cubase looking for a particular path.

Thanks in advance!

[kidslow]

I'm afraid you may not find a solution other than manually changing them. It is a fundamental system difference between the OSes. You also face the real potential that the \ and / are reversed between Win and Mac for file paths.

If you could find the files where such presets are stored, and they are stored in plaintext, you could run a script to automate conversion by reading in the file and converting old path to new path and writing back to the file. That type of task is very well known and possible. On unix (macos) a tool like awk or sed is indispensable for such things, but also could be done in perl or python and examples abound for any of these. But how much time do you want to spend on this?

Why do you have to convert everything all at once? It would become a sequence of much smaller tasks if you were to convert them on an as-needed basis as you require the old presets.

[BONES]

This doesn't sound right, Macs "just work", don't they? Perhaps the unicorns and rainbows are obscuring the paths?

[kidslow]

Given that MacOS uses the Unix path model, which predates Windows or MSDOS, clearly it is Windows that is broken & went about doing it wrong.

[sQeetz]

Given that MacOS uses the Unix path model, which predates Windows or MSDOS, clearly it is Windows that is broken & went about doing it wrong.

It truly is the only OS using backslashes. No one else does it that way

[chk071]

It has (obviously) technical reasons: https://learn.microsoft.com/en-us/archi ... -character

[sQeetz]

It has (obviously) technical reasons: https://learn.microsoft.com/en-us/archi ... -character

Nice to know... still, though, nonetheless, andsoforth,....wrong by *ANY* other OS

[BertKoor]

Not relevant. DOS / Windows is not any of those other OSses. So sure enough specifying a file path with one convention does not work on the other. Has anyone ever suggested it should?

The core problem though is not backslash or forward slash. At the windows api level these can both be used. It's the drive letter and colon which gets in the way and breaks compatibility.

[uOpt]

Windows accepts / as a replacement for \ just fine, except on the commandline I think.

[kidslow]

It's the drive letter and colon which gets in the way and breaks compatibility.

Yes, that's the fundamental problem. I would imagine something like Cygwin long ago found a work around to map drive letters A: - Z: to /dev/x when using their tools. I doubt Kontakt is going to be able to use third-party work arounds though, so unless those paths are stored in a text file and you can programmatically do a search and replace for a regular expression of e.g. S:\Samples\some\directory to /Volumes/Samples/some/other/directory, I don't see any solution that doesn't involve manually changing the stored path presets.

[jdnz]

Windows accepts / as a replacement for \ just fine, except on the commandline I think.

correct - and also if you use DOS device paths to get similar behaviour to the /Volumes directory on MacOS : https://learn.microsoft.com/en-us/dotne ... th-formats

unfortunately most programs still use traditional DOS paths instead

[uOpt]

Also, the colon is a normal character in Unix pathnames. "S:" is a valid directory name in Unix.

So sometimes you can make a hardcoded path "s:/foo/bar" work by `mkdir -p s:/foo/bar` in the working directory and then symlinking something inside bar.