Linux is to mount as Windows is to _______?

So Linux "mounts" a hard drive to perform some operation such as reading/writing. Does Windows "mount" in the same way?

Is it called something different in the context of Microsoft?

Solution 1:

If you know Windows internals, do fix my errors, please.

"Mounting" consists of two primary parts, which are the same in both systems but their separation is somewhat different:

1. accessing the filesystem on disk;
2. assigning a path to the filesystem.

On Linux, the same mount() function does both jobs; a filesystem has to be mounted explicitly on a user-chosen path and remains opened as long as it is mounted on at least one path (possibly more). Once all paths to that filesystem are umount()ed, it is closed.

Windows mounts volumes automatically when the volume appears – it immediately opens the filesystem and assigns a drive letter and/or any other configured names to it.

A disk can be temporarily "dismounted" using the FSCTL_LOCK_VOLUME and/or FSCTL_DISMOUNT_VOLUME ioctl functions – for example, while running a chkdsk on it – but is automatically mounted again when the program unlocks it or exits. This behavior could be viewed as kind of opposite to Linux. Since dismounting a filesystem is temporary, it retains the assigned names even while dismounted. (The "Safely Remove" function dismounts the filesystem and disables the underlying device, to prevent Windows from seeing the filesystem and remounting it.)

A filesystem can have several names assigned to it:

• Drive letters (A:, C:, [:) – automatically assigned to new disks and lost on reboot, although Windows remembers assignments configured by the user. In this way, they are similar to Unix mountpoints.

  (Drive letters can also be assigned to arbitrary devices, including network filesystems supported by Windows. You can see their targets at \GLOBAL??\ and \Sessions\<session>\DosDevices\<loginid>\ in WinObj.)

  Note: Drive letters are normally system-wide, but they can also be assigned session-wide using subst or DefineDosDevice(), and yes, it accepts [:. The session-wide assignments are never stored anywhere and vanish on reboot.

• Folder mount points (C:\Disks\Music) – a filesystem can be mounted on any arbitrary directory, like in Unix; however, they are actually stored on the target disk, in the form of reparse points (a more powerful form of symlinks) which refer to the mounted disk by its volume name.

  (Different kinds of reparse points also exist; a few standard ones are mount points, symlinks, directory junctions.)

• Volume GUID paths (\\?\Volume{710308c0-978e-11e1-95bc-806d6172696f}\) (at least that's how it seems to be called) – special paths in the Win32 namespace \\?\, containing an UUID that Windows assigns to that particular volume on this particular Windows system. They cannot be changed. They are listed by mountvol, or under \GLOBAL??\ in WinObj. Unlike drive letters, these are the same for all users.

• Device interface paths \\?\STORAGE#Volume#<something>Signature<hex>Offset<hex>Length<hex>#<uuid>\ Unlike a volume GUID path, each volume has exactly one device interface path.

  • Volume device name \Device\HarddiskVolume23 - unlike all the previous ones, which are just symbolic links, this directly names the volume. You know this because it's in the \Device namespace, not the \\? namespace. That also means you can't use it with functions such as CreateFile.

diskmgmt.msc, mountvol and diskpart can manage both drive letters and mount points.

Even when a volume doesn't have any drive letters and isn't "mounted" on any folder, it remains open and its contents can still be accessed through its volume name; e.g.

\\?\Volume{710308c0-978e-11e1-95bc-806d6172696f}\Windows\Explorer.exe

Solution 2:

mountvol.exe is the Windows equivalent.