On Jan 28 15:15, Houder wrote: > On Sun, 27 Jan 2019 22:57:21, Corinna Vinschen wrote: > > > > On Jan 27 19:39, Houder wrote: > > > NO BLODA. > > > > > > Ok, for the record (as this is W7, i.e. pre-pre-W10 :-) > > > > > > Using my original STC again: (source code included below) > > > > > > - create file (in /tmp) write-only, write "Hello, world!" to file, close > > > fd > > > - open file once more read-only > > > - unlink file > > > - open file, using /dev/fd/N, read-write <==== succeeds (and the handle > > > shown by fcntl is read-write) > > > - write "*****" to file (using the fd obtained in the previous line), > > > lseek to begin of file > > > - write fails w/ "Permission denied" <==== so ... the file cannot be > > > written to? > > > > Yes, that scenario fails on W7 but works on W10 1709 and later. Keep in > > mind that the OS doesn't allow to reopen a file which has been deleted. > > Cygwin tries a best effort by duplicating the handle. A duplicated file > > handle can't have more permissions than the original handle, so if the > > original handle was opened for reading only, the duplicated handle can't > > have write perms. > [snip] > > Yes Corinna, I already got that from one of your previous replies. You gave > the same explanation here: > > https://cygwin.com/ml/cygwin/2019-01/msg00171.html > (Date: Tue, 22 Jan 2019 10:41:57 +0100) > > "A duplicated file handle can't have more permissions than the original > handle" (i.e what occurs on pre "Windows 10 1709" systems) > > The "funny" thing is, in that same post, you showed that the STC succeeded > on your virtual W7 system ... (contradiction!). > > The STC in that post executes the same scenario as above ... > > - the difference is that the first 3 steps are carried out by bash, when > invoked as follows: > > @@ ./stca /dev/fd/N N< > Both STC's (stc.c and stca.c) fail on my W7 (Note: stc.c is the testcase > that I included in my previous post -- and the one I started this thread > with). > > Mind this: I am NOT upset that the STC's (plural) fail on (my) W7. Not at > all! There was a minor difference when I tested it: My shell is not bash but tcsh, and tcsh opens the here document with different perms. I added debug output to fhandler_base::open and on bash the ACCESS_MASK set on the incoming handle is 0x12019F with tcsh and 0x120089 with bash. Compare with https://msdn.microsoft.com/en-us/library/cc246802.aspx, and you'll see that tcsh opened the file woth O_RDWR, while bash opened the file with O_RDONLY. I didn't notice this before, sorry! Corinna -- Corinna Vinschen Cygwin Maintainer