This is the mail archive of the
cygwin-cvs@cygwin.com
mailing list for the Cygwin project.
[newlib-cygwin] Cygwin: don't skip O_TMPFILE files in readdir
- From: Corinna Vinschen <corinna at sourceware dot org>
- To: cygwin-cvs at sourceware dot org
- Date: 9 Mar 2018 20:15:52 -0000
- Subject: [newlib-cygwin] Cygwin: don't skip O_TMPFILE files in readdir
https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=8b6804b8a8816be67843d694851331d97909998e
commit 8b6804b8a8816be67843d694851331d97909998e
Author: Corinna Vinschen <corinna@vinschen.de>
Date: Fri Mar 9 21:13:28 2018 +0100
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 <corinna@vinschen.de>
Diff:
---
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 66ebee8..fc87d91 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))