DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 517JKtOR2962345 Authentication-Results: delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com Authentication-Results: delorie.com; spf=pass smtp.mailfrom=cygwin.com DKIM-Filter: OpenDKIM Filter v2.11.0 delorie.com 517JKtOR2962345 Authentication-Results: delorie.com; dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=UIid7wUi X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 499103857B90 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1738956054; bh=XI6x1hkeQoRu+SAPJgtLe3NCvPoIolsTxb9qbcOACc8=; h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=UIid7wUiV4+5DGvSRn9F7Zz4P3+RMvfjjX8m8TgiYtnl+sP5PD2oaye39UOFnl5U2 fgdw0Ca1IwjQMSt07tB3/ZXbnasxH6xQxas5sKJSR1IoGN7lPEWucroXCjP9w7lnMF j4Pvscnvbr4Mt0EEgwfzDuBeYXI395RSqS6yEzkg= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 583743857C6E ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 583743857C6E ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738955988; cv=none; b=l4KqpO2a+Uq6B9+KJ8PpYnO0YvosXG4A5hsHdGuiRHRCusvzxcRPCEveORrz8xVbHI9MPRqiZ7FyuNhEJVRVhjDo3ORYMZCsqgCWut+7Vnm+0PWxZuAQzdYSt2hnJ6/AMqn2HYh5EPGJGHI806HxXBcxHE4F75M+V7VQicOUdbE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1738955988; c=relaxed/simple; bh=uXb9yp99ZZQw9s/l9xHP+0FOl2vmlzw6dB/dpG58aRo=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=eXdAgfRwzyrFJRRymjMG6zh9kDi+VjyoXWlZoYC7PQomk8LjBFhk5Q+iVaYZarXzfshbKZ5+zVTxmr+8PSVCYVexPOfdfx09nI4l/GHrjtHrZAycq3kYju9gA7SB/U5oSe1OB4VciGo+SupC1pJ18//CqHFDCp7Y/CQMdAaZyR4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 583743857C6E Date: Fri, 7 Feb 2025 11:19:47 -0800 (PST) X-X-Sender: jeremyd AT resin DOT csoft DOT net To: Corinna Vinschen via Cygwin Subject: Re: exposing Windows mountpoints in Cygwin In-Reply-To: Message-ID: <474a8899-2c92-ad8a-09c5-f86314213e94@jdrake.com> References: <09960367-4427-2929-9b12-17cc2a15f5c3 AT jdrake DOT com> MIME-Version: 1.0 X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.30 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Jeremy Drake via Cygwin Reply-To: Jeremy Drake Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" On Fri, 7 Feb 2025, Corinna Vinschen via Cygwin wrote: > On Feb 6 13:31, Jeremy Drake via Cygwin wrote: > > Now that my patch to escape characters in /proc/mounts has been applied, > > I'll get back to what I was thinking about back in June. I would like to > > have a way to list Windows volume roots in Cygwin, and it seems to make > > sense to me to expose them via getmntent, /proc/mounts, etc. The way I > > see this working is probably to replace the available_drives mechanism for > > enumerating mounts in favor of using FindFirst/NextVolumeW and > > GetVolumePathNamesForVolumeNameW to enumerate cygdrive mount points. > > Been there, done that, but that was more than 10 years ago, so things > might have changed. At the time, the volume manager was incredibly > slow. Enumerating and converting volume paths from one style into the > other just took too much time. And, as you know, Cygwin already is > slow... > > Still, if you want to do that, it should not be part of the standard > mount points becasue this is another level of implementation. These are > the POSIX mount points handled by Cygwin. That should be part of the > cygdrive handling. Sounds like you were mulling over this anyway. Right, the cygdrive_getmntent function in mount.cc. > But it's not quite clear what the expected output should be. > So what is the expected output in the cygdrive dir? > > What I could imagine is something like this. Assuming two drives, one > of them mounted into a dir: > > C: \Device\HarddiskVolume1 > C:\foo \Device\HarddiskVolume2 > > $ ls -gG /cygdrive > d---r-x---+ 1 0 Feb 7 03:38 c > drwxrwxr-x 1 0 Jan 8 11:02 c_foo -> /mnt/c/foo I'm thinking much simpler than that. I'm just thinking about enumerating directory mounts in the cygdrive_getmntent function. So /cygdrive looks the same as it does now, just the roots of drives, but for instance mount would show something like C: on /cygdrive/c type ntfs (binary,noacl,posix=0,user,noumount,auto) C:/foo on /cygdrive/c/foo type ntfs (binary,noacl,posix=0,user,noumount,auto) Presumably this would also make df privy to them. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple