public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "Schwarz, Konrad" <konrad.schwarz@siemens.com>
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: RE: Device names in /proc/mounts
Date: Wed, 27 Jul 2011 08:15:00 -0000	[thread overview]
Message-ID: <9B10FEAACF062F48A095880A451FF05903801180E9@DEMCHP99E84MSX.ww902.siemens.net> (raw)
In-Reply-To: <20110725140038.GA22821@calimero.vinschen.de>

> -----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

  reply	other threads:[~2011-07-27  8:15 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-25 12:30 Schwarz, Konrad
2011-07-25 14:01 ` Corinna Vinschen
2011-07-27  8:15   ` Schwarz, Konrad [this message]
2011-07-27  8:35   ` Schwarz, Konrad
2011-07-27  9:41     ` Corinna Vinschen
2011-07-27 11:19       ` Christopher Faylor
2011-07-28  8:18       ` Schwarz, Konrad
2011-07-28 11:22         ` Christopher Faylor
2011-07-29  7:46           ` Schwarz, Konrad
2011-07-29  9:21             ` Corinna Vinschen
2011-07-29 13:34               ` Schwarz, Konrad
2011-07-29 20:16                 ` Corinna Vinschen
2011-07-30  4:53                   ` Christopher Faylor
2011-07-30  8:18                     ` Corinna Vinschen
2011-08-01 13:10                       ` Nellis, Kenneth
2011-08-01 13:22                         ` Christopher Faylor
2011-08-06 23:53                   ` pb w/ cygpath -w /dev/sdXY (was Re: Device names in /proc/mounts) Cyrille Lefevre
2011-08-07 11:38                     ` Corinna Vinschen
2012-09-13 16:27                   ` associating volume labels with drive letters Nellis, Kenneth
2012-09-26  6:22                     ` Mark O'Keefe
2012-09-26 13:43                       ` Nellis, Kenneth
2012-10-19 18:45                         ` Nellis, Kenneth
2012-10-19 18:52                           ` Corinna Vinschen
2011-07-29 21:28                 ` Device names in /proc/mounts Buchbinder, Barry (NIH/NIAID) [E]
2011-07-25 15:07 ` Christopher Faylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9B10FEAACF062F48A095880A451FF05903801180E9@DEMCHP99E84MSX.ww902.siemens.net \
    --to=konrad.schwarz@siemens.com \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).