cp -x fails to preserve mount point permissions
To whom it may concern: There seems to be a bug in cp of coreutils 6.7 which causes the permissions of mount point directories to not get preserved properly when using the -x/--one-file-system option. For example: # mkdir /foo /foo/bar # mount /dev/sdb1 /foo/bar # ls -l /foo total 4 drwxrwxrwt 3 root root 4096 Mar 3 06:09 bar # mkdir /quux # cp -ax /foo /quux/ # ls -l /quux/foo total 4 drwx-T 2 root root 4096 Mar 3 06:36 bar While the code in copy_internal() is sufficiently complex that I haven't investigated it thoroughly, the following check at line 1597 of copy.c seems suspicious: if (x-one_file_system device != 0 device != src_sb.st_dev) return true; This is immediately after the directory is created, so there is no opportunity to set any permission bits which may have been masked out by the umask. The following patch may or may not be correct, but it seems to solve the problem for my case. diff -urN ../coreutils-6.7-orig/src/copy.c src/copy.c --- ../coreutils-6.7-orig/src/copy.c2006-12-07 16:01:16 +0900 +++ src/copy.c 2007-03-03 06:41:14 +0900 @@ -1595,7 +1595,8 @@ /* Are we crossing a file system boundary? */ if (x-one_file_system device != 0 device != src_sb.st_dev) - return true; + delayed_ok = true; + else /* Copy the contents of the directory. */ --Andrew Church [EMAIL PROTECTED] http://achurch.org/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls gets confused by IFS environment variable
LS gets confused as soon as the IFS environment variable only contains control characters. # IFS contains an NL only: bash IFS=$(echo -e \n) ls /bin/ls: Ungültige Option -- „/bin/ls --help“ gibt weitere Informationen. # IFS contains TAB,NL and SPACE: IFS=$(echo -e \t\n) ls -1 bin boot dev ... Strange! There is also nothing about IFS in the man or info pages of ls. Why has IFS an influence on ls at all? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[Fwd: ls gets confused by IFS environment variable]
coreutils-5.93-20 ---BeginMessage--- LS gets confused as soon as the IFS environment variable only contains control characters. # IFS contains an NL only: bash IFS=$(echo -e \n) ls /bin/ls: Ungültige Option -- „/bin/ls --help“ gibt weitere Informationen. # IFS contains TAB,NL and SPACE: IFS=$(echo -e \t\n) ls -1 bin boot dev ... Strange! There is also nothing about IFS in the man or info pages of ls. Why has IFS an influence on ls at all? ---End Message--- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
BUG REPORT
hi my name is Julio Axel and well i was play with cut comand and i was trying to cut som fields from a file and i saw the comand is very nice when you try to extract 1,3,4 field but if you try to subtract 4 and 1 field in this order the command filed, and i saw when any user try to cut in one specific way to get a special format the comand don´t run ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: ls gets confused by IFS environment variable
Elmar Stellnberger [EMAIL PROTECTED] writes: LS gets confused as soon as the IFS environment variable only contains control characters. The ls program does not use the IFS environment variable in any way. # IFS contains an NL only: bash IFS=$(echo -e \n) ls /bin/ls: Ungültige Option -- „/bin/ls --help“ gibt weitere Informationen. Try running /bin/ls directly, you problably have a shell alias or function with the name `ls', which depends on proper word splitting. Why has IFS an influence on ls at all? It hasn't. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 And now for something completely different. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: BUG REPORT
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Axel Colunga on 3/3/2007 2:30 AM: hi my name is Julio Axel and well i was play with cut comand and i was trying to cut som fields from a file and i saw the comand is very nice when you try to extract 1,3,4 field but if you try to subtract 4 and 1 field in this order the command filed, and i saw when any user try to cut in one specific way to get a special format the comand don´t run Thanks for the bug report. However, it is difficult to follow what you are trying to do. Actually showing the command line you used, what actually happened, and what you expected to happen, on a sample file, would be more useful for us to be able to tell you whether it is really a bug in cut or more likely a misunderstanding on how cut operates. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF6ZUT84KuGfSFAYARAovNAKCc+6eZBCoFGU5kuWih/7Hho5bAYACgpVDX SNPZu0rC98KoVmVGzwedkuo= =QapP -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -x fails to preserve mount point permissions
[EMAIL PROTECTED] (Andrew Church) writes:
The following patch may or may not be correct, but it seems to
solve the problem for my case.
Thanks for catching this problem. Too bad it's hard to write a portable
test case for it.
The patch looks correct to me, but how about this patch instead? It
tries to make the code a bit clearer (and a tiny bit faster).
2007-03-03 Paul Eggert [EMAIL PROTECTED]
* src/copy.c (copy_internal): Don't return immediately after
copying a mount point that we do not intend to recurse under.
This fixes a bug where we didn't set the correct permissions
for the mount point. Problem reported by Andrew Church.
diff --git a/src/copy.c b/src/copy.c
index 000c248..8de4f80 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1604,19 +1604,16 @@ copy_internal (char const *src_name, char const
*dst_name,
emit_verbose (src_name, dst_name, NULL);
}
- /* Are we crossing a file system boundary? */
- if (x-one_file_system device != 0 device != src_sb.st_dev)
- return true;
-
- /* Copy the contents of the directory. */
-
- if (! copy_dir (src_name, dst_name, new_dst, src_sb, dir, x,
- copy_into_self))
+ /* Are we staying in the file system, or do we not care? */
+ if (! x-one_file_system || device == 0 || device == src_sb.st_dev)
{
- /* Don't just return here -- otherwise, the failure to read a
-single file in a source directory would cause the containing
-destination directory not to have owner/perms set properly. */
- delayed_ok = false;
+ /* Copy the contents of the directory. Don't just return if
+this fails -- otherwise, the failure to read a single
+file in a source directory would cause the containing
+destination directory not to have owner/perms set
+properly. */
+ delayed_ok = copy_dir (src_name, dst_name, new_dst, src_sb, dir, x,
+copy_into_self);
}
}
else if (x-symbolic_link)
M ChangeLog
M src/copy.c
Committed as 293658fb3621376f0b51c54f1258d67dbb40d090
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: cp -x fails to preserve mount point permissions
Paul Eggert [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] (Andrew Church) writes:
The following patch may or may not be correct, but it seems to
solve the problem for my case.
Thanks for catching this problem. Too bad it's hard to write a portable
test case for it.
The patch looks correct to me, but how about this patch instead? It
tries to make the code a bit clearer (and a tiny bit faster).
Thanks to both of you.
I've checked in a change that looks a little different still.
I prefer not to negate that expression, since doing that makes
it less readable.
Andrew, the tiny change is not a reflection on the value
of your patch :-), but merely on its size -- it's a note that
since it's small enough that we don't need copyright papers from you.
2007-03-03 Andrew Church [EMAIL PROTECTED] (tiny change)
Paul Eggert [EMAIL PROTECTED]
Fix a bug: cp -x would fail to set mount point permissions.
* NEWS: mention cp -x bug fix
* src/copy.c (copy_internal): Don't return immediately after
copying a mount point that we do not intend to recurse under.
Based on a patch by Andrew Church.
diff --git a/NEWS b/NEWS
index 65a7d52..57c51e1 100644
--- a/NEWS
+++ b/NEWS
@@ -4,6 +4,8 @@ GNU coreutils NEWS-*-
outline -*-
** Bug fixes
+ cp -x (--one-file-system) would fail to set mount point permissions
+
The default block size and output format for df -P are now unaffected by
the DF_BLOCK_SIZE, BLOCK_SIZE, and BLOCKSIZE environment variables. It
is still affected by POSIXLY_CORRECT, though.
diff --git a/src/copy.c b/src/copy.c
index 000c248..49bbb8c 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -1604,19 +1604,20 @@ copy_internal (char const *src_name, char const
*dst_name,
emit_verbose (src_name, dst_name, NULL);
}
- /* Are we crossing a file system boundary? */
+ /* Decide whether to copy the contents of the directory. */
if (x-one_file_system device != 0 device != src_sb.st_dev)
- return true;
-
- /* Copy the contents of the directory. */
-
- if (! copy_dir (src_name, dst_name, new_dst, src_sb, dir, x,
- copy_into_self))
{
- /* Don't just return here -- otherwise, the failure to read a
-single file in a source directory would cause the containing
-destination directory not to have owner/perms set properly. */
- delayed_ok = false;
+ /* Here, we are crossing a file system boundary and cp's -x option
+is in effect: so don't copy the contents of this directory. */
+ }
+ else
+ {
+ /* Copy the contents of the directory. Don't just return if
+this fails -- otherwise, the failure to read a single file
+in a source directory would cause the containing destination
+directory not to have owner/perms set properly. */
+ delayed_ok = copy_dir (src_name, dst_name, new_dst, src_sb, dir, x,
+copy_into_self);
}
}
else if (x-symbolic_link)
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
new snapshot
Another new snapshot. This includes fixes for the cp -x bug and for an ia64/linux-specific failure of the pwd-unreadable-parent test: http://meyering.net/cu/coreutils-6.8+.tar.gz ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
