public inbox for cygwin-cvs@sourceware.org help / color / mirror / Atom feed
From: Corinna Vinschen <corinna@sourceware.org> To: cygwin-cvs@sourceware.org Subject: [newlib-cygwin/main] Cygwin: don't use unlink/rename POSIX semantics on certain NTFS Date: Tue, 21 Mar 2023 17:30:34 +0000 (GMT) [thread overview] Message-ID: <20230321173034.3A0A23857C5A@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=fe2545e9faaf4bf9586f61a7b83d5cb5af501194 commit fe2545e9faaf4bf9586f61a7b83d5cb5af501194 Author: Corinna Vinschen <corinna@vinschen.de> AuthorDate: Tue Mar 21 18:29:59 2023 +0100 Commit: Corinna Vinschen <corinna@vinschen.de> CommitDate: Tue Mar 21 18:29:59 2023 +0100 Cygwin: don't use unlink/rename POSIX semantics on certain NTFS If a host NTFS is mapped into a Hyper-V isolated container, the OPEN_BY_FILE_ID filesystem flag is missing, just as if that NTFS is a remote drive. However, NtQueryVolumeInformationFile claims the drive is a local drive. We can use this fact to learn that the process is running under Hyper-V, and that the Hyper-V isolated process can't use rename/unlink with POSIX semantics. Strange enough, the POSIX_UNLINK_RENAME filesystem flag is still set... Signed-off-by: Corinna Vinschen <corinna@vinschen.de> Diff: --- winsup/cygwin/syscalls.cc | 14 +++++++++----- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/winsup/cygwin/syscalls.cc b/winsup/cygwin/syscalls.cc index af4f870851eb..3e2d42f3aa8b 100644 --- a/winsup/cygwin/syscalls.cc +++ b/winsup/cygwin/syscalls.cc @@ -691,10 +691,12 @@ unlink_nt (path_conv &pc, bool shareable) pc.get_object_attr (attr, sec_none_nih); /* First check if we can use POSIX unlink semantics: W10 1709+, local NTFS. - With POSIX unlink semantics the entire job gets MUCH easier and faster. - Just try to do it and if it fails, it fails. */ + For the OPEN_BY_FILE_ID flag, see MINIMAL_WIN_NTFS_FLAGS comment in + fs_info::update. With POSIX unlink semantics the entire job gets MUCH + easier and faster. Just try to do it and if it fails, it fails. */ if (wincap.has_posix_unlink_semantics () - && !pc.isremote () && pc.fs_is_ntfs ()) + && !pc.isremote () && pc.fs_is_ntfs () + && pc.has_attribute (FILE_SUPPORTS_OPEN_BY_FILE_ID)) { FILE_DISPOSITION_INFORMATION_EX fdie; @@ -2407,10 +2409,12 @@ rename2 (const char *oldpath, const char *newpath, unsigned int at2flags) __leave; } - /* POSIX semantics only on local NTFS drives. */ + /* POSIX semantics only on local NTFS drives. For the OPEN_BY_FILE_ID + flag, see MINIMAL_WIN_NTFS_FLAGS comment in fs_info::update. */ use_posix_semantics = wincap.has_posix_rename_semantics () && !oldpc.isremote () - && oldpc.fs_is_ntfs (); + && oldpc.fs_is_ntfs () + && oldpc.has_attribute (FILE_SUPPORTS_OPEN_BY_FILE_ID); /* Opening the file must be part of the transaction. It's not sufficient to call only NtSetInformationFile under the transaction. Therefore we
reply other threads:[~2023-03-21 17:30 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20230321173034.3A0A23857C5A@sourceware.org \ --to=corinna@sourceware.org \ --cc=cygwin-cvs@sourceware.org \ /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: linkBe 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).