From 8b6804b8a8816be67843d694851331d97909998e Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Fri, 9 Mar 2018 21:13:28 +0100 Subject: [PATCH] Cygwin: don't skip O_TMPFILE files in readdir Bad idea. A file hidden from directory listings is not seen by rm either, so it never calls unlink for the file and a recursive removal of the parent directory fails with "directory not empty". Fix comments accordingly. Signed-off-by: Corinna Vinschen --- winsup/cygwin/fhandler_disk_file.cc | 24 +++++++++--------------- 1 file changed, 9 insertions(+), 15 deletions(-) diff --git a/winsup/cygwin/fhandler_disk_file.cc b/winsup/cygwin/fhandler_disk_file.cc index 66ebee8c6..fc87d91c1 100644 --- a/winsup/cygwin/fhandler_disk_file.cc +++ b/winsup/cygwin/fhandler_disk_file.cc @@ -1249,19 +1249,18 @@ fhandler_disk_file::link (const char *newpath) /* An O_TMPFILE file has FILE_ATTRIBUTE_TEMPORARY and FILE_ATTRIBUTE_HIDDEN set. After a successful hardlink the file is not temporary anymore in the usual sense. So we remove these - attributes here, even if this makes the original link (temporarily) - visible in directory enumeration. + attributes here. Note that we don't create a reopen attribute for the original link but rather a normal attribute for the just created link. - The reason is a curious behaviour of Windows: If we remove - the O_TMPFILE attributes on the original link, the new link - will not show up in file system listings, long after the original - link has been closed and removed. The file and its metadata will - be kept in memory only as long as Windows sees fit. By opening - the new link, we request the attribute changes on the new link, - so after closing it Windows will have an increased interest to - write back the metadata. */ + The reason is a curious behaviour of Windows: If we remove the + O_TMPFILE attributes on the original link, the new link will not + show up in file system listings (not even native ones from , e.g., + `cmd /c dir'), long after the original link has been closed and + removed. The file and its metadata will be kept in memory only + as long as Windows sees fit. By opening the new link, we request + the attribute changes on the new link, so after closing it Windows + will have an increased interest to write back the metadata. */ OBJECT_ATTRIBUTES attr; status = NtOpenFile (&fh, FILE_WRITE_ATTRIBUTES, newpc.get_object_attr (attr, sec_none_nih), &io, @@ -2107,7 +2106,6 @@ fhandler_disk_file::readdir (DIR *dir, dirent *de) /* d_cachepos always refers to the next cache entry to use. If it's 0 we must reload the cache. */ -restart: FileAttributes = 0; if (d_cachepos (dir) == 0) { @@ -2222,10 +2220,6 @@ go_ahead: FileAttributes = ((PFILE_BOTH_DIR_INFORMATION) buf)->FileAttributes; } - /* We don't show O_TMPFILE files in the filesystem. This is a kludge, - so we may end up removing this snippet again. */ - if ((FileAttributes & O_TMPFILE_FILE_ATTRS) == O_TMPFILE_FILE_ATTRS) - goto restart; RtlInitCountedUnicodeString (&fname, FileName, FileNameLength); d_mounts (dir)->check_mount (&fname); if (de->d_ino == 0 && (dir->__flags & dirent_set_d_ino))