←back to thread

Ubuntu on Windows

(blog.dustinkirkland.com)
2049 points bpierre | 2 comments | | HN request time: 0.001s | source
Show context
look_lookatme ◴[] No.11391320[source]
What is up with the unix-y directory structure in this screenshot?

http://o.aolcdn.com/dims-global/dims3/GLOB/resize/1345x666/q...

It's been a while since I've used Windows but I'm pretty sure it doesn't have a unix directory structure... is it the case that they map / to a folder inside windows?

replies(1): >>11391365 #
geofft ◴[] No.11391365[source]
Yes, as mentioned in the article, / on the Linux side maps to C:\Users\...\AppData\Local\Lxss\rootfs\, and C:\ on the Windows side maps to /mnt/c/ on the Linux side.

Think of it as an Ubuntu chroot on Windows, with C:\ bind-mounted into the chroot.

replies(1): >>11391400 #
1. bryanlarsen ◴[] No.11391400[source]
I get the impression that it's a new filesystem, so C:\Users\Kirkland\AppData\Local\Lxss\rootfs is a file containing a linuxy file system that's mounted onto / in the Linux subsystem and onto C:\Users\Kirkland\AppData\Local\Lxss\rootfs\ on the Windows subsystem.
replies(1): >>11415671 #
2. JdeBP ◴[] No.11415671[source]
It's not, though.

Windows NT was designed with multiple "personality" subsystems right from the start. The filesystem that any given "personality" sees is not the underlying system that is seen via the "Native API". They are all reinterpreted views of the NT Object Manager's namespace.

* The Win32 subsystem presents a view where C:\ in a Win32 name is mapped to \DosDevices\C:\ in a Native NT name.

* The POSIX subsystem (at least in the later SFU/SFUA) presents a view where /dev/fs/c/ in a POSIX name is mapped to \DosDevices\C:\ in a Native NT name.

* This Linux subsystem (reportedly) presents a view where /mnt/c/ in a Linux name is mapped to \DosDevices\C:\ in a Native NT name.

\DosDevices\C: is, in turn, a Object Manager symbolic link that points to somewhere else in the Object Manager namespace. (There's also a whole mechanism of "per-login" and "global" symbolic links that I'm glossing over.)

Win32 names relative to \ , D:., and . , and POSIX names relative to \ and . , are also things that are handled within the subsystem (sometimes within a set of conspirator language runtime libraries, in fact) that are mapped by that to the NT Object Manager's namespace.

* The Win32 subsystem itself only supports one current directory, the current directory on the current drive. The Win32 subsystem keeps a handle to that current directory open per Win32 process (and stores the handle value in the Process Environment Block in the process' address space) and remembers what string, including drive letter, it was set to.

* The current directory on another drive is a fiction maintained by conspiring Win32 language runtime libraries, using a set of otherwise hidden environment variables. A Win32 name with D:. is mapped using the value of an "=D:" environment variable. See http://unix.stackexchange.com/a/251215/5132 for how this can make a mess with the (Win32) Bourne Again shell running on Cygwin.

* Win32 names relative to a driveless \ use a Win32-subsystem-maintained idea of a current drive letter, derived from the Win32 "current directory" string that is set, and then go through the mapping to \DosDevices\C:\ (or whatever drive letter).

* The (SFU/SFUA) POSIX subsystem doesn't need such conspiracy, as the POSIX model is to have only one current directory, too. So the POSIX subsystem keeps a handle to the current directory open per POSIX process.

* This Linux subsystem (reportedly) presents a view where / in a Linux name is mapped to \DosDevices\C:\Users\Kirkland\AppData\Local\Lxss\rootfs\ in a Native NT name.

* Presumably, this Linux subsystem similarly keeps a handle to the current directory open per Linux process, and remembers its string. After all, it has to present /proc/self/cwd to Linux programs.

Every Windows NT subsystem has filename mapping mechanisms, and they all present their own "views" of the actual native namespace of the NT operating system kernel. This is not a new filesystem. It's another NT subsystem with its own view of the NT Object Manager's namespace, just as the other subsystems have.