From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin-patches@cygwin.com
Subject: Re: [PATCH v2 1/8] syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE
Date: Fri, 22 Jan 2021 11:52:01 +0100 [thread overview]
Message-ID: <20210122105201.GD810271@calimero.vinschen.de> (raw)
In-Reply-To: <20210120161056.77784-2-ben@wijen.net>
Hi Ben,
On Jan 20 17:10, Ben Wijen wrote:
> Implement wincap.has_posix_unlink_semantics_with_ignore_readonly and when set
> skip setting/clearing of READONLY attribute and instead use
> FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE
> ---
> winsup/cygwin/ntdll.h | 3 ++-
> winsup/cygwin/syscalls.cc | 14 +++++-----
> winsup/cygwin/wincap.cc | 11 ++++++++
> winsup/cygwin/wincap.h | 56 ++++++++++++++++++++-------------------
> 4 files changed, 49 insertions(+), 35 deletions(-)
>
> diff --git a/winsup/cygwin/ntdll.h b/winsup/cygwin/ntdll.h
> index d4f6aaf45..7eee383dd 100644
> --- a/winsup/cygwin/ntdll.h
> +++ b/winsup/cygwin/ntdll.h
> @@ -497,7 +497,8 @@ enum {
> FILE_DISPOSITION_DELETE = 0x01,
> FILE_DISPOSITION_POSIX_SEMANTICS = 0x02,
> FILE_DISPOSITION_FORCE_IMAGE_SECTION_CHECK = 0x04,
> - FILE_DISPOSITION_ON_CLOSE = 0x08
> + FILE_DISPOSITION_ON_CLOSE = 0x08,
> + FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE = 0x10,
> };
>
> enum
> diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc
> index 4742c6653..2e50ad7d5 100644
> --- a/winsup/cygwin/syscalls.cc
> +++ b/winsup/cygwin/syscalls.cc
> @@ -709,14 +709,11 @@ _unlink_nt (path_conv &pc, bool shareable)
> flags);
A few lines above, FILE_WRITE_ATTRIBUTES is added to the
access mask, if the file is R/O. This, too, depends on
wincap.has_posix_unlink_semantics_with_ignore_readonly().
> if (!NT_SUCCESS (status))
> goto out;
> - /* Why didn't the devs add a FILE_DELETE_IGNORE_READONLY_ATTRIBUTE
> - flag just like they did with FILE_LINK_IGNORE_READONLY_ATTRIBUTE
> - and FILE_LINK_IGNORE_READONLY_ATTRIBUTE???
> -
> - POSIX unlink semantics are nice, but they still fail if the file
> + /* POSIX unlink semantics are nice, but they still fail if the file
> has the R/O attribute set. Removing the file is very much a safe
> bet afterwards, so, no transaction. */
This comment should contain a short comment "W10 1809+, blah blah",
analogue to the comment in line 698 in terms of 1709+ ("++"? Oops,
fix typo...).
> - if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
> + if (!wincap.has_posix_unlink_semantics_with_ignore_readonly ()
> + && (pc.file_attributes () & FILE_ATTRIBUTE_READONLY))
I'd invert the test order here. On 1809+ systems, the majority of
systems these days, the first test is always true, but it's always
checked, even if the file is not R/O. First checking for R/O would
reduce the hits on the "with_ignore_readonly" check.
> {
> status = NtSetAttributesFile (fh, pc.file_attributes ()
> & ~FILE_ATTRIBUTE_READONLY);
> @@ -727,10 +724,13 @@ _unlink_nt (path_conv &pc, bool shareable)
> }
> }
> fdie.Flags = FILE_DISPOSITION_DELETE | FILE_DISPOSITION_POSIX_SEMANTICS;
> + if(wincap.has_posix_unlink_semantics_with_ignore_readonly ())
^^^
space
> + fdie.Flags |= FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE;
^^^^
indentation 2, not 4.
> status = NtSetInformationFile (fh, &io, &fdie, sizeof fdie,
> FileDispositionInformationEx);
> /* Restore R/O attribute in case we have multiple hardlinks. */
> - if (pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
> + if (!wincap.has_posix_unlink_semantics_with_ignore_readonly ()
> + && (pc.file_attributes () & FILE_ATTRIBUTE_READONLY))
Same here.
Actually, on second thought, what about introducing another bool at the
start of the posix handling, along the lines of
const bool needs_ro_handling =
(pc.file_attributes () & FILE_ATTRIBUTE_READONLY)
&& !wincap.has_posix_unlink_semantics_with_ignore_readonly ();
and then check for needs_ro_handling throughout?
Thanks,
Corinna
next prev parent reply other threads:[~2021-01-22 10:52 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 13:45 [PATCH 00/11] Improve rm speed Ben Wijen
2021-01-15 13:45 ` [PATCH 01/11] syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE first Ben Wijen
2021-01-18 10:25 ` Corinna Vinschen
2021-01-18 10:45 ` Corinna Vinschen
2021-01-18 12:11 ` Ben
2021-01-18 12:22 ` Corinna Vinschen
2021-01-18 14:30 ` Ben
2021-01-18 14:39 ` Corinna Vinschen
2021-01-18 14:59 ` Ben
2021-01-15 13:45 ` [PATCH 02/11] syscalls.cc: Deduplicate _remove_r Ben Wijen
2021-01-18 10:56 ` Corinna Vinschen
2021-01-18 12:40 ` Ben
2021-01-18 13:04 ` Corinna Vinschen
2021-01-18 13:51 ` Ben
2021-01-18 14:49 ` Corinna Vinschen
2021-01-18 14:58 ` Ben
2021-01-15 13:45 ` [PATCH 03/11] syscalls.cc: Fix num_links Ben Wijen
2021-01-18 11:01 ` Corinna Vinschen
2021-01-15 13:45 ` [PATCH 04/11] syscalls.cc: Use EISDIR Ben Wijen
2021-01-18 11:06 ` Corinna Vinschen
2021-01-15 13:45 ` [PATCH 05/11] Cygwin: Move post-dir unlink check Ben Wijen
2021-01-18 11:08 ` Corinna Vinschen
2021-01-18 14:31 ` Ben
2021-01-18 14:52 ` Corinna Vinschen
2021-01-15 13:45 ` [PATCH 06/11] cxx.cc: Fix dynamic initialization for static local variables Ben Wijen
2021-01-18 11:33 ` Corinna Vinschen
2021-01-15 13:45 ` [PATCH 07/11] syscalls.cc: Implement non-path_conv dependent _unlink_nt Ben Wijen
2021-01-18 10:51 ` Ben
2021-01-15 13:45 ` [PATCH 08/11] path.cc: Allow to skip filesystem checks Ben Wijen
2021-01-18 11:36 ` Corinna Vinschen
2021-01-18 17:15 ` Ben
2021-01-19 9:25 ` Corinna Vinschen
2021-01-15 13:45 ` [PATCH 09/11] mount.cc: Implement poor-man's cache Ben Wijen
2021-01-18 11:51 ` Corinna Vinschen
2021-02-03 11:38 ` Ben
2021-02-04 19:37 ` Corinna Vinschen
2021-01-15 13:45 ` [PATCH 10/11] syscalls.cc: Expose shallow-pathconv unlink_nt Ben Wijen
2021-01-15 13:45 ` [PATCH 11/11] dir.cc: Try unlink_nt first Ben Wijen
2021-01-18 12:13 ` Corinna Vinschen
2021-01-18 17:07 ` Ben
2021-01-18 17:18 ` Ben
2021-01-19 9:54 ` Corinna Vinschen
2021-01-20 16:10 ` [PATCH v2 0/8] Improve rm speed Ben Wijen
2021-01-20 16:10 ` [PATCH v2 1/8] syscalls.cc: unlink_nt: Try FILE_DISPOSITION_IGNORE_READONLY_ATTRIBUTE Ben Wijen
2021-01-22 10:52 ` Corinna Vinschen [this message]
2021-01-22 15:47 ` [PATCH v3 " Ben Wijen
2021-01-25 10:30 ` Corinna Vinschen
2021-01-20 16:10 ` [PATCH v2 2/8] syscalls.cc: Deduplicate remove Ben Wijen
2021-01-22 12:22 ` Corinna Vinschen
2021-01-22 15:47 ` [PATCH v3 " Ben Wijen
2021-01-25 18:58 ` Corinna Vinschen
2021-01-20 16:10 ` [PATCH v2 3/8] Cygwin: Move post-dir unlink check Ben Wijen
2021-01-22 12:35 ` Corinna Vinschen
2021-01-20 16:10 ` [PATCH v2 4/8] syscalls.cc: Implement non-path_conv dependent _unlink_nt Ben Wijen
2021-01-26 11:34 ` Corinna Vinschen
2021-02-03 11:03 ` Ben
2021-02-04 19:29 ` Corinna Vinschen
2021-01-20 16:10 ` [PATCH v2 5/8] path.cc: Allow to skip filesystem checks Ben Wijen
2021-01-20 16:10 ` [PATCH v2 6/8] syscalls.cc: Expose shallow-pathconv unlink_nt Ben Wijen
2021-01-26 11:45 ` Corinna Vinschen
2021-01-20 16:10 ` [PATCH v2 7/8] dir.cc: Try unlink_nt first Ben Wijen
2021-01-26 11:46 ` Corinna Vinschen
2021-01-27 9:22 ` Ben
2021-01-20 16:10 ` [PATCH v2 8/8] fhandler_disk_file.cc: Use path_conv's IndexNumber Ben Wijen
2021-01-26 12:15 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210122105201.GD810271@calimero.vinschen.de \
--to=corinna-cygwin@cygwin.com \
--cc=cygwin-patches@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).