Custom Query (245 matches)

The coreutils chmod.exe does not modify the mode attribute if MODE EA is not present in the file.

The attached patch fixes two problems in chmod():

1) libc_back_fsUnixAttribsGetMode returns -ENOTSUP when EA are not supported by file system and EA are not present on file. Probably the two error conditions should be split, but in this case we can go on even if EA are not supported, we will fail in the DosSetPathInfo? call.

2) the MODE field contains also the bits to specify the kind of handle (dir, file, socket, ...) and these bits are not initialized, so when MODE is read back it is reported as zero. This bit is handled inside the backend function, I don't know if it must be handled before reaching the final steps.

Index: src/lib/sys/b_fsNativeFileModeSet.c
===================================================================
--- src/lib/sys/b_fsNativeFileModeSet.c	(revision 3650)
+++ src/lib/sys/b_fsNativeFileModeSet.c	(working copy)
@@ -50,7 +50,7 @@
  *
  * @returns 0 on success.
  * @returns Negative error code (errno.h) on failure.
- * @param   fh      Handle to file.
+ * @param   pszNativePath   Path to the file to change.
  * @param   Mode    The filemode.
  */
 int __libc_back_fsNativeFileModeSet(const char *pszNativePath, mode_t Mode)
@@ -160,12 +160,25 @@
     {
         mode_t CurMode;
         rc = __libc_back_fsUnixAttribsGetMode(-1, pszNativePath, &CurMode);
-        if (__predict_true(!rc))
+	// YD -ENOTSUP is returned if EA not supported or not present!
+	// in the latter case, we need to continue
+        if (__predict_true(!rc) || rc==-ENOTSUP)
         {
             /* correct the passed in Mode mask. */
             Mode &= ALLPERMS; /** @todo sticky bit and set uid/gid access validation... */
             Mode |= CurMode & ~ALLPERMS;
 
+#if OFF_MAX > LONG_MAX
+            ULONG fAttributtes = fLarge ? info.fsts4L.attrFile : info.fsts4.attrFile;
+#else
+            ULONG fAttributtes = info.fsts4.attrFile;
+#endif
+
+            if (fAttributtes & FILE_DIRECTORY)
+                Mode |= S_IFDIR;
+            else
+                Mode |= S_IFREG;
+
             /* construct FEA2 stuff. */
             #pragma pack(1)
             struct __LIBC_FSUNIXATTRIBSSETMODE

Also the NDFS32 file system driver can handle extended attributes, at least with SMB plugin. Probably also the local and ramfs plugins could too.

Unfortunately this feature depends on the plugin used and so it depends on the mounted resource. This means a NDFS32 drive can handle EAs for some directories only.

The following patch enables EAs for NDFS32 too:

Index: fs.c
===================================================================
--- fs.c	(revision 3650)
+++ fs.c	(working copy)
@@ -1817,6 +1817,7 @@
         strncat(pFsInfo->szName, (const char *)&pfsqb->szName[pfsqb->cbName + 1], sizeof(pFsInfo->szName) - 1);
     if (    !strcmp(pFsInfo->szName, "JFS")
         ||  !strcmp(pFsInfo->szName, "HPFS")
+        ||  !strcmp(pFsInfo->szName, "NDFS32")
         ||  !strcmp(pFsInfo->szName, "FAT"))
     {
         pFsInfo->fZeroNewBytes  = 1;

I wonder what happens if drives are added/removed while a libc program is running, not only for netdrive but also for lvm.

When compiling with -std=c99 or -std=gnu99, the extern inline keywords changes meaning. GCC 4.3 conforms to the ISO C99 specification, where extern inline is very different thing than the GNU extern inline extension.

If the old GNU extern inline behavior is desired, one can use extern inline attribute((gnu_inline)).

Only stdio.h have this problem.

Link: ​http://gcc.gnu.org/gcc-4.3/porting_to.html