This is the mail archive of the cygwin-cvs@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]