From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47456 invoked by alias); 17 Dec 2018 09:25:40 -0000 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 Received: (qmail 47444 invoked by uid 89); 17 Dec 2018 09:25:39 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-100.9 required=5.0 tests=BAYES_00,GOOD_FROM_CORINNA_CYGWIN,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=story, SYSTEM, lengths, bottom X-HELO: mout.kundenserver.de Received: from mout.kundenserver.de (HELO mout.kundenserver.de) (217.72.192.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 17 Dec 2018 09:25:37 +0000 Received: from calimero.vinschen.de ([24.134.7.25]) by mrelayeu.kundenserver.de (mreue109 [212.227.15.183]) with ESMTPSA (Nemesis) id 1MekvT-1h6mrL19l7-00aqJG for ; Mon, 17 Dec 2018 10:25:34 +0100 Received: by calimero.vinschen.de (Postfix, from userid 500) id 9449CA803E7; Mon, 17 Dec 2018 10:25:33 +0100 (CET) Date: Mon, 17 Dec 2018 09:25:00 -0000 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: /dev/fd/N not synonymous with file descriptor N; it is on Linux Message-ID: <20181217092533.GP28727@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <0f030e809f063f5a5e64ff7a7a0c3227@xs4all.nl> <20181216202847.GK28727@calimero.vinschen.de> <20181216215549.GO28727@calimero.vinschen.de> <12270f528754c1ce974e6ad8d22c4249@xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j2AXaZ4YhVcLc+PQ" Content-Disposition: inline In-Reply-To: <12270f528754c1ce974e6ad8d22c4249@xs4all.nl> User-Agent: Mutt/1.9.2 (2017-12-15) X-SW-Source: 2018-12/txt/msg00134.txt.bz2 --j2AXaZ4YhVcLc+PQ Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 3525 On Dec 17 05:30, Houder wrote: > On 2018-12-16 22:55, Corinna Vinschen wrote: > [snip] >=20 > > I'm mulling over adding some hack to open(). It could try to recognize > > the special case of opening a processes' own descriptor symlink within > > /proc and then warp the open() call into dup(). No idea how tricky > > or even feasible that is, though... >=20 > That is why I wrote the following in my STC: >=20 > // Q: does Cygwin attempt to read the /tmp directory? (an attempt > that > // will fail, because the file has been unlinked) > // it appears that reading a symlnk in /dev/fd can best be divert= ed > to > // the open file descriptor of the process ... >=20 > What I meant was, that I see no reason to modify the symlink in this > special case, but in stead of that to access the file using fd N, where > N is equal to the one in /dev/fd/N. >=20 > File descriptor N has been left open by bash and should not have been > closed as result of the exec ... tl;dr: cat tries to open /dev/fd/0. /dev/fd/0 refers to a non-existing file and that's why open fails. Cygwin doesn't have special code to handle the fd symlinks as refference to an actually open descriptors. The long story: The descriptor hasn't been closed. Cat still has the file open as fd 0. The problem is that you tell cat to open and read from /dev/fd/0, *not* from fd 0. That's quite a difference. /dev/fd/0 is just some arbitrary file which is given to open(2), a symlink at that. First thing open(2) does is to call the symlink evaluation code. The symlink is ultimately evaluated to the filename opened by the shell. So, cat's open(2) tries to open "/tmp/whatever". But, as you noticed, that path doesn't exist anymore since it has been deleted by the shell before even writing to it via unlink(2). What happens is that unlink(2) is supposed to delete a file in use. Since that's not possible in Windows, the file gets renamed into the recycle bin and just marked for deletion. The fact that the filename changed is not known to the application of course, it just gets success reported from unlink. Cygwin itself doesn't know the new name of the file either. There just isn't a reason to keep track since it's going to be removed anyway at one point. And even *if* we keep track, we can't use this information since files marked for deletion can't be opened on Windows (ERROR_DELETE_PENDING or ERROR_ACCESS_DENIED, I'm not sure which). Here's another problem with handling /dev/fd/0 as just some descriptor we can call dup(2) on: /dev/fd/0 is just some symlink which evaluates like this: - /dev/fd is a symlink to /proc/self/fd - /proc/self is a symlink to /proc/ So before we even get to evaluate fd 0 symlink, we're at /proc//fd/0 Here's the question: What if you don't give /proc/self/fd/0 to cat, but something like /proc//fd/0? That's where Cygwin just fails because /proc is a process-local fake in our user space Cygwin DLL. Emulating /proc is fun stuff, the full functionality is pretty tricky without going to great lengths like starting a service with SYSTEM permissions. Bottom line is, we could do more if we decide that running cygserver is a requirement. As it is, we always strived for a setup which works "out of the box", without having to start services and stuff. Corinna --=20 Corinna Vinschen Cygwin Maintainer --j2AXaZ4YhVcLc+PQ Content-Type: application/pgp-signature; name="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEoVYPmneWZnwT6kwF9TYGna5ET6AFAlwXa40ACgkQ9TYGna5E T6DECw/+NzRN0Pzt9r3BgUIvfAC/g+h9orX9LsAg4uzRbp9wBBPDs2AX7GLMtlwt 1NCVK3kcuOwnDJ7dNLxULdMAc3oensXZHtB6ouvBlIpk8ChHAXbPCZY/VkQHWfHR AC2cALCMUCfZsHU/JZLBvxK02uL5gVGK0RCnFQ40q5HPdl6x/ynFmbWM0CHi+yag 2eXvbaqRa+VTU2nI+LX5/d1P5DjtVm5H9OtFO8n8MZMiDYKMF0UKsIw8VWZW5xAJ 3DvKUPCUOkaqzh9rPyN35Qxbnd0RPt7Ki4LKPD/WypeLv0L75uEYNYHOEAJVs7WK 9mqg77CwgDw4ECX6jJsAr2P1mMG1GokHef3rydmMtLwsbzby4iB6p/gPB5xUCJp/ nslk9PupOnpGtdyPkG/T0mJupjNFY239cinHgIXFQSoDONOQWWqV0fKzPDEoGznA O4CVkoosgHvFeF7H32qqn17gm4Td4B47uEzsD+dg5Xl54+zrFLVxH0smoV6Zd/Gl vDlOuY65OxcH+Is97fl8Z3CE23aVpKk/JjvRbDW9XbUwAfla9TIo2+Mf0GKHd/Rd 85naMIm6Ow3Nr/RMuq3lp6/YC5ofSBi1PV4EhKNlm3QSqvs8BN8tiYlEslcYDGk9 k0MMwtRAJUJDScOklRb2oA51+fabJYoRxd7n9hmCqZQOQ5ILPC8= =AbvH -----END PGP SIGNATURE----- --j2AXaZ4YhVcLc+PQ--