Mail Archives: cygwin/2019/01/28/09:15:58
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<<EOF
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!
As you indicated in your commit of January 8, 2019, you have "to lie your
ass off" to make things work.
However, if a file descriptor refers to a "duplicated file handle" (which
is read-only), then at least write() should fail w.
Bad file descriptor (i.s.o. Permission denied)
Also fcntl(..., F_GETFL) should NOT show a handle w. write permission.
But I stop here. I let it rest.
But not without saying thanks to you for all the help I got from you in
the past years.
Regards,
Henri
-----
author Corinna Vinschen <corinna AT vinschen DOT de>
Tue, 8 Jan 2019 20:37:43 +0000 (21:37 +0100)
committer Corinna Vinschen <corinna AT vinschen DOT de>
Tue, 8 Jan 2019 20:47:28 +0000 (21:47 +0100)
commit ec36c59f1a9349e690849e393251623f5936408c
tree fd8b12b24bdb4fb21a4600cdd0dd14d4e91fb30d tree
parent 0c545f3264aaaac3d02d3ef785a2e2e9d77ed03f commit | diff
Cygwin: open: workaround reopen file w/ delete disposition set
On pre-W10 systems there's no way to reopen a file by handle if
the delete disposition is set. We try to get around with
duplicating the handle.
535 /* Open system call handler function. */
536 int
537 fhandler_base::open (int flags, mode_t mode)
538 {
..
694 status = NtCreateFile (&fh, access, &attr, &io, NULL, file_attributes, shared,
695 create_disposition, options, p, plen);
696 /* Pre-W10, we can't open a file by handle with delete disposition
697 set, so we have to lie our ass off. */
698 if (get_handle () && status == STATUS_DELETE_PENDING)
699 {
700 BOOL ret = DuplicateHandle (GetCurrentProcess (), get_handle (),
701 GetCurrentProcess (), &fh,
702 access, !(flags & O_CLOEXEC), 0);
703 if (!ret)
704 ret = DuplicateHandle (GetCurrentProcess (), get_handle (),
705 GetCurrentProcess (), &fh,
706 0, !(flags & O_CLOEXEC),
707 DUPLICATE_SAME_ACCESS);
708 if (!ret)
709 debug_printf ("DuplicateHandle after STATUS_DELETE_PENDING, %E");
710 else
711 status = STATUS_SUCCESS;
712 }
=====
--
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
- Raw text -