Re: modify chmod
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;
+
+ /* If statfs fails, assume we can't use the optimization. */
+ if (statfs (file, buf) 0)
This function should accept a file descriptor, not a file name,
and should call fstatfs, not statfs.
Thanks for the correction.
IMHO, to get a fd, then call fstatfs ranther than statfs here, is to
ensure the same file object proceeding to operated on?
For your next version of this patch, please find a way to send
it that does not split lines or remove leading spaces.
I will take care for this kind of formating issues.
Re: modify chmod
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
+ struct statfs buf;
+
+ /* If statfs fails, assume we can't use the optimization. */
+ if (statfs (file, buf) 0)
This function should accept a file descriptor, not a file name,
and should call fstatfs, not statfs.
Thanks for the correction.
IMHO, to get a fd, then call fstatfs ranther than statfs here, is to
ensure the same file object proceeding to operated on?
fts provides a file descriptor for every directory it processes,
so you can use an FTS_ENT const *ent parameter instead.
When it refers to a directory, use ent-fts_fts-fts_cwd_fd as the
file descriptor. Otherwise, you will have to call statfs after all.
At first, I was thinking we could avoid statfs most of the time (i.e.,
change device only at a directory), but with bind-mounted regular files,
the device can change at any time during a traversal.
Re: modify chmod
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 HAVE_SYS_STATFS_H HAVE_STRUCT_STATFS_F_TYPE
+ struct statfs buf;
+
+ /* If statfs fails, assume we can't use the optimization. */
+ if (statfs (file, buf) 0)
This function should accept a file descriptor, not a file name,
and should call fstatfs, not statfs.
Thanks for the correction.
IMHO, to get a fd, then call fstatfs ranther than statfs here, is to
ensure the same file object proceeding to operated on?
fts provides a file descriptor for every directory it processes,
so you can use an FTS_ENT const *ent parameter instead.
When it refers to a directory, use ent-fts_fts-fts_cwd_fd as the
file descriptor. Otherwise, you will have to call statfs after all.
thanks for the point out.
Actually, by consulting your primary comments for using fstatfs(2),
I was also thought the only way is pass the fts_cwd_fd to it,
then I started to study the fts_() series functions and added debugging
instruments to check the fts_cwd_fd value againt a five-depth directory.
but at that time, I found many -100(AT_FDCWD) printed out somehow.
so I took it for granted to call statfs since it can save the time if do not
need to check the fts_cwd_fd against AT_FDCWD frequently.
At first, I was thinking we could avoid statfs most of the time (i.e.,
change device only at a directory), but with bind-mounted regular files,
the device can change at any time during a traversal.
Re: modify chmod
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 that chmod processes. The above works for all readable objects. For unreadable ones, revert to using the statfs with the full relative name.
[REQUEST] - wget style status bar for cp
Gentlemen, Just wondering if there was, or could be some consideration taken into adding an option to the cp command to show a per file status bar? Would be nice to have the option to see how far along large files are when being transfered using cp. Something fairly simple like the one wget features would be fantastic. Cheers, Tw33k^
3 small patches coming soon
Since I'm using this help-version script in gzip and grep (and a few
other projects), I've added their settings to coreutils, solely to help
keep this shared file in sync.
[PATCH 1/3] tests: include help-version test settings used by gzip and grep
[PATCH 2/3] doc: add a cross reference from tac's man page to rev
[PATCH 3/3] copy.c: improve a comment
From 86573d33a70248bb67567272629af9841ae2f562 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 7 Feb 2010 12:16:34 +0100
Subject: [PATCH 1/3] tests: include help-version test settings used by gzip and
grep
* tests/misc/help-version: ...the better to keep this file in sync.
---
tests/misc/help-version | 49 --
1 files changed, 46 insertions(+), 3 deletions(-)
diff --git a/tests/misc/help-version b/tests/misc/help-version
index 6202dee..063c3eb 100755
--- a/tests/misc/help-version
+++ b/tests/misc/help-version
@@ -43,6 +43,19 @@ expected_failure_status_dir=2
expected_failure_status_ls=2
expected_failure_status_vdir=2
+expected_failure_status_cmp=2
+expected_failure_status_zcmp=2
+expected_failure_status_sdiff=2
+expected_failure_status_diff3=2
+expected_failure_status_diff=2
+expected_failure_status_zdiff=2
+expected_failure_status_zgrep=2
+expected_failure_status_zegrep=2
+expected_failure_status_zfgrep=2
+
+expected_failure_status_grep=2
+expected_failure_status_egrep=2
+expected_failure_status_fgrep=2
test $built_programs \
|| { echo $this_test: no programs built!?! 12; Exit 1; }
@@ -90,6 +103,10 @@ for lang in C fr da; do
done
done
+bigZ_in=bigZ-in.Z
+zin=zin.gz
+zin2=zin2.gz
+
tmp=tmp-$$
tmp_in=in-$$
tmp_in2=in2-$$
@@ -123,6 +140,24 @@ cmp_args=$tmp_in $tmp_in2
# The transfer rate would vary between runs.
dd_args=status=noxfer
+zdiff_args=$zin $zin2
+zcmp_args=$zin $zin2
+zcat_args=$zin
+gunzip_args=$zin
+zmore_args=$zin
+zless_args=$zin
+znew_args=$bigZ_in
+zforce_args=$zin
+zgrep_args=z $zin
+zegrep_args=z $zin
+zfgrep_args=z $zin
+gzexe_args=$tmp_in
+
+# We know that $tmp_in contains a 0
+grep_args=0 $tmp_in
+egrep_args=0 $tmp_in
+fgrep_args=0 $tmp_in
+
diff_args=$tmp_in $tmp_in2
sdiff_args=$tmp_in $tmp_in2
diff3_args=$tmp_in $tmp_in2 $tmp_in2
@@ -188,9 +223,17 @@ for i in $built_programs; do
# Skip these.
case $i in chroot|stty|tty|false|chcon|runcon) continue;; esac
- rm -rf $tmp_in $tmp_in2 $tmp_dir $tmp_out
- echo $tmp_in
- echo $tmp_in2
+ rm -rf $tmp_in $tmp_in2 $tmp_dir $tmp_out $bigZ_in $zin $zin2
+ echo z |gzip $zin
+ cp $zin $zin2
+ cp $zin $bigZ_in
+
+ # This is sort of kludgey: use numbers so this is valid input for factor,
+ # and two tokens so it's valid input for tsort.
+ echo 2147483647 0 $tmp_in
+ # Make $tmp_in2 identical. Then, using $tmp_in and $tmp_in2 as arguments
+ # to the likes of cmp and diff makes them exit successfully.
+ cp $tmp_in $tmp_in2
mkdir $tmp_dir
# echo == $i
test $i = [ prog=lbracket || prog=$i
--
1.7.0.rc1.214.gd5f8a
From 543696a9af2d25bec0708b6b790102c01910b5ff Mon Sep 17 00:00:00 2001
From: James R. Van Zandt j...@debian.org
Date: Sun, 7 Feb 2010 16:36:13 +0100
Subject: [PATCH 2/3] doc: add a cross reference from tac's man page to rev
* man/tac.x: See also rev.
---
man/tac.x |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/man/tac.x b/man/tac.x
index d943afa..7d3821c 100644
--- a/man/tac.x
+++ b/man/tac.x
@@ -2,3 +2,5 @@
tac \- concatenate and print files in reverse
[DESCRIPTION]
.\ Add any additional description here
+[SEE ALSO]
+\fBrev\fP(1).
--
1.7.0.rc1.214.gd5f8a
From ed509250a2c9436ba1f2fd013b0f192abd3906f2 Mon Sep 17 00:00:00 2001
From: Jim Meyering meyer...@redhat.com
Date: Sun, 7 Feb 2010 21:02:18 +0100
Subject: [PATCH 3/3] copy.c: improve a comment
* src/copy.c (copy_reg): The comment about POSIXLY_CORRECT refers
only to cp, not to any other application that uses copy.c.
---
src/copy.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/src/copy.c b/src/copy.c
index 80ec362..8399b71 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -587,10 +587,11 @@ copy_reg (char const *src_name, char const *dst_name,
lstat'ing the DST_NAME shows that it is a symlink, then we
have a problem: trying to resolve this dangling symlink to
a directory/destination-entry pair is fundamentally racy,
- so punt. If POSIXLY_CORRECT is set, simply call open again,
- but without O_EXCL (potentially dangerous). If not, fail
- with a diagnostic. These shenanigans are necessary only
- when copying, i.e., not in move_mode. */
+ so punt. If x-open_dangling_dest_symlink is set (cp sets
+ that when POSIXLY_CORRECT is set in the environment), simply
+ call open again, but without O_EXCL (potentially dangerous).
+ If not, fail with a diagnostic. These shenanigans are necessary
+ only when copying, i.e., not in move_mode. */
Re: [REQUEST] - wget style status bar for cp
On 07/02/10 16:58, Tw33k ^ wrote: Gentlemen, Just wondering if there was, or could be some consideration taken into adding an option to the cp command to show a per file status bar? Would be nice to have the option to see how far along large files are when being transfered using cp. Something fairly simple like the one wget features would be fantastic. This has been discussed before, most recently at: http://lists.gnu.org/archive/html/bug-coreutils/2009-11/msg3.html cheers, Pádraig.
