]> sourceware.org Git - newlib-cygwin.git/commitdiff
* fhandler_disk_file.cc (fhandler_base::fstat_helper): Try harder
authorCorinna Vinschen <corinna@vinschen.de>
Tue, 24 Jan 2006 12:32:33 +0000 (12:32 +0000)
committerCorinna Vinschen <corinna@vinschen.de>
Tue, 24 Jan 2006 12:32:33 +0000 (12:32 +0000)
to determine remote file systems with reliable inode numbers.  Add
longish comment.

winsup/cygwin/ChangeLog
winsup/cygwin/fhandler_disk_file.cc

index cae5ee6af4c804e7bbe993e70477b4b60ada580b..c808f28b9c1a418317f0727182a0cf42276180cc 100644 (file)
@@ -1,3 +1,9 @@
+2006-01-24  Corinna Vinschen  <corinna@vinschen.de>
+
+       * fhandler_disk_file.cc (fhandler_base::fstat_helper): Try harder
+       to determine remote file systems with reliable inode numbers.  Add
+       longish comment.
+
 2006-01-23  Corinna Vinschen  <corinna@vinschen.de>
 
        * fhandler_socket.cc (fhandler_socket::fixup_after_fork): Reset
index ce0738b4a55b8e6cd2a5469180e4be26bf8abb40..ab277815b411b8c83b92fdafdfcc9ab74ab51dde 100644 (file)
@@ -326,14 +326,36 @@ fhandler_base::fstat_helper (struct __stat64 *buf,
     case DRIVE_REMOVABLE:
     case DRIVE_CDROM:
     case DRIVE_RAMDISK:
-    /* Temporarily enable remote drives until we find out why we disabled them
-       in the first place. When we find out don't forget to write a comment! */
-    case DRIVE_REMOTE:
       /* Although the documentation indicates otherwise, it seems like
         "inodes" on these devices are persistent, at least across reboots. */
       buf->st_ino = (((__ino64_t) nFileIndexHigh) << 32)
                    | (__ino64_t) nFileIndexLow;
       break;
+
+    case DRIVE_REMOTE:
+      /* From own experiments and replies from the Cygwin mailing list,
+        we're now trying to figure out how to determine remote file
+        systems which are capable of returning persistent inode
+        numbers.  It seems that NT4 NTFS, when accessed remotly, and
+        some other remote file systems return unreliable values in
+        nFileIndex.  The common factor of these unreliable remote FS
+        seem to be that FILE_SUPPORTS_OBJECT_IDS isn't set, even though
+        this should have nothing to do with inode numbers.
+        An exception is Samba, which seems to return valid inode numbers
+        without having the FILE_SUPPORTS_OBJECT_IDS flag set.  So we're
+        testing for the flag values returned by a 3.x Samba explicitely
+        for now. */
+#define FS_IS_SAMBA (FILE_CASE_SENSITIVE_SEARCH \
+                    | FILE_CASE_PRESERVED_NAMES \
+                    | FILE_PERSISTENT_ACLS)
+      if ((pc.fs_flags () & FILE_SUPPORTS_OBJECT_IDS)
+         || pc.fs_flags  () == FS_IS_SAMBA)
+       {
+         buf->st_ino = (((__ino64_t) nFileIndexHigh) << 32)
+                       | (__ino64_t) nFileIndexLow;
+         break;
+       }
+      /*FALLTHRU*/
     default:
       /* Either the nFileIndex* fields are unreliable or unavailable.  Use the
         next best alternative. */
This page took 0.034976 seconds and 5 git commands to generate.