This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Device names in /proc/mounts


> -----Original Message-----
> From: Corinna Vinschen
> Sent: Monday, July 25, 2011 4:01 PM
> Subject: Re: Device names in /proc/mounts
> 
> On Jul 25 14:29, Schwarz, Konrad wrote:
> > There seems no way of mapping device names (resp. Win32 Device 
> > Namespace names) to mount points --
> 
> Cygwin mount pounts are not mapping disk devices to POSIX 
> pathnames, but
> Win32 pathnames to POSIX pathnames.

That is incompatibile with Linux's /proc/mount and mount(8).
Furthermore, Cygwin is inconsistent in this respect, as it uses
POSIX disk device names elsewhere, e.g., in the output of blkid(8).

I would like to find the mount point of a disk using its volume label (or UUID).
blk_id (on both Linux and Cygwin) outputs a string of the form /dev/sdXY,
given a volume label as an argument.

In Cygwin, there is no way of figuring out where /dev/sdXY is mounted.
In Linux, mount(8) or /proc/mounts contains the necessary information.

> > the Cygwin User's Guide suggests using comparing the output of 
> > /proc/partitions with the output of df(1) to match up the two.
> > 
> > It then pointedly uses the registry
> > entry '\HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices' -- which 
> encodes the 
> > mapping from NT device names to DOS device names -- as an 
> example for 
> > regtool(1) (see 
> http://www.cygwin.com/cygwin-ug-net/using-specialnames.html#pa
> thnames-proc-registry).
> > It does not explain how to decode the information there -- 
> but neither does MSDN.
> 
> Huh?  This is just an example for the virtual /proc/registry access.
> It has nothing to do with device mapping.

I merely find it telling that the key
used in the example is the one you would need to map between NT names
for disks and DOS/Win32 names -- this is the section right after the
one you refer to below.

> See 
> http://www.cygwin.com/cygwin-ug-net/using-specialnames.html#pa
> thnames-posixdevices
> instead, which shows how POSIX devices are mapped to native 
> NT devices.  

No -- this section does not cover disks.  It describes other
types of devices, but not disks.
 
> > However, blk_id(8) describes volumes in terms of (Cygwin) 
> device names 
> > (/dev/sda2), so an easier to use mapping would be nice to have.  It 
> > would also increase compatibility between Cygwin and Linux.
> > 
> > Some poking around MSDN reveals the function QueryDosDevice.  This 
> > function's purpose would seem to be to map DOS names to 
> Win32 device 
> > names.  Would it make sense to use this to populate the 
> first column 
> > of /proc/mounts (after mapping Win32 device names \\.\ to 
> Cygwin device names /dev/sdxy)?
> 
> No.  As I wrote above, Cygwin mount pounts are not mapping devices but
> Win32 pathnames to POSIX pathnames.  Devices just don't make 
> sense in this context.  The mapping from NT devices to POSIX 
> devices is used for direct device access only.

Well, since Win32 pathnames corresponding to volumes have NT device names,
and NT device names have Cygwin device names, wouldn't it be more consistent
to use the Cygwin device names in those Cygwin mount points?

Cygwin should limit mapping between its and the Win32 namespace to the
cygpath utility.  Cygpath would need to be extended to support mapping
between Win32 device names (COM1:, C:, ...) and Cygwin device names
(/dev/ttyS0, /dev/sda1, ...).  People wanting to mount a device
using Win32 names would then use

mount "$(cygpath "<win32path>")" <posixpath>

rather than

mount <win32path> <posixpath>

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]