From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30962 invoked by alias); 28 Jul 2011 08:18:55 -0000 Received: (qmail 30949 invoked by uid 22791); 28 Jul 2011 08:18:51 -0000 X-SWARE-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI X-Spam-Check-By: sourceware.org Received: from david.siemens.de (HELO david.siemens.de) (192.35.17.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 28 Jul 2011 08:18:36 +0000 Received: from mail1.siemens.de (localhost [127.0.0.1]) by david.siemens.de (8.13.6/8.13.6) with ESMTP id p6S8IYwA005020 for ; Thu, 28 Jul 2011 10:18:34 +0200 Received: from DEMCHP99ET0MSX.ww902.siemens.net (demchp99et0msx.ww902.siemens.net [139.25.131.181]) by mail1.siemens.de (8.13.6/8.13.6) with ESMTP id p6S8ISF0016696 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for ; Thu, 28 Jul 2011 10:18:34 +0200 Received: from DEMCHP99ET4MSX.ww902.siemens.net (139.25.131.174) by DEMCHP99ET0MSX.ww902.siemens.net (139.25.131.181) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 28 Jul 2011 10:18:31 +0200 Received: from DEMCHP99E84MSX.ww902.siemens.net ([169.254.3.192]) by DEMCHP99ET4MSX.ww902.siemens.net ([139.25.131.174]) with mapi; Thu, 28 Jul 2011 10:18:27 +0200 From: "Schwarz, Konrad" To: "cygwin@cygwin.com" Date: Thu, 28 Jul 2011 08:18:00 -0000 Subject: RE: Device names in /proc/mounts Message-ID: <9B10FEAACF062F48A095880A451FF0590380B9DAEF@DEMCHP99E84MSX.ww902.siemens.net> References: <20110727094051.GA28312@calimero.vinschen.de> In-Reply-To: <20110727094051.GA28312@calimero.vinschen.de> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2011-07/txt/msg00359.txt.bz2 > From: Corinna Vinschen > Sent: Wednesday, July 27, 2011 11:41 AM > Subject: Re: Device names in /proc/mounts > D:/foo/bar /baz xyz binary,posix=3D0 0 0 > //server/share/some/path /home/dummy smbfs binary,noacl 0 0 >=20 > how would you map them to devices? Both paths are not=20 > devices, except that they are equivalent to the NT kernel paths >=20 > \Device\HarddiskVolume3\foo\bar > \Device\Mup\server\share\some\path Why not display these (in /proc/mounts) as /cygdrive/d/foo/bar /baz bind ... //server/share/some/path /home/dummy bind ... I think this is the Linux bind mount syntax. > > In Cygwin, there is no way of figuring out where /dev/sdXY=20 > is mounted. >=20 > Yes, for the simple reason that they are not mounted in=20 > Cygwin, but only in NT. What you're asking for just doesn't=20 > make sense in this context. As far as I understand, Cygwin mount knows about - fixed mounts /, /usr/bin, /usr/lib - user-defined mounts taken from /etc/fstab, /etc/fstab.d, and the command-= line - Win32 drive letters implicitly mounted under /cygdrive The last case is actually handled by Windows, as you point out. What would be the problem (otherwise than backwards compatibility) in using Cygwin device names in this last case? For the second case (and the first, should you so desire), you could use the /cygdrive prefix or //server/share notation, as above. > No. There is no reason to carry the Linux compatibility to=20 > such extremes. Forcing the users to use device names in=20 > /etc/fstab just won't fly. Let's use the above two examples again: >=20 > D:/foo/bar /baz xyz binary,posix=3D0 0 0 > //server/share/some/path /home/dummy smbfs binary,noacl 0 0 >=20 > What would you like to see in fstab for both of them? >=20 > /Device/HarddiskVolume3/foo/bar /baz xyz binary,posix=3D0 0 0 >=20 > or >=20 > /dev/sdb1/foo/bar /baz xyz binary,posix=3D0 0 0 >=20 > Both are not Linux compatible either, since you can't use=20 > expressions like /dev/sdb1/foo/bar under Linux to access=20 > subdirectories on a drive. Well, I would use /cygdrive/d/foo/bar /baz bind ... as I suggested above. Even better would be if Linux rebinding did it this way. But mostly I would like /dev/sda1 /cygdrive/c ntfs ... rather than C: /cygdrive/c ntfs ... > And what about remote shares? >=20=20 > /Device/Mup/server/share/some/path /home/dummy smbfs=20 > binary,noacl 0 0 >=20 > Where's the POSIX device here? There is none. Do you want=20 > to invent one, like, say, /dev/mup? There's no equivalent=20 > device on Linux. Again, as suggested above: //server/share/some/path /home/dummy smbs ... > Cygwin tries to have a Linux-like API. > But it's running on Win32. So there are limitation what we=20 > can do and what makes sense, given the context. I quite understand, it's just that I think you could sensibly stretch the limits a little bit more in this case :-). -- 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