Hi Jim,
Thanks for your so detailed instruction! And sorry for my later response, I
just back from travel.
Could you please check my comments inline?
Jim Meyering wrote:
jeff.liu wrote:
jeff.liu 写道:
Jim Meyering 写道:
Finally, I see the one true way ;-)
Do this for each name:
- open
jeff.liu wrote:
Hi Jim,
Thanks for your so detailed instruction! And sorry for my later response, I
just back from travel.
Could you please check my comments inline?
...
This is the most important point:
[*] This change is intended to be an optimization.
I am leery of letting an
jeff.liu wrote:
Jim Meyering wrote:
jeff.liu wrote:
Hi Jim,
Thanks for your so detailed instruction! And sorry for my later response, I
just back from travel.
Could you please check my comments inline?
...
This is the most important point:
[*] This change is intended to be an
Jim Meyering wrote:
jeff.liu wrote:
Jim Meyering wrote:
jeff.liu wrote:
Hi Jim,
Thanks for your so detailed instruction! And sorry for my later response,
I just back from travel.
Could you please check my comments inline?
...
This is the most important point:
[*] This change is
jeff.liu wrote:
jeff.liu 写道:
Jim Meyering 写道:
Finally, I see the one true way ;-)
Do this for each name:
- open each file/dir. with fd = openat (fts_cwd_fd, name, ...
- if that succeeds, then call fstatfs (fd, ...
Using the combination of openat and fstatfs is required in order to
Jim Meyering 写道:
Finally, I see the one true way ;-)
Do this for each name:
- open each file/dir. with fd = openat (fts_cwd_fd, name, ...
- if that succeeds, then call fstatfs (fd, ...
Using the combination of openat and fstatfs is required in order to
avoid using the full
jeff.liu 写道:
Jim Meyering 写道:
Finally, I see the one true way ;-)
Do this for each name:
- open each file/dir. with fd = openat (fts_cwd_fd, name, ...
- if that succeeds, then call fstatfs (fd, ...
Using the combination of openat and fstatfs is required in order to
avoid using the
Jim Meyering 写道:
jeff.liu wrote:
A tiny patch, make chmod do not touch the inode if the new file
permission mode is same as it was before.
...
+static bool
+may_have_nfsacl(const char *file)
+{
+# if HAVE_SYS_VFS_H HAVE_SYS_STATFS_H HAVE_STRUCT_STATFS_F_TYPE
+ struct statfs buf;
jeff.liu wrote:
Jim Meyering 写道:
jeff.liu wrote:
A tiny patch, make chmod do not touch the inode if the new file
permission mode is same as it was before.
...
+static bool
+may_have_nfsacl(const char *file)
+{
+# if HAVE_SYS_VFS_H HAVE_SYS_STATFS_H HAVE_STRUCT_STATFS_F_TYPE
+
Jim Meyering 写道:
jeff.liu wrote:
Jim Meyering 写道:
jeff.liu wrote:
A tiny patch, make chmod do not touch the inode if the new file
permission mode is same as it was before.
...
+static bool
+may_have_nfsacl(const char *file)
+{
+# if HAVE_SYS_VFS_H
Finally, I see the one true way ;-)
Do this for each name:
- open each file/dir. with fd = openat (fts_cwd_fd, name, ...
- if that succeeds, then call fstatfs (fd, ...
Using the combination of openat and fstatfs is required in order to
avoid using the full relative name of each object
Eric Blake 写道:
According to jeff.liu on 2/5/2010 7:44 AM:
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 2eb5a8a0ff8348149a9ca985e2ccbfb03bc8de53
+Subproject commit 4b93a2579fb567b9fbbeb24439770d814dac95cd
Why are you modifying the gnulib submodule?
Hmm, I also wonder what's the
jeff.liu wrote:
A tiny patch, make chmod do not touch the inode if the new file
permission mode is same as it was before.
...
+static bool
+may_have_nfsacl(const char *file)
+{
+# if HAVE_SYS_VFS_H HAVE_SYS_STATFS_H HAVE_STRUCT_STATFS_F_TYPE
+ struct statfs buf;
+
+ /* If statfs fails,
From c7bc43a05e4f021db8047ecd390b4fb75368f558 Mon Sep 17 00:00:00 2001
From: Jeff Liu jeff@oracle.com
Date: Fri, 5 Feb 2010 20:45:41 +0800
Subject: [PATCH 1/1] Modify chmod v1
do not touch the inode if the new file permission bits is identical to it was before.
Signed-off-by: Jie Liu jeff
Sorry for the inconvenient, looks my email body was filtered somehow, :-(
A tiny patch, make chmod do not touch the inode if the new file
permission mode is same as it was before.
From c7bc43a05e4f021db8047ecd390b4fb75368f558 Mon Sep 17 00:00:00 2001
From: Jeff Liu jeff@oracle.com
Date: Fri, 5 Feb 2010 20:45:41 +0800
Subject: [PATCH 1/1] Modify chmod v1
do
According to jeff.liu on 2/5/2010 7:44 AM:
+++ b/gnulib
@@ -1 +1 @@
-Subproject commit 2eb5a8a0ff8348149a9ca985e2ccbfb03bc8de53
+Subproject commit 4b93a2579fb567b9fbbeb24439770d814dac95cd
Why are you modifying the gnulib submodule?
+/* Some systems only have sys/vfs.h, other systems also
jeff.liu wrote:
...
http://git.sv.gnu.org/cgit/coreutils.git/plain/HACKING
Sure, that's sounds interesting.
For the copyright assignment, Oracle did, it as a company, and the assignment
covers all the employees. :-)
Confirmed. That was easy ;-)
Just one thing need to statement
Paul Eggert wrote:
Jim Meyering j...@meyering.net writes:
This new behavior could be useful...
maybe noticeably more efficient in some cases, too.
Perhaps worth a new option, if not the default.
In rereading the old bug report, I noticed that FreeBSD is listed as the
only OS that does
jeff.liu wrote:
It looks the Modify chmod task has been in TODO list for a long time.
I have looked through the discussion thread referred to
http://bugs.debian.org/497514.
Does it make sense to make chmod do not change the inode's ctime
if the new permission bits is identical to the old
According to Jim Meyering on 1/30/2010 8:50 AM:
Does it make sense to make chmod do not change the inode's ctime
if the new permission bits is identical to the old as the default behavior?
I still think POSIX allows it. Rather than calling out chmod(2) behavior,
POSIX states that for chmod(1):
Jim Meyering j...@meyering.net writes:
This new behavior could be useful...
maybe noticeably more efficient in some cases, too.
Perhaps worth a new option, if not the default.
In rereading the old bug report, I noticed that FreeBSD is listed as the
only OS that does things the more-efficient
Hi Jim,
It looks the Modify chmod task has been in TODO list for a long time.
I have looked through the discussion thread referred to
http://bugs.debian.org/497514.
Does it make sense to make chmod do not change the inode's ctime
if the new permission bits is identical to the old as the default
29 matches
Mail list logo
