Code: Select all
fopen("../foo/./bar.txt")
=> library expands into "$(CWD)/../foo/./bar.txt"
=> library normalises into "/home/hellbender/foo/bar.txt"
=> library calls VFS_resolve("/home/hellbender/foo/bar.txt");
My theory is, things like "current working directory" and relative paths are none of the VFS's problem and should be handled by the process itself (e.g. part of the C standard library that the process uses). This means the VFS only ever has to care about absolute paths; and different processes (written in different languages with different libraries, for different semantics and/or compatibility requirements) can potentially use very different ways to convert relative paths into absolute paths (or "none" if the process doesn't use relative paths to start with).Hellbender wrote:I'm designing my first virtual file system API, and was thinking about the best way to handle relative paths and ".", ".." traversing.
Curious: What if foo/ didn't exist? I would consider that an error, but if the userspace were to automatically resolve .. path components, then it would have to check to see if each element of the path exists in order to maintain that error reporting. This could potentially involve a lot of system calls (and therefore overhead) that would be superfluous. I don't think the additional complexity of doing path resolution in kernel-space is that bad.More specifically, I think VFS should only ever care about "absolute, canonical paths". What I mean here is that "/foo/../bar" would be illegal and the process/library would need to convert it to the canonical "/bar" instead
Yes, and no.piranha wrote:Curious: What if foo/ didn't exist? I would consider that an error, but if the userspace were to automatically resolve .. path components, then it would have to check to see if each element of the path exists in order to maintain that error reporting. This could potentially involve a lot of system calls (and therefore overhead) that would be superfluous. I don't think the additional complexity of doing path resolution in kernel-space is that bad.More specifically, I think VFS should only ever care about "absolute, canonical paths". What I mean here is that "/foo/../bar" would be illegal and the process/library would need to convert it to the canonical "/bar" instead
I don't support 'chroot' (for my OS design).piranha wrote:Interesting. I agree, it does depend on if you consider such a path valid or not. Interestingly, gcc and ld do that kind of path screwery all the time. In your system, then, how would you handle roots? (again, somewhat assuming unix semantics) if you chroot and your VFS handles absolutely no relative path, wouldn't that include a path to the root if a process is executing in a chroot'd environment? If it handles storing the "current directory" and "root" locations in userspace, that could be overwritten, and the process could break out.
There's 2 separate issues here..piranha wrote:Another performance issue would be resolving really long paths. If I access 'foo/file' from my current directory, and the kernel handles relative paths, I only need to traverse the current directory for foo and foo for file (getting inodes along the way). If it doesn't, I prepend my current directory and give the VFS an absolute path, forcing it to resolve the entire thing.
There's a reason I didn't talk about symbolic links, I know how complicated they make thingsAlso note that the main reason I'm suggesting "VFS only sees canonical absolute paths" is that it reduces complexity in the VFS; and I really do think you're grossly underestimating just how insane the complexity really is otherwise. For an example; imagine that "foo/mylink" is a symbolic link to "/bar"; and the first process changes its current/working directory to "/foo/mylink/stuff" and starts reading the directory "things" (which is actually "/foo/mylink/stuff/things", which is actually "/bar/stuff/things"). Then a second process unlinks/"deletes" the symbolic link. After that the first process sees the file "hello.txt" in the directory it's still reading and tries to open the file "things/hello.txt" (which is actually "/foo/mylink/stuff/things/hello.txt", which is actually "/bar/stuff/things/hello.txt"). The programmer who wrote the first process expects the 'open()' to succeed (they've ensured the file exists and the file actually does still exist). Does it work?
Another implementation could store simply a directory entry as the current working directory. Then the two would not be identical, instead you would simply get a head start on the userspace version because you get to start resolving the path halfway through, and you don't need to do the working directory each time.First; if the kernel handles relative paths and you access 'foo/file' from your current directory, then you ask VFS for "foo/file" and the VFS prepends your working directory to it to get "/workDir/foo/file" and then has to check for and handle/remove any "//" and "./" and "../" (even if there are none it still must check); and after all that the VFS has an absolute path it can work with.
Yes, I agree. Again, this depends on the overall design (and of course, they're all valid!). I think it works well in the basic cases (looking up, creating, deleting, all trivial). But it does add complexity to cases like symbolic links changing (how would your design handle symbolic links?), mount points (if supported), chrooting...The second issue is whether or not directories along the path need to be checked . . .
