Re: [PATCH] Use getgrouplist where available.
James Youngman <[EMAIL PROTECTED]> wrote:
> 2008-02-18 James Youngman <[EMAIL PROTECTED]>
>
> * gl/m4/mgetgroups.m4: Check for getgrouplist.
> * gl/lib/mgetgroups.c (mgetgroups): Use getgrouplist, if
> available.
> * TODO: Remove the item about switching to getgrouplist.
...
Hi James,
Thanks a lot for working on this.
It was long overdue.
> diff --git a/gl/lib/mgetgroups.c b/gl/lib/mgetgroups.c
> index 6a4a422..3da1f58 100644
> --- a/gl/lib/mgetgroups.c
> +++ b/gl/lib/mgetgroups.c
> @@ -23,11 +23,29 @@
...
> + *groups = g;
> + if (max_n_groups > InitialGroupBufSize)
> + {
> + return getgrouplist (username, gid, g, &max_n_groups);
> + /* XXX: Ignoring the race with group size increase */
If/when the race hits, getgrouplist returns -1, even though *groups is
already modified, thus breaking the contract defined by the function
comments (potential leak). So this is worth fixing. See the additional
patch below.
> + }
> + else
> + {
> + /* smallbuf was big enough, so we already have our data */
> + memcpy (g, smallbuf, max_n_groups * sizeof *g);
> + return 0;
That should be "return max_n_groups;".
Returning 0 works only when smallbuf is trivially small.
> + }
> + /* getgrouplist failed, fall through and use getugroups instead. */
> +}
> + /* else no username, so fall through and use getgroups. */
> +#endif
> +
>max_n_groups = (username
> ? getugroups (0, NULL, username, gid)
> : getgroups (0, NULL));
> @@ -52,14 +110,8 @@ mgetgroups (const char *username, gid_t gid, GETGROUPS_T
> **groups)
>if (max_n_groups < 0)
>max_n_groups = 5;
>
> - if (xalloc_oversized (max_n_groups, sizeof *g))
> -{
> - errno = ENOMEM;
> - return -1;
> -}
> -
> - g = malloc (max_n_groups * sizeof *g);
> - if (g == NULL)
> + g = allocate_groupbuf (max_n_groups);
> + if (NULL == g)
Please don't use that "(NULL == variable)" style in coreutils.
With the gcc warnings I always use, there is no need.
Here are two change sets, yours with some small modifications,
and mine to fix the remaining race/contract problem:
2008-02-22 Jim Meyering <[EMAIL PROTECTED]>
id: avoid race when a group is added between getgrouplist calls
* gl/lib/mgetgroups.c (mgetgroups) [N_GROUPS_INIT]: Rename enum.
Use a larger value.
Update *groups only upon success.
Iterate upon failed getgrouplist.
>From 49f7ebaac45f4d20a70c83c8302444b64259c6d3 Mon Sep 17 00:00:00 2001
From: James Youngman <[EMAIL PROTECTED]>
Date: Thu, 21 Feb 2008 15:01:15 +0100
Subject: [PATCH] id: use getgrouplist when possible
* gl/m4/mgetgroups.m4: Check for getgrouplist.
* gl/lib/mgetgroups.c (mgetgroups): Use getgrouplist, if available.
* TODO: Remove the item about switching to getgrouplist.
* NEWS: mention this
Signed-off-by: Jim Meyering <[EMAIL PROTECTED]>
---
NEWS|3 ++
TODO| 11
gl/lib/mgetgroups.c | 67 ---
gl/m4/mgetgroups.m4 |5 ++-
4 files changed, 64 insertions(+), 22 deletions(-)
diff --git a/NEWS b/NEWS
index 5a5a0a0..b549513 100644
--- a/NEWS
+++ b/NEWS
@@ -6,6 +6,9 @@ GNU coreutils NEWS-*-
outline -*-
configure --enable-no-install-program=groups now works.
+ id now uses getgrouplist, when possible. This results in
+ much better performance when there are many users and/or groups.
+
ls no longer segfaults on files in /proc when linked with an older version
of libselinux. E.g., ls -l /proc/sys would dereference a NULL pointer.
diff --git a/TODO b/TODO
index 8d53caa..4e0b298 100644
--- a/TODO
+++ b/TODO
@@ -142,17 +142,6 @@ Add a distcheck-time test to ensure that every distributed
file is either read-only(indicating generated) or is
version-controlled and up to date.
-Implement Ulrich Drepper's suggestion to use getgrouplist rather than
- getugroups. This affects both `id' and `setuidgid', but makes a big
- difference on systems with many users and/or groups, and makes id usable
- once again on systems where access restrictions make getugroups fail.
- But first we'll need a run-test (either in an autoconf macro or at
- run time) to avoid the segfault bug in libc-2.3.2's getgrouplist.
- In that case, we'd revert to using a new (to-be-written) getgrouplist
- module that does most of what `id' already does. Or just avoid the
- buggy use of getgrouplist by never passing it a buffer of length zero.
- See http://bugzilla.redhat.com/200327
-
remove `%s' notation (now that they're all gone, add a Makefile.maint sc_
rule to ensure no new ones are added):
grep -E "\`%.{,4}s'" src/*.c
diff --git a/gl/lib/mgetgroups.c b/gl/lib/mgetgroups.c
index 6a4a422..b63436a 100644
--- a/gl/lib/mgetgroups.c
+++ b/gl/lib/mgetgroups.c
@@ -23,11 +23,27 @@
#include
#include
+#include
#include
-
+#if HAVE_GETGR
Re: [PATCH] Use getgrouplist where available.
On Fri, Feb 22, 2008 at 9:04 AM, Jim Meyering <[EMAIL PROTECTED]> wrote:
> + while (1)
> + {
> + GETGROUPS_T *h;
> + ng = getgrouplist (username, gid, g, &max_n_groups);
> + if (0 <= ng)
> + {
> + *groups = g;
> + return ng;
> + }
> +
> + /* When getgrouplist fails, it guarantees that
> +max_n_groups reflects the new number of groups. */
> +
> + h = realloc (g, max_n_groups * sizeof *h);
Shouldn't realloc here be xnrealloc?
James.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Use getgrouplist where available.
"James Youngman" <[EMAIL PROTECTED]> wrote: > On Fri, Feb 22, 2008 at 9:04 AM, Jim Meyering <[EMAIL PROTECTED]> wrote: ... >> + h = realloc (g, max_n_groups * sizeof *h); > > Shouldn't realloc here be xnrealloc? No. This function is intended to be usable from a library. I.e., no fair calling exit, which xnrealloc does when it fails. Also, the function header comment says what happens when it fails, and "exit" is not mentioned. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Use getgrouplist where available.
Jim Meyering <[EMAIL PROTECTED]> wrote:
> "James Youngman" <[EMAIL PROTECTED]> wrote:
>> On Fri, Feb 22, 2008 at 9:04 AM, Jim Meyering <[EMAIL PROTECTED]> wrote:
> ...
>>> + h = realloc (g, max_n_groups * sizeof *h);
>>
>> Shouldn't realloc here be xnrealloc?
>
> No. This function is intended to be usable from a library.
> I.e., no fair calling exit, which xnrealloc does when it fails.
>
> Also, the function header comment says what happens
> when it fails, and "exit" is not mentioned.
But I suspect your point is that I need to check for overflow.
That's true. I'm adding this:
diff --git a/gl/lib/mgetgroups.c b/gl/lib/mgetgroups.c
index 317cc7c..ba8818e 100644
--- a/gl/lib/mgetgroups.c
+++ b/gl/lib/mgetgroups.c
@@ -101,8 +101,8 @@ mgetgroups (char const *username, gid_t gid, GETGROUPS_T
**groups)
/* When getgrouplist fails, it guarantees that
max_n_groups reflects the new number of groups. */
- h = realloc (g, max_n_groups * sizeof *h);
- if (h == NULL)
+ if (xalloc_oversized (max_n_groups, sizeof *h)
+ || (h = realloc (g, max_n_groups * sizeof *h) == NULL))
{
int saved_errno = errno;
free (g);
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: [PATCH] Use getgrouplist where available.
(I have moved the discussion to the gnulib mailing list; bug-coreutils is BCC'ed) On Fri, Feb 22, 2008 at 9:27 AM, Jim Meyering <[EMAIL PROTECTED]> wrote: > No. I note your subsequent mail, and yes, I was indeed thinking about oversized allocations. > This function is intended to be usable from a library. > I.e., no fair calling exit, which xnrealloc does when it fails. > > Also, the function header comment says what happens > when it fails, and "exit" is not mentioned. While I have read many times on this list people mentioning this issue, I just didn't think about it when I wrote my previous mail. I could easily have written code using xnrealloc, and contributed to the problem of library code calling exit. It occurs to me that quite a bit of effort goes into checking for and fixing that kind of thing. It strikes me that if gnulib modules had a "not allowed to call exit" property, we could probably use a topologically sorted list of gnulib object modules to determine if a given module could call exit (or _Exit, _exit, abort, ...). That property could be verified against the declared property in the module definition automatically. Similar approaches could work for related constraints (for example, one might require modules intended to be thread-safe not to call chdir(2)). This sounds like an interesting project; I may find some time to work on it during March. James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rename("symlink-to-dir/", "name") behavior
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 1/28/2008 6:28 AM:
| According to Geoff Clare on 1/28/2008 2:57 AM:
| |>
| |> My strict reading of the current wording in draft 4 does not permit
| Linux'
| |> behavior (even though it is more useful, in my opinion), since the
| |> trailing slash on B/ means that the old argument names a directory by
| the
| |> rewritten path resolution rules in XBD 4.12 (line 3008).
| |
| | Right. The behaviour on Solaris and FreeBSD is the one required
| | by the standard. It is also the behaviour on all certified UNIX03 and
| | POSIX01 systems because a test for it is included in the tests for
| | rename() in The Open Group's UNIX03/POSIX01 test suite.
| |
| | (I just checked, and Linux does indeed fail the test, which reports an
| | unexpected ENOTDIR error.)
| |
| | Linux also gives ENOTDIR for rmdir("B/"), instead of removing A and
| | leaving B as a broken link as the standard requires.
|
| However, I find the Linux behavior (for rename at least) much friendlier,
| and would like to see the standard permit that behavior. So it sounds
| like when I write the aardvark, that both behaviors need to be permitted,
| rather than declaring existing behavior of UNIX03/POSIX01 invalid.
I wrote the aardvark along those lines, and it was rejected in yesterday's
meeting of the Austin Group. They argued that Linux is allowed to fail to
follow symlink-to-dir/ in the rename and rmdir case, but only if it
returns a different errno than ENOTDIR.
https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tpl&source=L&listname=austin-group-l&id=11349
I wonder if we would have much luck proposing a patch to the Linux kernel
folks to do just that? Otherwise, I'm afraid that coreutils mv and rmdir
will just have to remain non-POSIX-compliant on Linux because the
underlying syscall is violating semantics.
- --
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
iD8DBQFHvsGO84KuGfSFAYARAssiAKCyga5tFzqIYzaalxox9qgEu1eVAACfQD1w
1fzWlkNiV0YLqdaeU939qKI=
=a1x0
-END PGP SIGNATURE-
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rename("symlink-to-dir/", "name") behavior
Eric Blake <[EMAIL PROTECTED]> wrote: > I wrote the aardvark along those lines, and it was rejected in yesterday's > meeting of the Austin Group. They argued that Linux is allowed to fail to > follow symlink-to-dir/ in the rename and rmdir case, but only if it > returns a different errno than ENOTDIR. > > https://www.opengroup.org/sophocles/show_mail.tpl?CALLER=index.tpl&source=L&listname=austin-group-l&id=11349 Yeah, I saw that exchange. Too bad. Thanks for trying. > I wonder if we would have much luck proposing a patch to the Linux kernel > folks to do just that? Do you see another errno symbol name that makes sense? I think that ENOTDIR makes the most sense from a semantic point of view. It might be a hard sell. > Otherwise, I'm afraid that coreutils mv and rmdir > will just have to remain non-POSIX-compliant on Linux because the > underlying syscall is violating semantics. That would be neither a problem nor anything new. I think of it as a feature: I try hard to maintain POSIX compliance, but not blindly, and certainly not when doing so would make the tools behave in such an unintuitive manner. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rename("symlink-to-dir/", "name") behavior
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jim Meyering on 2/22/2008 6:09 AM: |> I wonder if we would have much luck proposing a patch to the Linux kernel |> folks to do just that? | | Do you see another errno symbol name that makes sense? | I think that ENOTDIR makes the most sense from a semantic point of view. | It might be a hard sell. The POSIX folks argued that ENOTDIR is not appropriate, since in _most_ contexts, symlink-to-dir/ (with the trailing slash) is indeed a directory according to the pathname resolution rules - it is only when you omit the trailing slash that it is not a directory; unfortunately, rename and rmdir have different semantics when you remove the trailing slash. But they also agreed that POSIX allows implementations to add additional restrictions on path resolution, and that as long as Linux does not violate the semantics of their interpretation of ENOTDIR (ie. uses a different errno, to make it clear that this is an intentional and addition implementation restriction of Linux), then the intuitive behavior is permissible as one of those implementation restrictions. ENOTSUP sounds reasonable, otherwise I think we'd have to invent a new one, maybe ESLASH "trailing slash on symlink"? - -- 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 iD8DBQFHvs3D84KuGfSFAYARAhxzAKDGDVkAClE8QiIan0+at3saz2ioAACgx7oi bwVJfWArVM0vaz0mcALAA3I= =X+lc -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
nohup breaks logname and tty commands
As we are moving from RHEL 4.x to 5.x I noticed that some scripts started failing. When I researched this I found that RHEL 4.x used coreutils 5.2.1 and RHEL 5.x used coreutils 5.97. In RHEL 4 with coreutils 5.2.1 the following works: $ /usr/bin/nohup /usr/bin/logname /usr/bin/nohup: appending output to `nohup.out' $ cat nohup.out mroth In RHEL 5 with coreutils 5.97 the following does not work: $ /usr/bin/nohup /usr/bin/logname /usr/bin/nohup: appending output to `nohup.out' $ cat nohup.out /usr/bin/logname: no login name I also checked the nohup in the coreutils 6.9 and it has the same behavior. The tty command has similar issue, not sure if other commands are effected as well. We are able to work around the issues but it creates more incompatibilities between Linux and the other Unix flavors. Thanks, Matthew Roth AT&T Services, Inc. 1010 Pine Street, Room 8-W-3, Saint Louis, Missouri 63101 (314) 331-9839, [EMAIL PROTECTED] ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup breaks logname and tty commands
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to ROTH, MATTHEW G (ATTSI) on 2/22/2008 9:06 AM: | As we are moving from RHEL 4.x to 5.x I noticed that some scripts | started failing. You may want to consider further upgrades - the latest stable version of coreutils is 6.10. | In RHEL 5 with coreutils 5.97 the following does not work: | | $ /usr/bin/nohup /usr/bin/logname | /usr/bin/nohup: appending output to `nohup.out' | | $ cat nohup.out | /usr/bin/logname: no login name I'm not sure why that is failing for you. It worked just fine for me: $ logname eblake $ nohup logname nohup: ignoring input and appending output to `nohup.out' $ cat nohup.out eblake $ nohup --version | head -n1 nohup (GNU coreutils) 6.10 $ logname --version | head -n1 logname (GNU coreutils) 6.10 Perhaps an strace would shed some light? | I also checked the nohup in the coreutils 6.9 and it has the same | behavior. The tty command has similar issue, not sure if other commands | are effected as well. Well, the tty command is SUPPOSED to be affected. POSIX allows nohup to redirect stdin so as not to hold a tty open indefinitely (the idea of nohup is to isolate a long-running background process from SIGHUP, and interactive input doesn't make sense to such a long-running process). So newer coreutils does just that, meaning 'nohup tty' is testing whether /dev/null is a tty (it isn't), while older coreutils held the input tty open and was able to return true. | | We are able to work around the issues but it creates more | incompatibilities between Linux and the other Unix flavors. You already have to work around the incompatibilities of stdin being redirected, since POSIX allows, but does not require, that. In other words, relying on a tty input to survive nohup is inherently non-portable. - -- 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 iD4DBQFHvvdS84KuGfSFAYARAvTqAJkBBrft/wm1VWYibggIn/DSL51odQCYghUf 740QQWhyiw27yrMKCOHr1w== =009F -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: nohup breaks logname and tty commands
Eric Blake <[EMAIL PROTECTED]> writes: > According to ROTH, MATTHEW G (ATTSI) on 2/22/2008 9:06 AM: > | In RHEL 5 with coreutils 5.97 the following does not work: > | > | $ /usr/bin/nohup /usr/bin/logname > | /usr/bin/nohup: appending output to `nohup.out' > | > | $ cat nohup.out > | /usr/bin/logname: no login name > > I'm not sure why that is failing for you. It worked just fine for me: > $ logname > eblake > $ nohup logname > nohup: ignoring input and appending output to `nohup.out' > $ cat nohup.out > eblake > $ nohup --version | head -n1 > nohup (GNU coreutils) 6.10 > $ logname --version | head -n1 > logname (GNU coreutils) 6.10 > > Perhaps an strace would shed some light? That appears to be a bug in glibc in that getlogin uses the terminal connected to stdin instead of the controlling terminal. 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
how to apply for adding a change or a patch in gnu-coreutils-6.9 and whom to contact for the same
My name is Nilesh Kumar studying in Vellore Institute Of Technology University, Vellore, Tamil Nadu. I would like to know as to how to apply for adding a change or a patch in gnu-coreutils-6.9 in more detail. Waiting in anticipation. Thanking you. Yours faithfully Nilesh Kumar ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: how to apply for adding a change or a patch in gnu-coreutils-6.9 and whom to contact for the same
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to nilesh kumar on 2/22/2008 12:23 PM: | I would like to know as to how to | apply for adding a change or a patch in gnu-coreutils-6.9 in more | detail. This is the right list. Feel free to post your patches here, although if they are non-trivial, you will also have to assign copyright to the FSF. By the way, we prefer patches against the latest git checkout (6.9 is old; 6.10 has been released and more patches have been applied in the meantime). - -- 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 iD8DBQFHvyjL84KuGfSFAYARAuX7AKC7r1GB0z5BbhT5xtD48Lo9QLlnjwCePiSR azeZoFu9T9v8rV9/8F+Rxt0= =gC1b -END PGP SIGNATURE- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: rename("symlink-to-dir/", "name") behavior
On Fri, Feb 22, 2008 at 1:09 PM, Jim Meyering <[EMAIL PROTECTED]> wrote: > Do you see another errno symbol name that makes sense? ENOTSUP? James. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
`cp -p` incorrectly sets g+s bit when fs supports acl
i'm using coreutils-6.10 with acl-2.2.47 on linux-2.6.24. when using ext2 with acl support enabled, `cp -p` on a directory who does not have the g+s bit set but whose parent does have g+s set, the new destination directory will have the g+s bit set. if the filesystem is remounted with acl support turned off, the g+s bit is (correctly) not set on the new destination directory. consider: dd if=/dev/zero of=fs.img count=512 mke2fs fs.img mkdir fs mount -o loop,acl fs.img fs cd fs mkdir parent chmod g+s parent cd parent mkdir src chmod g-s src cp -pr src dst now, if i do `ls -l` on the dirs with acl support: drwxr-sr-x 2 root root 1024 2008-02-22 22:22 dst drwxr-xr-x 2 root root 1024 2008-02-22 22:22 src and if i remount w/out acl and repeat the steps: drwxr-xr-x 2 root root 1024 2008-02-22 22:22 dst drwxr-xr-x 2 root root 1024 2008-02-22 22:22 src -mike signature.asc Description: This is a digitally signed message part. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: `cp -p` incorrectly sets g+s bit when fs supports acl
Mike Frysinger <[EMAIL PROTECTED]> writes: > i'm using coreutils-6.10 with acl-2.2.47 on linux-2.6.24. when using ext2 > with acl support enabled, `cp -p` on a directory who does not have the g+s > bit set but whose parent does have g+s set, the new destination directory > will have the g+s bit set. if the filesystem is remounted with acl support > turned off, the g+s bit is (correctly) not set on the new destination > directory. Could you please strace the failing cp? Thanks. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: `cp -p` incorrectly sets g+s bit when fs supports acl
On Saturday 23 February 2008, Paul Eggert wrote:
> Mike Frysinger <[EMAIL PROTECTED]> writes:
> > i'm using coreutils-6.10 with acl-2.2.47 on linux-2.6.24. when using
> > ext2 with acl support enabled, `cp -p` on a directory who does not have
> > the g+s bit set but whose parent does have g+s set, the new destination
> > directory will have the g+s bit set. if the filesystem is remounted with
> > acl support turned off, the g+s bit is (correctly) not set on the new
> > destination directory.
>
> Could you please strace the failing cp? Thanks.
here is the strace from a good and a bad run
-mike
signature.asc
Description: This is a digitally signed message part.
execve("/root/coreutils-6.10/src/cp", ["/root/coreutils-6.10/src/cp", "-pr", "src", "dst"], [/* 55 vars */]) = 0
brk(0) = 0x614000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ad5a06ec000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2ad5a06ed000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=254827, ...}) = 0
mmap(NULL, 254827, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2ad5a06ee000
close(3)= 0
open("/lib/libacl.so.1", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\0\"[EMAIL PROTECTED]@[EMAIL PROTECTED]@\0\34\0\33\0\1\0\0\0\5\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\324j\0\0\0\0\0\0\324j\0\0\0\0\0\0\0\0 \0\0\0\0\0\1\0\0\0\6\0\0\0\270m\0\0\0\0\0\0\270m \0\0\0\0\0\270m \0\0\0\0\0\200\4\0\0\0\0\0\0\260\4\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0\350m\0\0\0\0\0\0\350m \0\0\0\0\0\350m \0\0\0\0\0\320\1\0\0\0\0\0\0\320\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0P\345td\4\0\0\0\344`\0\0\0\0\0\0\344`\0\0\0\0\0\0\344`\0\0\0\0\0\0\34\2\0\0\0\0\0\0\34\2\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0R\345td\4\0\0\0\270m\0\0\0\0\0\0\270m \0\0\0\0\0\270m \0\0\0\0\0H\2\0\0\0\0\0\0H\2\0\0\0\0\0\0\1\0\0\0\0\0\0\0\200\25\4e\0(\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0\275\0\0\0a\0\0\0008\0\0\0F\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0B\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\r\0\0\0`\0\0\0K\0\0\0+\0\0\0\0\0\0\0\0\0\0\0\16\0\0\0006\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0Z\0\0\0\0\0\0\0\0\0\0\0P\0\0\0\0\0\0\0\0\0\0\0\25\0\0\0\0\0\0\0\0\0\0\0003\0\0\0\0\0\0\0\0\0\0\0]\0\0\0%\0\0\0\'\0\0\0\32\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0 \0\0\0\34\0\0\0\0\0\0\0\0\0\0\0#\0\0\0Y\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0N\0\0\0\0\0\0\0\3\0\0\0L\0\0\0\0\0\0\0\0\0\0\0001\0\0\0\0\0\0\0)[EMAIL PROTECTED]", 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=31296, ...}) = 0
mmap(NULL, 2126440, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ad5a08ed000
mprotect(0x2ad5a08f4000, 2093056, PROT_NONE) = 0
mmap(0x2ad5a0af3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x6000) = 0x2ad5a0af3000
close(3)= 0
open("/lib/libc.so.6", O_RDONLY)= 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>[EMAIL PROTECTED];[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] \0\0\0\0\0\1\0\0\0\6\0\0\0`\347\23\0\0\0\0\0`\3473\0\0\0\0\0`\3473\0\0\0\0\0\30F\0\0\0\0\0\0x\212\0\0\0\0\0\0\0\0 \0\0\0\0\0\2\0\0\0\6\0\0\0`\33\24\0\0\0\0\0`\0334\0\0\0\0\0`\0334\0\0\0\0\0\360\1\0\0\0\0\0\0\360\1\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\4\0\0\0\250\2\0\0\0\0\0\0\250\2\0\0\0\0\0\0\250\2\0\0\0\0\0\0 \0\0\0\0\0\0\0 \0\0\0\0\0\0\0\4\0\0\0\0\0\0\0\7\0\0\0\4\0\0\0`\347\23\0\0\0\0\0`\3473\0\0\0\0\0`\3473\0\0\0\0\0\20\0\0\0\0\0\0\0h\0\0\0\0\0\0\0\20\0\0\0\0\0\0\0P\345td\4\0\0\0\334J\21\0\0\0\0\0\334J\21\0\0\0\0\0\334J\21\0\0\0\0\0\34e\0\0\0\0\0\0\34e\0\0\0\0\0\0\4\0\0\0\0\0\0\0Q\345td\6\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0R\345td\4\0\0\0`\347\23\0\0\0\0\0`\3473\0\0\0\0\0`\3473\0\0\0\0\0\2408\0\0\0\0\0\0\2408\0\0\0\0\0\0\1\0\0\0\0\0\0\0\200\25\4e\0(\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\10\0\0\0\0\0\0\0\4\0\0\0\20\0\0\0\1\0\0\0GNU\0\0\0\0\0\2\0\0\0\6\0\0\0\t\0\0\0\363\3\0\0\n\0\0\0\0\1\0\0\16\0\0\0\\20D\240 [EMAIL PROTECTED]"[EMAIL PROTECTED], \16\"H&\204\300\214\4\10\0\2\2\16\241\254\32\4f\300\0\3002\0\300\0P\1 \201\10\204\v ($\0\4 P\0\20X\200\312DB(\0\6\200\20\30B\0 @\200\0", 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1330424, ...}) = 0
mmap(NULL, 3437016, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x2ad5a0af5000
mprotect(0x2ad5a0c33000, 2097152, PROT_NONE) = 0
mmap(0x2ad5a0e33000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13e000) = 0x2ad5a0e33000
mmap(0x2ad5a0e38000, 16856, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2ad5a0e38
Re: rename("symlink-to-dir/", "name") behavior
Eric Blake <[EMAIL PROTECTED]> wrote: > According to Jim Meyering on 2/22/2008 6:09 AM: > |> I wonder if we would have much luck proposing a patch to the Linux kernel > |> folks to do just that? > | > | Do you see another errno symbol name that makes sense? > | I think that ENOTDIR makes the most sense from a semantic point of view. > | It might be a hard sell. > > The POSIX folks argued that ENOTDIR is not appropriate, since in _most_ > contexts, symlink-to-dir/ (with the trailing slash) is indeed a directory > according to the pathname resolution rules - it is only when you omit the > trailing slash that it is not a directory; unfortunately, rename and rmdir > have different semantics when you remove the trailing slash. But they > also agreed that POSIX allows implementations to add additional > restrictions on path resolution, and that as long as Linux does not > violate the semantics of their interpretation of ENOTDIR (ie. uses a > different errno, to make it clear that this is an intentional and addition > implementation restriction of Linux), then the intuitive behavior is > permissible as one of those implementation restrictions. ENOTSUP sounds > reasonable, otherwise I think we'd have to invent a new one, maybe ESLASH > "trailing slash on symlink"? Oh! ENOTSUP sounds ok. That's probably easier than inventing, even if ESLASH is more evocative. For some reason I interpreted Geoff's words as saying the alternate errno symbol had to be one of the ones already listed in the ERRORS section. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
