This could be considered a bug, in that the parent directory of the file system root is not the root itself – filesystems are not infinitely recursive, so the result does not reflect the true filesystem structure. (Shouldn’t "/".dirname be an empty string, or nil? )
I had been checking for the top of the directory tree by path.dirname.includes(Platform.pathSeparator) but that no longer works.
It seems from the source that we are using a dirname function from somewhere else…? Why would they do this???
this is correct, or at least justifiable. this function in SC is based off POSIX dirname (https://linux.die.net/man/3/dirname), which is what’s called on macOS and Linux. Windows uses a handwritten solution that seems to do the same thing at a glance, but I don’t think it handles absolute Windows filesystem paths. I guess the documentation does say “unix style paths”.
/.. is actually a hard link to / on most if not all Unix systems (check the output of ls -ia /), and it is sometimes treated that way too in other POSIX-specified functions (linux - The parent of the root directory - Super User). i think the most helpful way to interpret dirname is that it provides the directory where you’d access files in the same directory as the input, which is a really useful thing to know sometimes. this is why for instance dirname test is ., dirname . is ., and dirname test/.. is test. what this function doesn’t do is calculate the parent directory of the input.
did this use to work at some point? i don’t recall any recent changes to String:-dirname…
EDIT: clarified the point about POSIX specification; /.. isn’t directly specified by POSIX.
I wrote it into a function in a granulator interface that I used in some courses a couple of years ago. There’s a patch file being loaded from some location A on disk, and this patch file references an audio file by an absolute path (which may be anywhere). To make it easier to move patches between machines, this function scans upward from A (patch location) and looks for the audio file’s basename in A or a parent directory – if found, it uses the nearby file, falling back to the absolute path otherwise.
Today I found that the while in this function inflooped because it never reaches an empty string. But I had no infloops before.
It’s possible that I only ever used it when the audio could be found before reaching root (never tested absolute paths) – but, knowing my coding approach, I don’t think I would have assumed that the dirname of “/” is empty. I’m pretty sure I would have tested what the dirname is (path.includes(Platform.pathSeparator) is a strange thing to write just on faith). But this was 2 or 3 years ago so I can’t say with absolute certainty.