https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;h=8b6804b8a8816be67843d694851331d97909998e

commit 8b6804b8a8816be67843d694851331d97909998e
Author: Corinna Vinschen <[email protected]>
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 <[email protected]>

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))

Reply via email to