GNU bug report logs -
#10305
coreutils-8.14, "rm -r" fails with EBADF
Previous Next
To reply to this bug, email your comments to 10305 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 15 Dec 2011 14:08:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Joachim Schmitz" <jojo <at> schmitz-digital.de>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Thu, 15 Dec 2011 14:08:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Hi folks
I got coreutils-8.9, 8.13 and 8.14 to compile for my platform, and most of
the utilities work, but as soon as it comes to recurring thru the file
system some utils fail, e.g.:
~/coreutils-8.14/src $ ./rm -R /tmp/foo
./rm: traversal failed: `/tmp/foo': Bad file descriptor
~/coreutils-8.14/src $ ./rm -r /tmp/foo
./rm: traversal failed: `/tmp/foo': Bad file descriptor
~/coreutils-8.14/src $
'./ls -R /tmp/foo' does work though:
~/coreutils-8.14/src $ ./ls -lr /tmp/foo
total 0
-rw-rw-r-- 1 jojo ITUGLIB 0 Dec 15 08:06 bar
Does this ring a bell with one of you?
I don't understand why one fails but the other works, and can't seem to fine
the place where it goes wrong.
It seems to happen somewhere deep in gnulib, but I'm not really sure.
Bye, Jojo
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 15 Dec 2011 14:19:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
> I got coreutils-8.9, 8.13 and 8.14 to compile for my platform, and most of the
Thanks for the report.
More details will help us help you:
Which platform is that?
Including your config.h might help.
> utilities work, but as soon as it comes to recurring thru the file system some
> utils fail, e.g.:
>
> ~/coreutils-8.14/src $ ./rm -R /tmp/foo
>
> ./rm: traversal failed: `/tmp/foo': Bad file descriptor
>
> ~/coreutils-8.14/src $ ./rm -r /tmp/foo
>
> ./rm: traversal failed: `/tmp/foo': Bad file descriptor
>
> ~/coreutils-8.14/src $
>
> ‘./ls –R /tmp/foo’ does work though:
>
> ~/coreutils-8.14/src $ ./ls -lr /tmp/foo
>
> total 0
>
> -rw-rw-r-- 1 jojo ITUGLIB 0 Dec 15 08:06 bar
>
> Does this ring a bell with one of you?
I haven't seen that before.
It's obviously coming from this:
case FTS_ERR:
/* Various failures, from opendir to ENOMEM, to failure to "return"
to preceding directory, can provoke this. */
error (0, ent->fts_errno, _("traversal failed: %s"),
quote (ent->fts_path));
fts_skip_tree (fts, ent);
return RM_ERROR;
but what I really need to know is what happened just prior, in fts_read.
Can you run gdb, set a breakpoint in fts_read and show us the result of
stepping through fts_read? That would be most useful.
Or can you run strace -o log ./rm -r /tmp/foo
and send us the "log" file?
> I don’t understand why one fails but the other works, and can’t seem to fine the
> place where it goes wrong.
rm (and du, chmod, chown, etc.) use fts for tree traversal, while ls
still uses hand-rolled (and thus unnecessarily limited) recursion.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 15 Dec 2011 15:23:02 GMT)
Full text and
rfc822 format available.
Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> From: Jim Meyering [mailto:jim <at> meyering.net]
> Sent: Thursday, December 15, 2011 3:17 PM
> To: Joachim Schmitz
> Cc: bug-coreutils <at> gnu.org; bug-gnulib <at> gnu.org
> Subject: Re: coreutils-8.14, "rm -r" fails with EBADF
>
> Joachim Schmitz wrote:
> > I got coreutils-8.9, 8.13 and 8.14 to compile for my platform, and
> > most of the
>
> Thanks for the report.
> More details will help us help you:
>
> Which platform is that?
HP-NonStop
> Including your config.h might help.
Attached
> > utilities work, but as soon as it comes to recurring thru the file
> > system some utils fail, e.g.:
> >
> > ~/coreutils-8.14/src $ ./rm -R /tmp/foo
> >
> > ./rm: traversal failed: `/tmp/foo': Bad file descriptor
> >
> > ~/coreutils-8.14/src $ ./rm -r /tmp/foo
> >
> > ./rm: traversal failed: `/tmp/foo': Bad file descriptor
> >
> > ~/coreutils-8.14/src $
> >
> > ‘./ls –R /tmp/foo’ does work though:
> >
> > ~/coreutils-8.14/src $ ./ls -lr /tmp/foo
> >
> > total 0
> >
> > -rw-rw-r-- 1 jojo ITUGLIB 0 Dec 15 08:06 bar
> >
> > Does this ring a bell with one of you?
>
> I haven't seen that before.
> It's obviously coming from this:
>
> case FTS_ERR:
> /* Various failures, from opendir to ENOMEM, to failure to "return"
> to preceding directory, can provoke this. */
> error (0, ent->fts_errno, _("traversal failed: %s"),
> quote (ent->fts_path));
> fts_skip_tree (fts, ent);
> return RM_ERROR;
>
> but what I really need to know is what happened just prior, in fts_read.
> Can you run gdb, set a breakpoint in fts_read and show us the result of stepping
> through fts_read? That would be most useful.
Sorry, no gdb, the debugger here is calls eInspect (but is similar to gdb, as far as I know).
It goes thru fts_read() the 1st time without problem, on 2nd round fts_build(sp, BREAD) in ~/coreutils-8.14/lib/fts.c line 903 returns NULL, then the subsequent rm_fts (fts, ent, x) fails. It goues trhi fts_read() 2 more times after that.
> Or can you run strace -o log ./rm -r /tmp/foo and send us the "log" file?
Sorry, no strace here.
> > I don’t understand why one fails but the other works, and can’t seem
> > to fine the place where it goes wrong.
>
> rm (and du, chmod, chown, etc.) use fts for tree traversal, while ls still uses
> hand-rolled (and thus unnecessarily limited) recursion.
Ah, that makes sense, thanks.
Bye, Jojo
[config.h (text/plain, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 15 Dec 2011 16:31:02 GMT)
Full text and
rfc822 format available.
Message #14 received at submit <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
...
>> but what I really need to know is what happened just prior, in fts_read.
>> Can you run gdb, set a breakpoint in fts_read and show us the result of stepping
>> through fts_read? That would be most useful.
>
> Sorry, no gdb, the debugger here is calls eInspect (but is similar to
> gdb, as far as I know).
> It goes thru fts_read() the 1st time without problem, on 2nd round
> fts_build(sp, BREAD) in ~/coreutils-8.14/lib/fts.c line 903 returns
> NULL, then the subsequent rm_fts (fts, ent, x) fails. It goues trhi
> fts_read() 2 more times after that.
There are three places in fts_build that directly set FTS_STOP:
- fts_palloc failure (i.e., virtual memory exhausted, not likely)
- found a file name longer than SIZE_MAX (not likely)
- failure to restore working directory:
/*
* If descended after called from fts_children or after called from
* fts_read and nothing found, get back. At the root level we use
* the saved fd; if one of fts_open()'s arguments is a relative name
* to an empty directory, we wind up here with no other way back. If
* can't get back, we're done.
*/
if (!continue_readdir && descend && (type == BCHILD || !nitems) &&
(cur->fts_level == FTS_ROOTLEVEL
? RESTORE_INITIAL_CWD(sp)
: fts_safe_changedir(sp, cur->fts_parent, -1, ".."))) {
cur->fts_info = FTS_ERR;
SET(FTS_STOP);
fts_lfree(head);
return (NULL);
}
If you can debug it further to narrow down what/how it is failing,
eventually we'll find the cause.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 15 Dec 2011 18:09:02 GMT)
Full text and
rfc822 format available.
Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):
On 12/15/11 08:28, Jim Meyering wrote:
> If you can debug it further to narrow down what/how it is failing,
> eventually we'll find the cause.
One way to do that might be to put a breakpoint on all the following
functions, and to let us know what their arguments are when called,
and what they return. You also might try to compile coreutils
with debugging turned off, so that functions aren't inlined.
diropen
fts_build
fts_safe_changedir
restore_initial_cwd
fchdir
cwd_advance_fd
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 16 Dec 2011 10:31:01 GMT)
Full text and
rfc822 format available.
Message #20 received at submit <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Thursday, December 15, 2011 7:07 PM
> To: Joachim Schmitz
> Cc: Jim Meyering; bug-coreutils <at> gnu.org; bug-gnulib <at> gnu.org
> Subject: Re: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/15/11 08:28, Jim Meyering wrote:
> > If you can debug it further to narrow down what/how it is failing,
> > eventually we'll find the cause.
>
> One way to do that might be to put a breakpoint on all the following
functions,
> and to let us know what their arguments are when called, and what they
> return. You also might try to compile coreutils with debugging turned
off, so
> that functions aren't inlined.
I guess you meant turn of optimization rather than debugging?
> diropen
> fts_build
> fts_safe_changedir
> restore_initial_cwd
> fchdir
> cwd_advance_fd
OK here we go:
jojo@\hpitug:/home/jojo/Floss/coreutils-8.14/src $ run -debug -inspect=on
./rm -r /tmp/foo
TNS/E Native Inspect gdb Debugger [T1237 - 30-Jun-2010 17:53]
Copyright 1998 Free Software Foundation, Inc.
Copyright 2003-2008 Hewlett-Packard Development Company, L.P.
Native Inspect (based on GDB) is covered by the GNU General Public License.
Type "show copying" for conditions for changing and/or distributing copies.
Type "show warranty" for warranty/support information.
Working directory \HPITUG.$DATA01.JOJO.
Symbols read in for program loadfile /usr/local/Floss/coreutils-8.14/src/rm.
Added process (1,808).
Breakpoint 1 at 0x7000fcb0:1: file /usr/local/Floss/coreutils-8.14/src/rm.c,
line 206.
main (argc=3, argv=0x80ca000) at
/usr/local/Floss/coreutils-8.14/src/rm.c:206
* 206 bool preserve_root = true;
(eInspect 1,808):break
Breakpoint 2 at 0x7000fcb0:1: file /usr/local/Floss/coreutils-8.14/src/rm.c,
line 206.
(eInspect 1,808):clear
invalid command name "clear"
(eInspect 1,808):break 2
warning: Line 2 in file "/usr/local/Floss/coreutils-8.14/src/rm.c" does not
have
instructions.
Placing breakpoint on the next available source line.
Breakpoint 3 at 0x7000e9c0:0: file /usr/local/Floss/coreutils-8.14/src/rm.c,
line 105.
(eInspect 1,808):exit
There are held processes that will be resumed. Exit anyway? (y or n) y
There are existing Breakpoints. Exit anyway? (y or n) y
eInspect is exiting...
./rm: traversal failed: `/tmp/foo': Bad file descriptor
jojo@\hpitug:/home/jojo/Floss/coreutils-8.14/src $ run -debug -inspect=on
./rm -r /tmp/foo
TNS/E Native Inspect gdb Debugger [T1237 - 30-Jun-2010 17:53]
Copyright 1998 Free Software Foundation, Inc.
Copyright 2003-2008 Hewlett-Packard Development Company, L.P.
Native Inspect (based on GDB) is covered by the GNU General Public License.
Type "show copying" for conditions for changing and/or distributing copies.
Type "show warranty" for warranty/support information.
Working directory \HPITUG.$DATA01.JOJO.
Symbols read in for program loadfile /usr/local/Floss/coreutils-8.14/src/rm.
Added process (1,317).
Breakpoint 1 at 0x7000fcb0:1: file /usr/local/Floss/coreutils-8.14/src/rm.c,
line 206.
main (argc=3, argv=0x80ca000) at
/usr/local/Floss/coreutils-8.14/src/rm.c:206
* 206 bool preserve_root = true;
(eInspect 1,317):break diropen
Breakpoint 2 at 0x7002f1a0:1: file
/usr/local/Floss/coreutils-8.14/lib/fts.c, line 360.
(eInspect 1,317):break fts_build
Breakpoint 3 at 0x70038af0:1: file
/usr/local/Floss/coreutils-8.14/lib/fts.c, line 1276.
(eInspect 1,317):break fts_safe_changedir
Breakpoint 4 at 0x7003ee80:1: file
/usr/local/Floss/coreutils-8.14/lib/fts.c, line 2009.
(eInspect 1,317):break restore_initial_cwd
Code location does not exist.
(eInspect 1,317):break fchdir
Breakpoint 5 at 0x7002cd30:2: file
/usr/local/Floss/coreutils-8.14/lib/fchdir.c, line 206.
(eInspect 1,317):break cwd_advance_fd
Breakpoint 6 at 0x70030f70:1: file
/usr/local/Floss/coreutils-8.14/lib/fts.c, line 331.
(eInspect 1,317):cont
Continuing.
Breakpoint 6, cwd_advance_fd (sp=0x80cee40, fd=-3041965,
chdir_down_one=true)
at /usr/local/Floss/coreutils-8.14/lib/fts.c:331
* 331 int old = sp->fts_cwd_fd;
(eInspect 1,317):cont
Continuing.
Breakpoint 3, fts_build (sp=0x80cee40, type=3) at
/usr/local/Floss/coreutils-8.14/lib/fts.c:1276
* 1276 FTSENT *cur = sp->fts_cur;
(eInspect 1,317):cont
Continuing.
./rm: traversal failed: `/tmp/foo': Bad file descriptor
Process (1,317) exited with code 01.
Removed process (1,317).
eInspect is exiting...
jojo@\hpitug:/home/jojo/Floss/coreutils-8.14/src $
so a) there is no restore_initial_cwd and b) it enters only cwd_advance_fd
and fts_build and both only once.
Stepping into fts_build shows that the dup(dir_fd) in line 1385 fails, with
errno being set to EBADF
* 1375 if (continue_readdir)
(eInspect 1,840):
* 1381 else if (nlinks || type == BREAD) {
(eInspect 1,840):
* 1382 if (ISSET(FTS_CWDFD))
(eInspect 1,840):
* 1384 dir_fd = dup (dir_fd);
(eInspect 1,840):p dir_fd
$3 = 3
(eInspect 1,840):next
* 1385 if (0 <= dir_fd)
(eInspect 1,840):p dir_fd
$4 = -1
(eInspect 1,840):next
* 1388 if (dir_fd < 0 || fts_safe_changedir(sp, cur,
dir_fd, NULL)) {
(eInspect 1,840):
* 1389 if (nlinks && type == BREAD)
(eInspect 1,840):
* 1390 cur->fts_errno = errno;
(eInspect 1,840):
* 1391 cur->fts_flags |= FTS_DONTCHDIR;
(eInspect 1,840):p cur->fts_errno
$5 = 4009
(eInspect 1,840):
So... it seems we can't dup() an fd for a directory here!
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 16 Dec 2011 10:53:02 GMT)
Full text and
rfc822 format available.
Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
>> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
>> Sent: Thursday, December 15, 2011 7:07 PM
>> To: Joachim Schmitz
>> Cc: Jim Meyering; bug-coreutils <at> gnu.org; bug-gnulib <at> gnu.org
>> Subject: Re: coreutils-8.14, "rm -r" fails with EBADF
>>
>> On 12/15/11 08:28, Jim Meyering wrote:
>> > If you can debug it further to narrow down what/how it is failing,
>> > eventually we'll find the cause.
>>
>> One way to do that might be to put a breakpoint on all the following
> functions,
>> and to let us know what their arguments are when called, and what they
>> return. You also might try to compile coreutils with debugging turned
> off, so
>> that functions aren't inlined.
>
> I guess you meant turn of optimization rather than debugging?
>
>> diropen
>> fts_build
>> fts_safe_changedir
>> restore_initial_cwd
>> fchdir
>> cwd_advance_fd
>
> OK here we go:
> jojo@\hpitug:/home/jojo/Floss/coreutils-8.14/src $ run -debug -inspect=on
> ./rm -r /tmp/foo
...
> Stepping into fts_build shows that the dup(dir_fd) in line 1385 fails, with
> errno being set to EBADF
>
> * 1375 if (continue_readdir)
> (eInspect 1,840):
> * 1381 else if (nlinks || type == BREAD) {
> (eInspect 1,840):
> * 1382 if (ISSET(FTS_CWDFD))
> (eInspect 1,840):
> * 1384 dir_fd = dup (dir_fd);
> (eInspect 1,840):p dir_fd
> $3 = 3
> (eInspect 1,840):next
> * 1385 if (0 <= dir_fd)
> (eInspect 1,840):p dir_fd
> $4 = -1
...
> So... it seems we can't dup() an fd for a directory here!
Right.
Your config.h file suggests you're not using a gnulib dup replacement,
so I suspect a bug in your system's dup implementation.
I thought gnulib had pretty good dup* test coverage,
but see that no dup* test uses a directory file descriptor.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 16 Dec 2011 13:05:01 GMT)
Full text and
rfc822 format available.
Message #26 received at submit <at> debbugs.gnu.org (full text, mbox):
> From: Jim Meyering [mailto:jim <at> meyering.net]
> Sent: Friday, December 16, 2011 11:51 AM
> To: Joachim Schmitz
> Cc: 'Paul Eggert'; bug-gnulib <at> gnu.org; bug-coreutils <at> gnu.org
> Subject: Re: coreutils-8.14, "rm -r" fails with EBADF
>
> Joachim Schmitz wrote:
>
> >> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> >> Sent: Thursday, December 15, 2011 7:07 PM
> >> To: Joachim Schmitz
> >> Cc: Jim Meyering; bug-coreutils <at> gnu.org; bug-gnulib <at> gnu.org
> >> Subject: Re: coreutils-8.14, "rm -r" fails with EBADF
> >>
> >> On 12/15/11 08:28, Jim Meyering wrote:
...
> > So... it seems we can't dup() an fd for a directory here!
>
> Right.
> Your config.h file suggests you're not using a gnulib dup replacement, so
I
> suspect a bug in your system's dup implementation.
Hmm, I can dup() an fd for a directory if or had been open()'d O_RDONLY, but
not if opened O_WRONLY or O_RDWR, I'll get an EISDIR from open() then.
> I thought gnulib had pretty good dup* test coverage, but see that no dup*
test
> uses a directory file descriptor.
Any workaround?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 16 Dec 2011 13:17:01 GMT)
Full text and
rfc822 format available.
Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
>> From: Jim Meyering [mailto:jim <at> meyering.net]
>> Sent: Friday, December 16, 2011 11:51 AM
>> To: Joachim Schmitz
>> Cc: 'Paul Eggert'; bug-gnulib <at> gnu.org; bug-coreutils <at> gnu.org
>> Subject: Re: coreutils-8.14, "rm -r" fails with EBADF
>>
>> Joachim Schmitz wrote:
>>
>> >> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
>> >> Sent: Thursday, December 15, 2011 7:07 PM
>> >> To: Joachim Schmitz
>> >> Cc: Jim Meyering; bug-coreutils <at> gnu.org; bug-gnulib <at> gnu.org
>> >> Subject: Re: coreutils-8.14, "rm -r" fails with EBADF
>> >>
>> >> On 12/15/11 08:28, Jim Meyering wrote:
> ...
>> > So... it seems we can't dup() an fd for a directory here!
>>
>> Right.
>> Your config.h file suggests you're not using a gnulib dup replacement, so
> I
>> suspect a bug in your system's dup implementation.
>
> Hmm, I can dup() an fd for a directory if or had been open()'d O_RDONLY, but
> not if opened O_WRONLY or O_RDWR, I'll get an EISDIR from open() then.
The FDs in fts.c should all be opened with O_RDONLY (among other flags),
but not O_WRONLY or O_RDWR. Maybe one of these other flags is what's
making your dup fail:
static inline int
internal_function
diropen (FTS const *sp, char const *dir)
{
int open_flags = (O_SEARCH | O_DIRECTORY | O_NOCTTY | O_NONBLOCK
| (ISSET (FTS_PHYSICAL) ? O_NOFOLLOW : 0)
| (ISSET (FTS_NOATIME) ? O_NOATIME : 0));
static inline DIR *
internal_function
opendirat (int fd, char const *dir, int extra_flags, int *pdir_fd)
{
int new_fd = openat (fd, dir,
(O_RDONLY | O_DIRECTORY | O_NOCTTY | O_NONBLOCK
| extra_flags));
>> I thought gnulib had pretty good dup* test coverage, but see that no dup*
> test
>> uses a directory file descriptor.
>
> Any workaround?
For your problem, try removing those other O_* flags.
For the test suite with inadequate coverage: add dirfd-using tests.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 16 Dec 2011 13:45:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 10305 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 12/16/2011 06:02 AM, Joachim Schmitz wrote:
> Hmm, I can dup() an fd for a directory if or had been open()'d O_RDONLY, but
> not if opened O_WRONLY or O_RDWR, I'll get an EISDIR from open() then.
But you shouldn't be able to open() a directory O_WRONLY or O_RDWR in
the first place, under POSIX. Is this a bug in our open() wrapper for
permitting a bad open() on a directory, which then renders the fd
un-dup()able? Or is it really some other O_* flag causing the issue?
>
>> I thought gnulib had pretty good dup* test coverage, but see that no dup*
> test
>> uses a directory file descriptor.
Good point, I will look into adding some.
> Any workaround?
We'll probably come up with something, once we can further characterize
what is going on, but I don't have one right now.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 16 Dec 2011 13:49:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Eric Blake [mailto:eblake <at> redhat.com]
> Sent: Friday, December 16, 2011 2:42 PM
> To: Joachim Schmitz
> Cc: 'Jim Meyering'; 10305 <at> debbugs.gnu.org; eggert <at> cs.ucla.edu; bug-
> gnulib <at> gnu.org
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/16/2011 06:02 AM, Joachim Schmitz wrote:
> > Hmm, I can dup() an fd for a directory if or had been open()'d
> > O_RDONLY, but not if opened O_WRONLY or O_RDWR, I'll get an EISDIR
> from open() then.
>
> But you shouldn't be able to open() a directory O_WRONLY or O_RDWR in the
> first place, under POSIX.
Right.
> Is this a bug in our open() wrapper for permitting a
> bad open() on a directory, which then renders the fd un-dup()able? Or is
it
> really some other O_* flag causing the issue?
It is not O_NOCTTY or O_NONBLOCK and the others (O_SEARCH, O_DIRECTORY,
O_NOFOLLOW, O_NOATIME) don't exist here.
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 16 Dec 2011 18:49:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 12/16/11 05:46, Joachim Schmitz wrote:
> It is not O_NOCTTY or O_NONBLOCK and the others (O_SEARCH, O_DIRECTORY,
> O_NOFOLLOW, O_NOATIME) don't exist here.
It could be the FD_CLOEXEC, perhaps. What does the following do?
Try it standalone, and also try it compiled and linked against
gnulib.
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
int main (void)
{
int fd, r, fd2;
fd = open (".", O_RDONLY | O_NOCTTY | O_NONBLOCK);
if (fd < 0)
return perror ("open"), 1;
r = fcntl (fd, F_SETFD, FD_CLOEXEC);
if (r < 0)
return perror ("F_SETFD"), 1;
fd2 = dup (fd);
if (fd2 < 0)
return perror ("dup"), 1;
return 0;
}
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 16 Dec 2011 21:24:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Friday, December 16, 2011 7:47 PM
> To: Joachim Schmitz
> Cc: 'Eric Blake'; 'Jim Meyering'; 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/16/11 05:46, Joachim Schmitz wrote:
> > It is not O_NOCTTY or O_NONBLOCK and the others (O_SEARCH,
> > O_DIRECTORY, O_NOFOLLOW, O_NOATIME) don't exist here.
>
> It could be the FD_CLOEXEC, perhaps. What does the following do?
> Try it standalone, and also try it compiled and linked against gnulib.
>
>
> #include <fcntl.h>
> #include <unistd.h>
> #include <stdio.h>
>
> int main (void)
> {
> int fd, r, fd2;
> fd = open (".", O_RDONLY | O_NOCTTY | O_NONBLOCK);
> if (fd < 0)
> return perror ("open"), 1;
> r = fcntl (fd, F_SETFD, FD_CLOEXEC);
> if (r < 0)
> return perror ("F_SETFD"), 1;
> fd2 = dup (fd);
> if (fd2 < 0)
> return perror ("dup"), 1;
> return 0;
> }
The standalone version works just fine.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Sat, 17 Dec 2011 00:29:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 12/16/11 13:21, Joachim Schmitz wrote:
> The standalone version works just fine.
That's too bad. I'm afraid there's no magic here: we need to
see what system calls are being executed by 'rm', and
in what order, and what arguments they are being given, and
what their results are, so that we can figure out what's going
wrong. Since NonStop doesn't have 'truss', I guess you'll need
to put a breakpoint on every system call and see what its arguments
are and what it returns, starting with the system call that
opens the directory. Or, you can put wrappers around each
system call in the source code, and have the wrappers send
diagnostics to stderr.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Sun, 18 Dec 2011 10:34:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Saturday, December 17, 2011 1:27 AM
> To: Joachim Schmitz
> Cc: 'Eric Blake'; 'Jim Meyering'; 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/16/11 13:21, Joachim Schmitz wrote:
> > The standalone version works just fine.
>
> That's too bad. I'm afraid there's no magic here: we need to see what system
> calls are being executed by 'rm', and in what order, and what arguments they
> are being given, and what their results are, so that we can figure out what's
> going wrong. Since NonStop doesn't have 'truss', I guess you'll need to put a
> breakpoint on every system call and see what its arguments are and what it
> returns, starting with the system call that opens the directory. Or, you can put
> wrappers around each system call in the source code, and have the wrappers
> send diagnostics to stderr.
I did some more debugging: it seems to go wrong in fcntl.c, line 194:
/* Haiku alpha 2 loses fd flags on original. */
int flags = fcntl (fd, F_GETFD); <==
if (flags < 0)
{
result = -1;
break;
}
that fcntl() returns a -1 with errno set to EBADF.
For some reason I can step into that fcntl(), guess it is calling the system's fcntl here?
Stack trace:
7 rpl_fcntl() fcntl.c:194
6 dup_safer() dup-safer.c:33
5 fts_build() fts.c:1384
4 fts_read() ftc.c:902
3 rm() remove.c:598
2 main() rm.c:343
1 _MAIN()
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Sun, 18 Dec 2011 22:26:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 12/18/11 02:31, Joachim Schmitz wrote:
> it seems to go wrong in fcntl.c, line 194:
>
> /* Haiku alpha 2 loses fd flags on original. */
> int flags = fcntl (fd, F_GETFD); <==
> if (flags < 0)
> {
> result = -1;
> break;
> }
>
> that fcntl() returns a -1 with errno set to EBADF.
What is the value of fd at that point?
Is it actually an invalid file descriptor?
> For some reason I can step into that fcntl(), guess it is calling the system's fcntl here?
Yes, that's how it's supposed to work.
If you plant a breakpoint on the parent fts_build,
and single step through that, can you find out whether
continue_readdir is true? If it's true, then please
investigate why dirfd (fts.c line 1285)
returned an invalid file descriptor. If it's false,
then please investigate why opendirat (..., &dir_fd)
(fts.c line 1301) succeeded but set dir_fd to an
invalid file descriptor.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Mon, 19 Dec 2011 08:14:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Sunday, December 18, 2011 11:24 PM
> To: Joachim Schmitz
> Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/18/11 02:31, Joachim Schmitz wrote:
> > it seems to go wrong in fcntl.c, line 194:
> >
> > /* Haiku alpha 2 loses fd flags on original. */
> > int flags = fcntl (fd, F_GETFD); <==
> > if (flags < 0)
> > {
> > result = -1;
> > break;
> > }
> >
> > that fcntl() returns a -1 with errno set to EBADF.
>
> What is the value of fd at that point?
3
> Is it actually an invalid file descriptor?
Not sure, and wouldn't know how to tell, it certainly looks valid but apparenlty fcntl() thinks otherwise.
It was my suspicion but I couldn't find it.
But see further down...
> > For some reason I can step into that fcntl(), guess it is calling the system's
> fcntl here?
>
> Yes, that's how it's supposed to work.
OK, I thought so, but weren't sure.
> If you plant a breakpoint on the parent fts_build, and single step through that,
> can you find out whether continue_readdir is true?
No it is not
> If it's true, then please
> investigate why dirfd (fts.c line 1285) returned an invalid file descriptor. If it's
> false, then please investigate why opendirat (..., &dir_fd) (fts.c line 1301)
> succeeded but set dir_fd to an invalid file descriptor.
OK, attention, lengthy...:
opendirat() calls openat_safer() which calls openat() which calls openat_permissive() which call rpl_open() which calls orig_open() which calls open() (which succeeds and returns 3) and _gl_register_fd() (which does nothing suspicious to the fd) and finally feeds that into fd_safer(). That does nothing but checking whther fd is not between STDIN and STDERR (which it is not). Everything looks fine so far, to me anyway.
Back in opendirat() and into set_cloexec_flag(), which calls rpl_fcntl(F_GETFD)= which calls the real fcntl() and successful. It calls it again with F_SETFD, this too seems successful.
So it goes into fdopendir(), fdopendir_with_dup(), rpl_dup(), the real dup() (disguised as dup_nothrow(), with success), _gl_register_dup(), nothing but success, no suspicious activity against fd.
Then it calls close(3) !!! then close(4) (the fd from the dup()) errno set to ENOTSUP
Back in fts_build() calling dup_safer(3) (which should be invalid meanwhile, as it got closed above!) rpl_fcntl(), calling the real fcntl() with errno EBADF and errors out.
So in fdopendir_with_dup() the fd gets closed and hence made invalid?!?
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Mon, 19 Dec 2011 13:25:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 10305 <at> debbugs.gnu.org (full text, mbox):
BTW: Seems I have a similar problem with tar-1.26. Not with tar-1.25 though.
Trying to spot the relevant diff between the two and relating them to the problem I have in coretuils:
diff -BbENru tar-1.25/gnu/dup2.c tar-1.26/gnu/dup2.c
--- tar-1.25/gnu/dup2.c 2010-05-06 15:18:52.000000000 -0500
+++ tar-1.26/gnu/dup2.c 2011-03-12 03:14:28.000000000 -0600
...
@@ -61,6 +61,10 @@
errno = EBADF;
return -1;
}
+# elif !defined __linux__
+ /* On Haiku, dup2 (fd, fd) mistakenly clears FD_CLOEXEC. */
+ if (fd == desired_fd)
+ return fcntl (fd, F_GETFL) == -1 ? -1 : fd;
# endif
result = dup2 (fd, desired_fd);
# ifdef __linux__
diff -BbENru tar-1.25/gnu/fcntl.c tar-1.26/gnu/fcntl.c
--- tar-1.25/gnu/fcntl.c 2010-05-06 15:18:52.000000000 -0500
+++ tar-1.26/gnu/fcntl.c 2011-03-12 03:14:28.000000000 -0600
...
@@ -189,7 +189,21 @@
errno = EINVAL;
else
{
+ /* Haiku alpha 2 loses fd flags on original. */
+ int flags = fcntl (fd, F_GETFD);
+ if (flags < 0)
+ {
+ result = -1;
+ break;
+ }
result = fcntl (fd, action, target);
+ if (0 <= result && fcntl (fd, F_SETFD, flags) == -1)
+ {
+ int saved_errno = errno;
+ close (result);
+ result = -1;
+ errno = saved_errno;
+ }
# if REPLACE_FCHDIR
if (0 <= result)
result = _gl_register_dup (fd, result);
diff -BbENru tar-1.25/gnu/fdopendir.c tar-1.26/gnu/fdopendir.c
--- tar-1.25/gnu/fdopendir.c 2011-02-04 05:31:35.000000000 -0600
+++ tar-1.26/gnu/fdopendir.c 2011-03-12 03:14:28.000000000 -060
...
@@ -63,7 +67,24 @@
DIR *
fdopendir (int fd)
{
- return fdopendir_with_dup (fd, -1);
+ DIR *dir = fdopendir_with_dup (fd, -1, NULL);
+
+ if (! REPLACE_FCHDIR && ! dir)
+ {
+ int saved_errno = errno;
+ if (EXPECTED_ERRNO (saved_errno))
+ {
+ struct saved_cwd cwd;
+ if (save_cwd (&cwd) != 0)
+ openat_save_fail (errno);
+ dir = fdopendir_with_dup (fd, -1, &cwd);
+ saved_errno = errno;
+ free_cwd (&cwd);
+ errno = saved_errno;
+ }
+ }
+
+ return dir;
}
/* Like fdopendir, except that if OLDER_DUPFD is not -1, it is known
Etc.pp... so we seem to be looking at the same problem, don't we?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Mon, 19 Dec 2011 17:31:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 12/19/11 00:11, Joachim Schmitz wrote:
> So it [opendirat] goes into fdopendir(), fdopendir_with_dup(), rpl_dup(),
> the real dup() (disguised as dup_nothrow(), with success), _gl_register_dup(),
> nothing but success, no suspicious activity against fd.
>
> Then it [fdopendir_with_dup] calls close(3) !!!
Yes, that's what I'd expect. fdopendir_with_dup sees that fd is 3
and dupfd is 4. So it invokes close (3) and then fd_clone_opendir (4, ...)
because it wants fd_clone_opendir to open a file (getting fd 3) and
then operate on fd 3.
then close(4) (the fd from the dup()) errno set to ENOTSUP
Sorry, you've jumped ahead too fast for me to follow. As I understand
it, fd_clone_opendir (4, ...) should first try openat_proc_name (..., 4, "."),
which should fail; it should then try _gl_directory_name (4),
and this should return the name "D" of the directory. fd_clone_opendir
should then invoke opendir ("D"), which should then open the directory,
internally get file descriptor 3, and then return a nonnull DIR *
pointer that is based on file descriptor 3; this is the value that
fd_clone_opendir should return back to fdopendir_with_dup.
So when fdopendir_with_dup later does that close(4), it should be OK.
since the directory is still open on file descriptor 3.
When you say that errno is set to ENOTSUP, though, that suggests
that my analysis is wrong and fd_clone_opendir returns NULL with
errno == ENOTSUP. Can you please investigate why that might be?
On 12/19/11 05:22, Joachim Schmitz wrote:
> Trying to spot the relevant diff between the two and relating them to the problem I have in coretuils:
I suppose you might try applying the reverse of those patches
to coreutils 8.14 to see whether it fixes the problem. I don't
hold out much hope for that approach, though.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 21 Dec 2011 14:18:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Monday, December 19, 2011 6:29 PM
> To: Joachim Schmitz
> Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/19/11 00:11, Joachim Schmitz wrote:
> > So it [opendirat] goes into fdopendir(), fdopendir_with_dup(),
> > rpl_dup(), the real dup() (disguised as dup_nothrow(), with success),
> > _gl_register_dup(), nothing but success, no suspicious activity against fd.
> >
> > Then it [fdopendir_with_dup] calls close(3) !!!
>
> Yes, that's what I'd expect. fdopendir_with_dup sees that fd is 3 and dupfd is 4.
> So it invokes close (3) and then fd_clone_opendir (4, ...) because it wants
> fd_clone_opendir to open a file (getting fd 3) and then operate on fd 3.
>
> then close(4) (the fd from the dup()) errno set to ENOTSUP
>
> Sorry, you've jumped ahead too fast for me to follow. As I understand it,
> fd_clone_opendir (4, ...) should first try openat_proc_name (..., 4, "."), which
> should fail;
Yes, it does (try and fail)
> it should then try _gl_directory_name (4), and this should return the
> name "D" of the directory.
It does.
> fd_clone_opendir should then invoke opendir ("D"),
> which should then open the directory,
it does
> internally get file descriptor 3, and then
> return a nonnull DIR * pointer that is based on file descriptor 3; this is the value
> that fd_clone_opendir should return back to fdopendir_with_dup.
It calls dirfd() with that DIR *, that calls DIR_TO_FD(), which return -1 and sets errno to ENOTSUP
Then dirfd() get called again and fails again.
close (3), calls fs_clone_opendir() and as dupfd is 4 but older_dupfd is -1, it calls close(4) and sets errno to ENTOSUP (from save_errno)
> So when fdopendir_with_dup later does that close(4), it should be OK.
> since the directory is still open on file descriptor 3.
As I see it we now have fds 3 and 4 closed.
> When you say that errno is set to ENOTSUP, though, that suggests that my
> analysis is wrong and fd_clone_opendir returns NULL with errno == ENOTSUP.
> Can you please investigate why that might be?
Ah, should have read to the end first... OK back a couple steps...
Hmm DIR_TO_FD() is :
#define DIR_TO_FD(Dir_p) -1
In config.h:
/* the name of the file descriptor member of DIR */
/* #undef DIR_FD_MEMBER_NAME */
#ifdef DIR_FD_MEMBER_NAME
# define DIR_TO_FD(Dir_p) ((Dir_p)->DIR_FD_MEMBER_NAME)
#else
# define DIR_TO_FD(Dir_p) -1
#endif
So fd_clone_dir() does not return NULL, but has errno set to ENTOSUP.
Our "struct DIR" has 2 shorts and one long, with funny names dd1, dd2 and dd3... looking at their content: nothing looks like a proper fd (values 7, 257 and 135067072, respectively)
Where to go now?
Resorting to wild guesses, I tried all 3 members of struct DIR as DIF_FD_MEMBER_NAME, no change to the EBADF
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 21 Dec 2011 16:09:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
...
> Hmm DIR_TO_FD() is :
> #define DIR_TO_FD(Dir_p) -1
>
> In config.h:
> /* the name of the file descriptor member of DIR */
> /* #undef DIR_FD_MEMBER_NAME */
>
> #ifdef DIR_FD_MEMBER_NAME
> # define DIR_TO_FD(Dir_p) ((Dir_p)->DIR_FD_MEMBER_NAME)
> #else
> # define DIR_TO_FD(Dir_p) -1
> #endif
>
> So fd_clone_dir() does not return NULL, but has errno set to ENTOSUP.
>
>
> Our "struct DIR" has 2 shorts and one long, with funny names dd1, dd2
> and dd3... looking at their content: nothing looks like a proper fd
> (values 7, 257 and 135067072, respectively)
>
>
> Where to go now?
>
> Resorting to wild guesses, I tried all 3 members of struct DIR as
> DIF_FD_MEMBER_NAME, no change to the EBADF
Write a small test program that opens say four directories,
to get one DIR* pointer for each. Then print a table of
the DIR member values. Maybe you'll see a pattern, i.e.,
how to derive an FD number from those dd1,2,3 fields.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 21 Dec 2011 16:31:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 10305 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 12/21/2011 09:06 AM, Jim Meyering wrote:
>>
>> Where to go now?
>>
>> Resorting to wild guesses, I tried all 3 members of struct DIR as
>> DIF_FD_MEMBER_NAME, no change to the EBADF
>
> Write a small test program that opens say four directories,
> to get one DIR* pointer for each. Then print a table of
> the DIR member values. Maybe you'll see a pattern, i.e.,
> how to derive an FD number from those dd1,2,3 fields.
If the NonStop opendir() does not open a directory fd under the hood,
then maybe we should wrap opendir() so that the gnulib rpl_opendir()
always opens a directory at the same time; at which point the gnulib
rpl_dirfd merely returns that directory fd.
Also, does NonStop have anything like Linux' /proc/self/fd or lsof, for
reverse engineering which fds a process has open and on what files? Is
there an equivalent to strace functionality for tracking all syscalls
made by libc?
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 21 Dec 2011 17:15:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Eric Blake [mailto:eblake <at> redhat.com]
> Sent: Wednesday, December 21, 2011 5:28 PM
> To: Jim Meyering
> Cc: Joachim Schmitz; 10305 <at> debbugs.gnu.org; 'Paul Eggert'; bug-
> gnulib <at> gnu.org
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/21/2011 09:06 AM, Jim Meyering wrote:
> >>
> >> Where to go now?
> >>
> >> Resorting to wild guesses, I tried all 3 members of struct DIR as
> >> DIF_FD_MEMBER_NAME, no change to the EBADF
> >
> > Write a small test program that opens say four directories, to get one
> > DIR* pointer for each. Then print a table of the DIR member values.
> > Maybe you'll see a pattern, i.e., how to derive an FD number from
> > those dd1,2,3 fields.
Yes, indeed, thanks for that idea (should have been mine):
It got to be dd1, only it is not an fd but something called fnum and these a) start counting with 1 rather than 0 and b) have 1 and 2 being root and CPD, followed by 3,4 and 5 being stdin, stdout, stderr... it seems fnum -3 == fd
> If the NonStop opendir() does not open a directory fd under the hood, then
> maybe we should wrap opendir() so that the gnulib rpl_opendir() always opens
> a directory at the same time; at which point the gnulib rpl_dirfd merely returns
> that directory fd.
Sounds good, but, to be honest, You lost me here ...
> Also, does NonStop have anything like Linux' /proc/self/fd
No, unfortunatly
> or lsof, for reverse
> engineering which fds a process has open and on what files? Is there an
Hmm... not lsof, but other methods to find out who has which file open and which file is opened by whom.
Reveals , when testing with rm, that my theory from above seems correct, that dir gets fnum=7, the value I see in struct DIR's member dd1, see below.
> equivalent to strace functionality for tracking all syscalls made by libc?
Not that I'd know of.
So let's see whether taking that fnum (AKA "dd1") and subtracting 3 makes it a proper fd.
But this is something for tomorrow...
Bye, Jojo
PS: one of these commands is 'pstate' and here's the output (somewhat verbose, the relevant part at the end)
$ pstate 728694845
PSTATE - T0705AAF (H01) (03MAY2008)
(C)1981 Tandem (C)2004 Hewlett Packard Development Company, L.P.
PSTATE for Guardian T06 on December 21, 2011 10:55:28.02 (LCT)
Target process: pin 720 in cpu 1, \HPITUG.$:1:720:20012474
OSS Pid: 728694845
loadfile type: MAYSETBPT,OSSPROCESS,PICELFPRG
loadfile name: /usr/local/Floss/coreutils-8.14/src/rm
\HPITUG.$SAS106.ZYQL0CAL.Z0009JRT
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zossfdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zi18ndll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zicnvdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zutildll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zcrtldll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zosskdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zcredll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zosscdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zsecdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zossedll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zosshdll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zrlddll
loadfile type: MAYSETBPT,OSSPROCESS,PUBLICLIB,PICELFDLL
loadfile name: /G/system/zdll012/zinetdll
loadfile type: OSSPROCESS,IMPLIB,PICELFDLL
loadfile name: /G/system/sys05/initdll
loadfile type: OSSPROCESS,IMPLIB,PICELFDLL
loadfile name: /G/system/sys05/mcpdll
swap: \HPITUG.$SAS106.#0
extended swap:
segment: Id: 2046
Add: x6CA00000 Size: 147456 Max: 2097152
Flat,Unaliased,KMS Backed
home terminal: \HPITUG.$ZPTY.#ZWN0115
Initial priority was 150, current priority is 150.
Process Wait State: x0000
waiting on :
Process access ID (PAID): ITUGLIB .JOJO , 100,4
Process State: x0009
INSPECT BREAKPOINT
Creator proc : , Id: ITUGLIB .JOJO , 100,4
Process Creation Time: December 21, 2011 10:52:52.420787 (LCT)
Process Execution Time: 0:0:0.001262
Only the process creator may stop this process.
No-one has tried to stop this process.
Procedure call trace:
rpl_opendir + 0x90 (UCr)
opendir_safer + 0x90 (UCr)
fd_clone_opendir + 0x3D0 (UCr)
fdopendir_with_dup + 0x340 (UCr)
fdopendir + 0xD0 (UCr)
opendirat + 0x230 (UCr)
fts_build + 0x7A0 (UCr)
fts_read + 0xE50 (UCr)
rm + 0x210 (UCr)
main + 0x1290 (UCr)
_MAIN + 0x80 (UCr)
Process memory values and other counters.
PFS Current 13624, Size 31384, Max 33554432
Main Stack Origin x70000000, Size 262144, Max 2097152
Priv Stack Origin x6DFE0000, Size 65536, Max 901120
Heap Origin x080CA800, Size 32768, Max 1609783296
Globals Origin x08000000, Size 827392
KMSF Guarantee 0
Resident memory pages 41
Messages Sent 51, Received 2
$RECEIVE Current QLength 0
Page faults 42
Fnum Filename Type Styp Lsterr
---- --------------------------------------- ----------- ---- ------
7 POSIX dir open 0
/tmp/foo
6 OSS open 0
/tmp/foo
5 \HPITUG.$ZPTY.#ZWN0115 OSS open 0
/G/zpty/#zwn0115
4 \HPITUG.$ZPTY.#ZWN0115 OSS open 0
/G/zpty/#zwn0115
3 \HPITUG.$ZPTY.#ZWN0115 OSS open 0
/G/zpty/#zwn0115
2 Current dir 0
/home/jojo
1 Root dir 0
/
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 21 Dec 2011 17:41:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Joachim Schmitz [mailto:jojo <at> schmitz-digital.de]
> Sent: Wednesday, December 21, 2011 6:12 PM
> To: 'Eric Blake'; 'Jim Meyering'
> Cc: '10305 <at> debbugs.gnu.org'; 'Paul Eggert'; 'bug-gnulib <at> gnu.org'
> Subject: RE: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> > From: Eric Blake [mailto:eblake <at> redhat.com]
> > Sent: Wednesday, December 21, 2011 5:28 PM
> > To: Jim Meyering
> > Cc: Joachim Schmitz; 10305 <at> debbugs.gnu.org; 'Paul Eggert'; bug-
> > gnulib <at> gnu.org
> > Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
> >
> > On 12/21/2011 09:06 AM, Jim Meyering wrote:
> > >>
> > >> Where to go now?
> > >>
> > >> Resorting to wild guesses, I tried all 3 members of struct DIR as
> > >> DIF_FD_MEMBER_NAME, no change to the EBADF
> > >
> > > Write a small test program that opens say four directories, to get
> > > one
> > > DIR* pointer for each. Then print a table of the DIR member values.
> > > Maybe you'll see a pattern, i.e., how to derive an FD number from
> > > those dd1,2,3 fields.
>
> Yes, indeed, thanks for that idea (should have been mine):
> It got to be dd1, only it is not an fd but something called fnum and these a) start
> counting with 1 rather than 0 and b) have 1 and 2 being root and CPD, followed
CWD I meant
> by 3,4 and 5 being stdin, stdout, stderr... it seems fnum -3 == fd
<snip>
>
> So let's see whether taking that fnum (AKA "dd1") and subtracting 3 makes it a
> proper fd.
> But this is something for tomorrow...
Apparently an over simplistic approach: doesn't work, I still get an EBADF.
I tried in config.h:
#ifdef DIR_FD_MEMBER_NAME
# define DIR_TO_FD(Dir_p) ((Dir_p)->DIR_FD_MEMBER_NAME)
#elif defined __TANDEM
# define DIR_TO_FD(Dir_p) (((Dir_p)->dd1) - 3)
#else
# define DIR_TO_FD(Dir_p) -1
#endif
Didn't work, unfortunately...
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 21 Dec 2011 18:45:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 12/21/11 08:27, Eric Blake wrote:
> maybe we should wrap opendir() so that the gnulib rpl_opendir()
> always opens a directory at the same time
That sounds a bit drastic, but it may be necessary.
How about this idea instead? Use the following patch,
so that fts_build does not assume that dirfd works.
POSIX does not require dirfd to work, and NonStop is
within its rights to not support dirfd, and in this particular
case I think the code will work without it (albeit less
reliably in the presence of very large file trees).
Joachim, does this patch fix "rm" for you? If not, what
problems does it run into? (I have not audited the code
for all uses of dirfd, just for this one.)
diff --git a/lib/fts.c b/lib/fts.c
index ccd1980..4dc6809 100644
--- a/lib/fts.c
+++ b/lib/fts.c
@@ -1283,7 +1283,7 @@ fts_build (register FTS *sp, int type)
FTSENT *cur = sp->fts_cur;
bool continue_readdir = !!cur->fts_dirp;
- /* When cur->fts_dirp is non-NULL, that means we should
+ /* If cur->fts_dirp is non-NULL and dirfd is supported,
continue calling readdir on that existing DIR* pointer
rather than opening a new one. */
if (continue_readdir)
@@ -1292,16 +1292,20 @@ fts_build (register FTS *sp, int type)
dir_fd = dirfd (dp);
if (dir_fd < 0)
{
+ int dirfd_errno = errno;
closedir_and_clear (cur->fts_dirp);
if (type == BREAD)
{
cur->fts_info = FTS_DNR;
cur->fts_errno = errno;
}
- return NULL;
+ if (dirfd_errno != ENOTSUP)
+ return NULL;
+ continue_readdir = false;
}
}
- else
+
+ if (! continue_readdir)
{
/* Open the directory for reading. If this fails, we're done.
If being called from fts_read, set the fts_info field. */
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 21 Dec 2011 19:04:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 10305 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 12/21/2011 10:12 AM, Joachim Schmitz wrote:
>>> Write a small test program that opens say four directories, to get one
>>> DIR* pointer for each. Then print a table of the DIR member values.
>>> Maybe you'll see a pattern, i.e., how to derive an FD number from
>>> those dd1,2,3 fields.
>
> Yes, indeed, thanks for that idea (should have been mine):
> It got to be dd1, only it is not an fd but something called fnum and these a) start counting with 1 rather than 0 and b) have 1 and 2 being root and CPD, followed by 3,4 and 5 being stdin, stdout, stderr... it seems fnum -3 == fd
Yay - we can implement dirfd() in terms of dd1-3.
Please try this on coreutils:
./configure gl_cv_sys_dir_fd_member_name='dd1-3'
and if that works, then the solution is this patch to gnulib (along with
enhancing our testsuite to further test our dirfd emulation):
diff --git i/ChangeLog w/ChangeLog
index 749b538..7a6bf4b 100644
--- i/ChangeLog
+++ w/ChangeLog
@@ -1,3 +1,9 @@
+2011-12-21 Eric Blake <eblake <at> redhat.com>
+
+ dirfd: port to HP NonStop
+ * m4/dirfd.m4 (gl_PREREQ_DIRFD): Also probe for NonStop variant.
+ Reported by Joachim Schmitz.
+
2011-12-14 Alex Nelson <ajnelson <at> cs.ucsc.edu> (tiny change)
strftime-tests: also test nanoseconds
diff --git i/m4/dirfd.m4 w/m4/dirfd.m4
index ea75e4e..031c337 100644
--- i/m4/dirfd.m4
+++ w/m4/dirfd.m4
@@ -1,4 +1,4 @@
-# serial 22 -*- Autoconf -*-
+# serial 23 -*- Autoconf -*-
dnl Find out how to get the file descriptor associated with an open DIR*.
@@ -50,8 +50,10 @@ AC_DEFUN([gl_PREREQ_DIRFD],
AC_CACHE_CHECK([how to get the file descriptor associated with an
open DIR*],
[gl_cv_sys_dir_fd_member_name],
[
+ # Most systems expose the fd directly, via d_fd or dd_fd
+ # HP NonStop instead has a member dd1, with a value 3 larger than
the fd
dirfd_save_CFLAGS=$CFLAGS
- for ac_expr in d_fd dd_fd; do
+ for ac_expr in d_fd dd_fd dd1-3; do
CFLAGS="$CFLAGS -DDIR_FD_MEMBER_NAME=$ac_expr"
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 21 Dec 2011 19:40:02 GMT)
Full text and
rfc822 format available.
Message #83 received at 10305 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 12/21/2011 11:42 AM, Paul Eggert wrote:
> On 12/21/11 08:27, Eric Blake wrote:
>> maybe we should wrap opendir() so that the gnulib rpl_opendir()
>> always opens a directory at the same time
>
> That sounds a bit drastic, but it may be necessary.
>
> How about this idea instead? Use the following patch,
> so that fts_build does not assume that dirfd works.
>
> POSIX does not require dirfd to work,
Actually, the next version of POSIX _will_ require dirfd to work, so we
may have to go with wrapping rpl_opendir anyways:
http://austingroupbugs.net/view.php?id=391
But you are correct that older systems do not meet the future POSIX
wording, so if your hack works, it's certainly simpler for the short term.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 22 Dec 2011 07:58:01 GMT)
Full text and
rfc822 format available.
Message #86 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Wednesday, December 21, 2011 7:42 PM
> To: Eric Blake
> Cc: Jim Meyering; 10305 <at> debbugs.gnu.org; Joachim Schmitz; bug-
> gnulib <at> gnu.org
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/21/11 08:27, Eric Blake wrote:
> > maybe we should wrap opendir() so that the gnulib rpl_opendir() always
> > opens a directory at the same time
>
> That sounds a bit drastic, but it may be necessary.
>
> How about this idea instead? Use the following patch, so that fts_build does not
> assume that dirfd works.
>
> POSIX does not require dirfd to work, and NonStop is within its rights to not
> support dirfd, and in this particular case I think the code will work without it
> (albeit less reliably in the presence of very large file trees).
>
> Joachim, does this patch fix "rm" for you? If not, what problems does it run
> into? (I have not audited the code for all uses of dirfd, just for this one.)
And this seems to be the problem, dirfd() gets called 3 times:
1st time
12 dirfd() dirfd.c:28 0x7002dbe2
11 rpl_opendir() opendir.c:136 0x70065000
10 opendir_safer() opendir-safer.c:33 0x70054450
9 fd_clone_opendir() fdopendir.c:159 0x70032650
8 fdopendir_with_dup() fdopendir.c:119 0x70032000
7 fdopendir() fdopendir.c:68 0x700319d0
6 opendirat() fts.c:310 0x70033a30
5 fts_build() fts.c:1305 0x7003dcf0
4 fts_read() fts.c:902 0x70039b10
3 rm() remove.c:598 0x7001ad10
2 main() rm.c:343 0x70015910
1 _MAIN() ATOM.$RLSE.T8432H03.CPLMAINC:50 0x70012d40
2nd time
11 dirfd() dirfd.c:28 0x7002dbe2
10 opendir_safer() opendir-safer.c:37 0x700544d0
9 fd_clone_opendir() fdopendir.c:159 0x70032650
8 fdopendir_with_dup() fdopendir.c:119 0x70032000
7 fdopendir() fdopendir.c:68 0x700319d0
6 opendirat() fts.c:310 0x70033a30
5 fts_build() fts.c:1305 0x7003dcf0
4 fts_read() fts.c:902 0x70039b10
3 rm() remove.c:598 0x7001ad10
2 main() rm.c:343 0x70015910
1 _MAIN() ATOM.$RLSE.T8432H03.CPLMAINC:50 0x70012d40
3rd time:
7 dirfd() dirfd.c:28 0x7002dbe2
6 rpl_closedir() closedir.c:43 0x7002da90
5 fts_build() fts.c:1397 0x7003e7d0
4 fts_read() fts.c:902 0x70039b10
3 rm() remove.c:598 0x7001ad10
2 main() rm.c:343 0x70015910
1 _MAIN() ATOM.$RLSE.T8432H03.CPLMAINC:50 0x70012d40
The code path you modified is not touched at all.
> diff --git a/lib/fts.c b/lib/fts.c
> index ccd1980..4dc6809 100644
> --- a/lib/fts.c
> +++ b/lib/fts.c
> @@ -1283,7 +1283,7 @@ fts_build (register FTS *sp, int type)
> FTSENT *cur = sp->fts_cur;
> bool continue_readdir = !!cur->fts_dirp;
>
> - /* When cur->fts_dirp is non-NULL, that means we should
> + /* If cur->fts_dirp is non-NULL and dirfd is supported,
> continue calling readdir on that existing DIR* pointer
> rather than opening a new one. */
> if (continue_readdir)
> @@ -1292,16 +1292,20 @@ fts_build (register FTS *sp, int type)
> dir_fd = dirfd (dp);
> if (dir_fd < 0)
> {
> + int dirfd_errno = errno;
> closedir_and_clear (cur->fts_dirp);
> if (type == BREAD)
> {
> cur->fts_info = FTS_DNR;
> cur->fts_errno = errno;
> }
> - return NULL;
> + if (dirfd_errno != ENOTSUP)
> + return NULL;
> + continue_readdir = false;
> }
> }
> - else
> +
> + if (! continue_readdir)
> {
> /* Open the directory for reading. If this fails, we're done.
> If being called from fts_read, set the fts_info field. */
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 22 Dec 2011 08:44:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Eric Blake [mailto:eblake <at> redhat.com]
> Sent: Wednesday, December 21, 2011 6:32 PM
> To: Joachim Schmitz
> Cc: 'Jim Meyering'; 10305 <at> debbugs.gnu.org; 'Paul Eggert'; bug-
> gnulib <at> gnu.org
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/21/2011 10:12 AM, Joachim Schmitz wrote:
> >>> Write a small test program that opens say four directories, to get
> >>> one
> >>> DIR* pointer for each. Then print a table of the DIR member values.
> >>> Maybe you'll see a pattern, i.e., how to derive an FD number from
> >>> those dd1,2,3 fields.
> >
> > Yes, indeed, thanks for that idea (should have been mine):
> > It got to be dd1, only it is not an fd but something called fnum and
> > these a) start counting with 1 rather than 0 and b) have 1 and 2 being
> > root and CPD, followed by 3,4 and 5 being stdin, stdout, stderr... it
> > seems fnum -3 == fd
>
> Yay - we can implement dirfd() in terms of dd1-3.
>
> Please try this on coreutils:
>
> ./configure gl_cv_sys_dir_fd_member_name='dd1-3'
I tried something to a similar effect, I manually changed config.h accordingly (see other email of mine) and rebuilt dirfd.o, rebuilt libcoreutils.a, relinked rm:
Didn't work :-(
In case it matters: I'm using
./configure --prefix=/usr/local --enable-install-program=arch,hostname --without-gmp CFLAGS="-O0 -g"
Another attempt with adding gl_cv_sys_dir_fd_member_name='dd1-3':
Unfortunatly it doesn't help
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 22 Dec 2011 09:18:01 GMT)
Full text and
rfc822 format available.
Message #92 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 12/21/11 23:54, Joachim Schmitz wrote:
> The code path you modified is not touched at all.
Oh well, it was a bit of a stab in the dark anyway.
I guess we'll have to do Eric's suggestion to wrap opendir
<http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10305#68>.
That should work around the problem, and in some sense
it's nicer anyway because it causes dirfd to work in
the usual way (as required in the next POSIX).
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Sat, 14 Jan 2012 16:29:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Thursday, December 22, 2011 10:15 AM
> To: Joachim Schmitz
> Cc: 'Eric Blake'; 'Jim Meyering'; 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 12/21/11 23:54, Joachim Schmitz wrote:
> > The code path you modified is not touched at all.
>
> Oh well, it was a bit of a stab in the dark anyway.
> I guess we'll have to do Eric's suggestion to wrap opendir
> <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10305#68>.
> That should work around the problem, and in some sense it's nicer anyway
> because it causes dirfd to work in the usual way (as required in the next POSIX).
Any progress on this?
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Sun, 15 Jan 2012 06:02:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 01/14/2012 08:27 AM, Joachim Schmitz wrote:
>> Oh well, it was a bit of a stab in the dark anyway.
>> > I guess we'll have to do Eric's suggestion to wrap opendir
>> > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10305#68>.
>> > That should work around the problem, and in some sense it's nicer anyway
>> > because it causes dirfd to work in the usual way (as required in the next POSIX).
> Any progress on this?
Not be me, alas. Is it something you can work on?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Sun, 15 Jan 2012 14:26:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Sunday, January 15, 2012 7:01 AM
> To: Joachim Schmitz
> Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric Blake'; 'Jim Meyering'
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 01/14/2012 08:27 AM, Joachim Schmitz wrote:
> >> Oh well, it was a bit of a stab in the dark anyway.
> >> > I guess we'll have to do Eric's suggestion to wrap opendir
> >> > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10305#68>.
> >> > That should work around the problem, and in some sense it's nicer
> >> > anyway because it causes dirfd to work in the usual way (as required in the
> next POSIX).
> > Any progress on this?
>
> Not be me, alas. Is it something you can work on?
I'm afraid I cannot, wouldn't even know where to start.
I'd be willing to test though.
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Sun, 29 Jan 2012 14:31:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 10305 <at> debbugs.gnu.org (full text, mbox):
severity 10305 wishlist
tags 10305 + notabug
thanks
Eric Blake wrote:
> On 12/21/2011 11:42 AM, Paul Eggert wrote:
>> On 12/21/11 08:27, Eric Blake wrote:
>>> maybe we should wrap opendir() so that the gnulib rpl_opendir()
>>> always opens a directory at the same time
>>
>> That sounds a bit drastic, but it may be necessary.
>>
>> How about this idea instead? Use the following patch,
>> so that fts_build does not assume that dirfd works.
>>
>> POSIX does not require dirfd to work,
>
> Actually, the next version of POSIX _will_ require dirfd to work, so we
> may have to go with wrapping rpl_opendir anyways:
>
> http://austingroupbugs.net/view.php?id=391
>
> But you are correct that older systems do not meet the future POSIX
> wording, so if your hack works, it's certainly simpler for the short term.
It is clear that this is not really a bug in coreutils,
but more an opportunity to (through gnulib) make fts, and thus rm
portable to this aspect of NonStop.
Marked as notabug and wishlist.
Severity set to 'wishlist' from 'normal'
Request was from
Jim Meyering <jim <at> meyering.net>
to
control <at> debbugs.gnu.org.
(Sun, 29 Jan 2012 14:31:02 GMT)
Full text and
rfc822 format available.
Added tag(s) notabug.
Request was from
Jim Meyering <jim <at> meyering.net>
to
control <at> debbugs.gnu.org.
(Sun, 29 Jan 2012 14:31:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 26 Jun 2012 16:44:02 GMT)
Full text and
rfc822 format available.
Message #111 received at 10305 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Sunday, January 15, 2012 7:01 AM
> To: Joachim Schmitz
> Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric Blake'; 'Jim Meyering'
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 01/14/2012 08:27 AM, Joachim Schmitz wrote:
> >> Oh well, it was a bit of a stab in the dark anyway.
> >> > I guess we'll have to do Eric's suggestion to wrap opendir
> >> > <http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10305#68>.
> >> > That should work around the problem, and in some sense it's nicer
> >> > anyway because it causes dirfd to work in the usual way (as required in the
> next POSIX).
> > Any progress on this?
>
> Not be me, alas. Is it something you can work on?
It's been a while but we now have something working.
Attached the patch that made it work for us with tar-1.26, I'll try the equivalent on coreutils-8.17 later this week.
We need an extended check in configure, small additions to dirfd.c, open.c, unistd.in.h and a somewhat larger addition to fchdir.c. Also 2 small fixes for C99 and 2 more, one for gnulib and one for tar, to cope with HP NotStop's superuser having UID 65530 rather than 0. And one fix for tar's test suite on HP NonStop
Let me know what you think and where/how you'd do it differently.
Bye, Jojo
[gnulib.diff (application/octet-stream, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 26 Jun 2012 17:51:02 GMT)
Full text and
rfc822 format available.
Message #114 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
> Also 2 small fixes for C99
Thanks for these. Indeed, the 'argp' and 'regex' modules use strcasecmp()
and should therefore depend 'strcase' (already done) and include <strings.h>
(done through patch below).
2012-06-26 Bruno Haible <bruno <at> clisp.org>
argp, regex: Ensure strcasecmp gets declared.
* lib/argp-help.c: Include <strings.h>.
* lib/regex_internal.h: Likewise.
Reported and suggested by Joachim Schmitz <jojo <at> schmitz-digital.de>.
--- lib/argp-help.c.orig Tue Jun 26 19:44:50 2012
+++ lib/argp-help.c Tue Jun 26 19:42:04 2012
@@ -29,6 +29,7 @@
#include <stddef.h>
#include <stdlib.h>
#include <string.h>
+#include <strings.h>
#include <assert.h>
#include <stdarg.h>
#include <ctype.h>
--- lib/regex_internal.h.orig Tue Jun 26 19:44:50 2012
+++ lib/regex_internal.h Tue Jun 26 19:42:56 2012
@@ -24,6 +24,7 @@
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
+#include <strings.h>
#include <langinfo.h>
#ifndef _LIBC
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 26 Jun 2012 18:02:02 GMT)
Full text and
rfc822 format available.
Message #117 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Shouldn't regex be avoiding strcasecmp entirely?
That is, couldn't there be a weird locale that considers
the lower-case equivalent of "U" to be "uu", or something
weird like that?
For this particular case c-strcase seems overkill, so how
about the following further patch?
diff --git a/lib/regcomp.c b/lib/regcomp.c
index 7eb003b..6d5525a 100644
--- a/lib/regcomp.c
+++ b/lib/regcomp.c
@@ -899,8 +899,10 @@ init_dfa (re_dfa_t *dfa, size_t pat_len)
!= 0);
#else
codeset_name = nl_langinfo (CODESET);
- if (strcasecmp (codeset_name, "UTF-8") == 0
- || strcasecmp (codeset_name, "UTF8") == 0)
+ if ((codeset_name[0] == 'U' || codeset_name[0] == 'u')
+ && (codeset_name[1] == 'T' || codeset_name[1] == 't')
+ && (codeset_name[2] == 'F' || codeset_name[2] == 'f')
+ && strcmp (codeset_name + 3 + (codeset_name[3] == '-'), "8") == 0)
dfa->is_utf8 = 1;
/* We check exhaustively in the loop below if this charset is a
diff --git a/modules/regex b/modules/regex
index 5371bab..cfc5d07 100644
--- a/modules/regex
+++ b/modules/regex
@@ -26,7 +26,6 @@ mbsinit [test $ac_use_included_regex = yes]
nl_langinfo [test $ac_use_included_regex = yes]
stdbool [test $ac_use_included_regex = yes]
stdint [test $ac_use_included_regex = yes]
-strcase [test $ac_use_included_regex = yes]
wchar [test $ac_use_included_regex = yes]
wcrtomb [test $ac_use_included_regex = yes]
wctype-h [test $ac_use_included_regex = yes]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 26 Jun 2012 22:02:02 GMT)
Full text and
rfc822 format available.
Message #120 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Hi Paul,
> Shouldn't regex be avoiding strcasecmp entirely?
> That is, couldn't there be a weird locale that considers
> the lower-case equivalent of "U" to be "uu", or something
> weird like that?
In such a locale, strcasecmp would not consider "U" and "uu" as
being equivalent; only mbscasecmp would do this.
But you're right: for comparing results of nl_langinfo (CODESET),
one should not use a locale dependent comparison. You wouldn't
want "ISO-8859-9" and "iso-8859-9" to be considered as different,
just because the locale is Turkish.
> For this particular case c-strcase seems overkill, so how
> about the following further patch?
>
> diff --git a/lib/regcomp.c b/lib/regcomp.c
> index 7eb003b..6d5525a 100644
> --- a/lib/regcomp.c
> +++ b/lib/regcomp.c
> @@ -899,8 +899,10 @@ init_dfa (re_dfa_t *dfa, size_t pat_len)
> != 0);
> #else
> codeset_name = nl_langinfo (CODESET);
> - if (strcasecmp (codeset_name, "UTF-8") == 0
> - || strcasecmp (codeset_name, "UTF8") == 0)
> + if ((codeset_name[0] == 'U' || codeset_name[0] == 'u')
> + && (codeset_name[1] == 'T' || codeset_name[1] == 't')
> + && (codeset_name[2] == 'F' || codeset_name[2] == 'f')
> + && strcmp (codeset_name + 3 + (codeset_name[3] == '-'), "8") == 0)
> dfa->is_utf8 = 1;
>
> /* We check exhaustively in the loop below if this charset is a
> diff --git a/modules/regex b/modules/regex
> index 5371bab..cfc5d07 100644
> --- a/modules/regex
> +++ b/modules/regex
> @@ -26,7 +26,6 @@ mbsinit [test $ac_use_included_regex = yes]
> nl_langinfo [test $ac_use_included_regex = yes]
> stdbool [test $ac_use_included_regex = yes]
> stdint [test $ac_use_included_regex = yes]
> -strcase [test $ac_use_included_regex = yes]
> wchar [test $ac_use_included_regex = yes]
> wcrtomb [test $ac_use_included_regex = yes]
> wctype-h [test $ac_use_included_regex = yes]
Looks right to me. Please add to this the removal of <strings.h> from
regex_internal.h, since I had already committed the #include <strings.h>.
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 27 Jun 2012 00:54:01 GMT)
Full text and
rfc822 format available.
Message #123 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 06/26/2012 09:38 AM, Joachim Schmitz wrote:
> Let me know what you think and where/how you'd do it differently.
The changes mostly look good. The trivial ones we've incorporated
already. I have some comments on the nontrivial ones (please see below).
But before we get into it too much further, are you and your company
willing to assign copyright to your nontrival changes to the FSF?
If so, I can send you more info about how to do that.
Here are some comments about that patch:
> --- ./configure.orig 2011-03-12 03:50:18.000000000 -0600
> +++ ./configure 2012-06-26 06:49:17.000000000 -0500
For future versions of this patch there's no need to show differences in
automatically-generated files like 'configure'.
> --- ./gnu/argp-help.c.orig 2011-03-12 03:14:26.000000000 -0600
> +++ ./gnu/argp-help.c 2011-06-16 02:01:23.000000000 -0500
This one Bruno just now fixed in a different way:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=2457d7ca6856f84502b09fa4690f6f4187de050f
> --- ./gnu/regex.c.orig 2011-03-12 03:14:32.000000000 -0600
> +++ ./gnu/regex.c 2011-06-17 04:07:16.000000000 -0500
This one we also fixed in a different way:
http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=d4903bb0efac5e399b785c71367d8cda3fb539ab
> --- ./gnu/dirfd.c.orig 2011-03-12 03:14:28.000000000 -0600
> +++ ./gnu/dirfd.c 2012-06-25 02:55:09.000000000 -0500
> ...
> +#ifdef __TANDEM
> +# include <unistd.h> /* for _gl_fnum2dt(), needed in C99 mode */
> +#endif
Shouldn't that be "_gl_fnum2fd"?
More important, doesn't the declaration of _gl_fnum2fd belong
better in dirent.h, not unistd.h? Among other things, that would
mean the above change can be omitted.
> int
> dirfd (DIR *dir_p)
> {
> int fd = DIR_TO_FD (dir_p);
> if (fd == -1)
> errno = ENOTSUP;
> +#ifdef __TANDEM
> + fd = _gl_fnum2fd(fd);
> +#endif
This might be cleaner if DIR_TO_FD invoked _gl_fnum2fd directly.
That way, dirfd.c could be left alone. (Or perhaps not; I don't
understand the code that well.)
> +# define NOFNUM -1
What's this for? I don't see it used anywhere.
> +# define NOFD -1
Body needs to be parenthesized.
> + char fnum; /* 'y' or 'n', actually a bool */
Why not use 1 and 0? That's far more typical for boolean values,
and generates better code.
> +#ifdef __TANDEM
> + || (stat (filename, &statbuf) == 0 && S_ISDIR (statbuf.st_mode)))
> +#else
> || (fstat (fd, &statbuf) == 0 && S_ISDIR (statbuf.st_mode)))
> +#endif
fstat doesn't work on Tandem? I must be missing something here.
> fd = orig_open (filename, flags, mode);
> +#ifdef __TANDEM
> + /* On NonStop open(2) can open an OSS directory, but not /G & /E
> + * directory, hence we do a dummy open here and override fstat() in
> + * fchdir.c to hide the fact that we have a dummy.
> + */
> + if (fd < 0 && errno == EISDIR)
> + fd = open ("/dev/null", flags, mode);
> +#endif
If 'flags' contains O_WRONLY or O_RDWR, this will misbehave
on an OSS directory, since open will fail with errno == EISDIR
but we don't want to replace it with /dev/null. So the fallback
needs to be conditioned on the file being opened read-only.
> --- ./gnu/unlinkdir.c.orig 2011-03-12 03:14:34.000000000 -0600
> +++ ./gnu/unlinkdir.c 2012-06-26 08:46:41.000000000 -0500
> ...
> --- ./src/extract.c.orig 2010-11-27 04:33:22.000000000 -0600
> +++ ./src/extract.c 2011-06-16 01:55:46.000000000 -0500
I just now fixed this in a different way in gnulib and tar master.
> /usr/local/bin/diff -EBbu ./tests/genfile.c.orig ./tests/genfile.c
> --- ./tests/genfile.c.orig 2010-10-24 13:06:45.000000000 -0500
> +++ ./tests/genfile.c 2011-06-16 01:55:46.000000000 -0500
> @@ -610,9 +610,17 @@
> else if (strcmp (p, "size") == 0)
> printf ("%s", umaxtostr (st.st_size, buf));
> else if (strcmp (p, "blksize") == 0)
> +#ifdef __TANDEM
> + printf ("*****Nothing to print on NonStop for st_blksize****\n");
> +#else
> printf ("%s", umaxtostr (st.st_blksize, buf));
> +#endif
> else if (strcmp (p, "blocks") == 0)
> +#ifdef __TANDEM
> + printf ("*****Nothing to print on NonStop for st_blocks****\n");
> +#else
> printf ("%s", umaxtostr (st.st_blocks, buf));
> +#endif
> else if (strcmp (p, "atime") == 0)
> printf ("%lu", (unsigned long) st.st_atime);
> else if (strcmp (p, "atimeH") == 0)
I assume st_blksize and st_blocks are garbage on Tandem?
Is there any harm in printing the garbage?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 27 Jun 2012 07:30:02 GMT)
Full text and
rfc822 format available.
Message #126 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Wednesday, June 27, 2012 2:49 AM
> To: Joachim Schmitz
> Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric Blake'; 'Jim Meyering'
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 06/26/2012 09:38 AM, Joachim Schmitz wrote:
>
> > Let me know what you think and where/how you'd do it differently.
>
> The changes mostly look good. The trivial ones we've incorporated already. I
> have some comments on the nontrivial ones (please see below).
> But before we get into it too much further, are you and your company willing to
> assign copyright to your nontrival changes to the FSF?
> If so, I can send you more info about how to do that.
I'd need to check, will pursue this in a different email.
> Here are some comments about that patch:
>
>
> > --- ./configure.orig 2011-03-12 03:50:18.000000000 -0600
> > +++ ./configure 2012-06-26 06:49:17.000000000 -0500
> For future versions of this patch there's no need to show differences in
> automatically-generated files like 'configure'.
That change then needs to go into m4/dirfd.m4, right?
> > --- ./gnu/argp-help.c.orig 2011-03-12 03:14:26.000000000 -0600
> > +++ ./gnu/argp-help.c 2011-06-16 02:01:23.000000000 -0500
>
> This one Bruno just now fixed in a different way:
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=2457d7ca685
> 6f84502b09fa4690f6f4187de050f
Fine by me
> > --- ./gnu/regex.c.orig 2011-03-12 03:14:32.000000000 -0600
> > +++ ./gnu/regex.c 2011-06-17 04:07:16.000000000 -0500
>
> This one we also fixed in a different way:
> http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=d4903bb0efa
> c5e399b785c71367d8cda3fb539ab
Fine too.
> > --- ./gnu/dirfd.c.orig 2011-03-12 03:14:28.000000000 -0600
> > +++ ./gnu/dirfd.c 2012-06-25 02:55:09.000000000 -0500
> > ...
> > +#ifdef __TANDEM
> > +# include <unistd.h> /* for _gl_fnum2dt(), needed in C99 mode */
> > +#endif
>
> Shouldn't that be "_gl_fnum2fd"?
Yes, of course, stupid typo.
> More important, doesn't the declaration of _gl_fnum2fd belong better in
> dirent.h, not unistd.h? Among other things, that would mean the above change
> can be omitted.
My attempts to integrate this into coreutils-8.17 seem to indicate that this function and a couple more are used elsewhere too
Looks like there closedir.o needs _gl_ungerister_fnum(), dirfd.c needs _gl_fnum2ds() and opendir.c needs _gl_register_fnum().
> > int
> > dirfd (DIR *dir_p)
> > {
> > int fd = DIR_TO_FD (dir_p);
> > if (fd == -1)
> > errno = ENOTSUP;
> > +#ifdef __TANDEM
> > + fd = _gl_fnum2fd(fd);
> > +#endif
>
> This might be cleaner if DIR_TO_FD invoked _gl_fnum2fd directly.
> That way, dirfd.c could be left alone. (Or perhaps not; I don't understand the
> code that well.)
Won't that make that macro too complicated?
> > +# define NOFNUM -1
>
> What's this for? I don't see it used anywhere.
Indeed, scratch it.
> > +# define NOFD -1
>
> Body needs to be parenthesized.
Point taken.
> > + char fnum; /* 'y' or 'n', actually a bool */
>
> Why not use 1 and 0? That's far more typical for boolean values, and
> generates better code.
True. But the corresponding member in dir_info_t should remain a char (or signed char?), to save space, shouldn't it?
Maybe we could also make it a short and place fnum right there? That would change the implementation quite a bit though, but might make it leaner too. And the comment
/* FIXME - add a DIR* member to make dirfd possible on mingw? */
Indicates that there is a change pending for a similar purpose on a different platform...
> > +#ifdef __TANDEM
> > + || (stat (filename, &statbuf) == 0 && S_ISDIR
> > +(statbuf.st_mode)))
>> +#else
> > || (fstat (fd, &statbuf) == 0 && S_ISDIR (statbuf.st_mode)))
> > +#endif
>
> fstat doesn't work on Tandem? I must be missing something here.
This is a special case for those "dummy directories" from the patch chunk below.
And yes, that warrants a comment in the above patch chunk ;-)
> > fd = orig_open (filename, flags, mode);
> > +#ifdef __TANDEM
> > + /* On NonStop open(2) can open an OSS directory, but not /G & /E
> > + * directory, hence we do a dummy open here and override fstat() in
> > + * fchdir.c to hide the fact that we have a dummy.
> > + */
> > + if (fd < 0 && errno == EISDIR)
> > + fd = open ("/dev/null", flags, mode);
> > +#endif
>
> If 'flags' contains O_WRONLY or O_RDWR, this will misbehave on an OSS
> directory, since open will fail with errno == EISDIR but we don't want to replace
> it with /dev/null. So the fallback needs to be conditioned on the file being
> opened read-only.
These cases are handeld furter above in the (existing) code:
if (flags & (O_CREAT | O_WRONLY | O_RDWR))
{
size_t len = strlen (filename);
if (len > 0 && filename[len - 1] == '/')
{
errno = EISDIR;
return -1;
}
}
#endif
fd = orig_open (filename, flags, mode);
#ifdef __TANDEM
/* On NonStop open(2) can open an OSS directory, but not /G & /E
* directory, hence we do a dummy open here and override fstat() in
* fchdir.c to hide the fact that we have a dummy.
*/
if (fd < 0 && errno == EISDIR)
fd = open ("/dev/null", flags, mode);
#endif
> > --- ./gnu/unlinkdir.c.orig 2011-03-12 03:14:34.000000000 -0600
> > +++ ./gnu/unlinkdir.c 2012-06-26 08:46:41.000000000 -0500
> > ...
> > --- ./src/extract.c.orig 2010-11-27 04:33:22.000000000 -0600
> > +++ ./src/extract.c 2011-06-16 01:55:46.000000000 -0500
>
> I just now fixed this in a different way in gnulib and tar master.
Good. Where does that ROOT_UID get set?
> > /usr/local/bin/diff -EBbu ./tests/genfile.c.orig ./tests/genfile.c
> > --- ./tests/genfile.c.orig 2010-10-24 13:06:45.000000000 -0500
> > +++ ./tests/genfile.c 2011-06-16 01:55:46.000000000 -0500
> > @@ -610,9 +610,17 @@
> > else if (strcmp (p, "size") == 0)
> > printf ("%s", umaxtostr (st.st_size, buf));
> > else if (strcmp (p, "blksize") == 0)
> > +#ifdef __TANDEM
> > + printf ("*****Nothing to print on NonStop for st_blksize****\n");
> > +#else
> > printf ("%s", umaxtostr (st.st_blksize, buf));
> > +#endif
> > else if (strcmp (p, "blocks") == 0)
> > +#ifdef __TANDEM
> > + printf ("*****Nothing to print on NonStop for st_blocks****\n");
> > +#else
> > printf ("%s", umaxtostr (st.st_blocks, buf));
> > +#endif
> > else if (strcmp (p, "atime") == 0)
> > printf ("%lu", (unsigned long) st.st_atime);
> > else if (strcmp (p, "atimeH") == 0)
>
> I assume st_blksize and st_blocks are garbage on Tandem?
> Is there any harm in printing the garbage?
No, we don't have those struct members at all. Instead of #ifdef __TANDEM it should probably better be #if HAVE_STAT_ST_BLOCKS and #if HAVE_STRUCT_STAT_ST_BLKSIZE or some such and remain silent if not, maybe like this:
else if (strcmp (p, "blksize") == 0)
#if HAVE_STRUCT_STAT_ST_BLKSIZE
printf ("%s", umaxtostr (st.st_blksize, buf));
#endif
else if (strcmp (p, "blocks") == 0)
#if HAVE_STRUCT_STAT_ST_BLOCKS
printf ("%s", umaxtostr (st.st_blocks, buf));
#endif
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 19 Jul 2012 18:01:02 GMT)
Full text and
rfc822 format available.
Message #129 received at 10305 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> From: Joachim Schmitz [mailto:jojo <at> schmitz-digital.de]
> Sent: Wednesday, June 27, 2012 9:25 AM
> To: 'Paul Eggert'
> Cc: '10305 <at> debbugs.gnu.org'; 'bug-gnulib <at> gnu.org'; 'Eric Blake'; 'Jim
> Meyering'
> Subject: RE: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> > From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> > Sent: Wednesday, June 27, 2012 2:49 AM
> > To: Joachim Schmitz
> > Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric Blake'; 'Jim
> Meyering'
> > Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
> >
> > On 06/26/2012 09:38 AM, Joachim Schmitz wrote:
> >
> > > Let me know what you think and where/how you'd do it differently.
> >
> > The changes mostly look good. The trivial ones we've incorporated
> > already. I have some comments on the nontrivial ones (please see below).
> > Here are some comments about that patch:
> > > --- ./gnu/dirfd.c.orig 2011-03-12 03:14:28.000000000 -0600
> > > +++ ./gnu/dirfd.c 2012-06-25 02:55:09.000000000 -0500
> > > ...
> > > +#ifdef __TANDEM
> > > +# include <unistd.h> /* for _gl_fnum2dt(), needed in C99 mode */
> > > +#endif
> >
> > Shouldn't that be "_gl_fnum2fd"?
>
> Yes, of course, stupid typo.
>
> > More important, doesn't the declaration of _gl_fnum2fd belong better
> > in dirent.h, not unistd.h? Among other things, that would mean the
> > above change can be omitted.
>
> My attempts to integrate this into coreutils-8.17 seem to indicate that this
> function and a couple more are used elsewhere too Looks like there closedir.o
> needs _gl_ungerister_fnum(), dirfd.c needs _gl_fnum2ds() and opendir.c needs
> _gl_register_fnum().
Furthermore that function needs access to fnum2fdmap, which is local to fchdir.c
> > > int
> > > dirfd (DIR *dir_p)
> > > {
> > > int fd = DIR_TO_FD (dir_p);
> > > if (fd == -1)
> > > errno = ENOTSUP;
> > > +#ifdef __TANDEM
> > > + fd = _gl_fnum2fd(fd);
> > > +#endif
> >
> > This might be cleaner if DIR_TO_FD invoked _gl_fnum2fd directly.
> > That way, dirfd.c could be left alone. (Or perhaps not; I don't
> > understand the code that well.)
>
> Won't that make that macro too complicated?
I believe it would. Prove me wrong ;-)
> > > + char fnum; /* 'y' or 'n', actually a bool */
> >
> > Why not use 1 and 0? That's far more typical for boolean values, and
> > generates better code.
Done, revealed a bad bug in our code, fixed now too.
> Maybe we could also make it a short and place fnum right there? That would
> change the implementation quite a bit though, but might make it leaner too.
> And the comment
> /* FIXME - add a DIR* member to make dirfd possible on mingw? */ Indicates
> that there is a change pending for a similar purpose on a different platform...
Ok now...
After quite a few iterations and with integrating the things you already fixed for the next releases of gnulib, coreuitls and tar, we finally got it running fine for coreutils-8.15. Doing the equivalent changes (not 100% identical, the coreutils resp. gnulib code had changed and reshuffled quite a bit) lead us into an endless recursion (well as endless as the stack could grow without aborting). After quite some effort in debugging, Nagendra finally found the culprit: in 8.15 configure checks for several functions to be declared without a macro, one of them is getcwd(), and then puts a
#define HAVE_RAW_DECL_GETCWD
into config.h. Coreutils-8.17 doesn't have that check anymore, hence doesn't set that define and then in getcwd.c enters that endless recursion loop: getcwd(), openat(), rpl_open(), get_name(), getcwd() ....
Our (temp.?) fix is to add an "|| __TANDEM" to lib/getcwd.c, line 138.
Find the entire patch we use attached. Some more comments on these:
We had to hop thru several loops to get getmntent() implemented for NonStop, you may or may not be interested in the details. It is very system specific. Part of the stuff is outside this patch in our own GNUlib-like library (called floss, Freeware Look for Open System Services). Maybe eventually this gets added to our system libs, who knows...
The patch to lib/i-ring.h is needed for the fts-functions to recur deeper than 4 levels, at least on NonStop. It is not really fully understood why that is (not by me at least), but that change cured the symptom ;-). Probably doesn't need to be quit as big...
The patch to lib/readutmp.h is ugly but needed, at least for now, ignore it, unless you have a better idea. We don't have utmp and friends at all. This is a bit work in progress, probably falls into the same category as getmntent().
The patches reg. NO_UID and NO_GID might be better done someplace else, or not at all, I'm sure whether they are worth the effort.
I've disable a bit of apparently dead code in src/remove.c
I'm not sure what's wrong with src/stat.c, but our compiler throws up on the original code. Might well be a bug in our compiler?
Same for src/system.h, I can't get it thru the compiler without that hack, but haven't been able to find out why.
The patch in src/su.c is not really needed, we can't use this su anyway, as our authentication works differently. But the DEFAULT_USER being "root" might be worth getting added to root-uid.h, possibly?
In src/uptime.c it gets pretty system specific (but not as deeply as getmntent), don't know whether you're interested in this, but I included it here anyway.
I've tried to fix some tests, split/filter and touch/not-owner. Some more tests are failing for no good reason, but a) I haven't yet found why they fail nor how to fix it and b) never check for error conditions you can't handle, so I just don't care about these test too much ;-)
As mentioned further above some patches are taken what you already did to coreutils, gnulib and tar.
I've removed a few hunks out of the patch, this may result in warnings by patch about an offset, but I guess you wouldn't apply them unaltered anyway.
Wherever you see room for improvement or have more questions, we're open, just let Nagendra and me know (and yes, schmitz <at> hp.com and jojo <at> schmitz-digital.de is the same person, me, just in different roles, business and private, but feel free to pick your choice)
Bye, Jojo
[coreutils-8.17-nonstop.diff (application/octet-stream, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 12:42:01 GMT)
Full text and
rfc822 format available.
Message #132 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
...
> I've disable a bit of apparently dead code in src/remove.c
...
> /usr/local/bin/diff -EBbu ./src/remove.c.orig ./src/remove.c
> --- ./src/remove.c.orig 2012-05-01 15:55:08 -0500
> +++ ./src/remove.c 2012-06-18 10:06:04 -0500
> @@ -88,6 +88,7 @@
> return st;
> }
>
> +#ifndef __TANDEM /* not used anywhere */
> /* Return true if *ST has been statted. */
> static inline bool
> cache_statted (struct stat *st)
> @@ -101,6 +102,7 @@
> {
> return (0 <= st->st_size);
> }
> +#endif /* !__TANDEM */
>
> /* Return 1 if FILE is an unwritable non-symlink,
> 0 if it is writable or some other type of file,
> @@ -311,6 +313,7 @@
> return RM_OK;
> }
>
> +#ifndef __TANDEM
> /* Return true if FILENAME is a directory (and not a symlink to a directory).
> Otherwise, including the case in which lstat fails, return false.
> *ST is FILENAME's tstatus.
> @@ -340,6 +343,7 @@
> errno = saved_errno;
> return is_non_dir;
> }
> +#endif /* !__TANDEM */
>
> /* When a function like unlink, rmdir, or fstatat fails with an errno
> value of ERRNUM, return true if the specified file system object
Thanks. I've simply removed those unused functions
and wrote a commit log entry for you.
I'll wait for an ACK from you before pushing this,
since you're listed as the author:
From 033b669f50e3ef4de7ba5598c0b036069bd56778 Mon Sep 17 00:00:00 2001
From: Joachim Schmitz <jojo <at> schmitz-digital.de>
Date: Fri, 20 Jul 2012 14:32:53 +0200
Subject: [PATCH] maint: rm: remove unused static-inlined functions
* src/remove.c (cache_statted, is_dir_lstat): Remove unused
static-inlined functions.
Copyright-paperwork-exempt: Yes
---
src/remove.c | 22 ----------------------
1 file changed, 22 deletions(-)
diff --git a/src/remove.c b/src/remove.c
index f44a982..42f2063 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -88,13 +88,6 @@ cache_stat_init (struct stat *st)
return st;
}
-/* Return true if *ST has been statted. */
-static inline bool
-cache_statted (struct stat *st)
-{
- return (st->st_size != -1);
-}
-
/* Return true if *ST has been statted successfully. */
static inline bool
cache_stat_ok (struct stat *st)
@@ -311,21 +304,6 @@ prompt (FTS const *fts, FTSENT const *ent, bool is_dir,
return RM_OK;
}
-/* Return true if FILENAME is a directory (and not a symlink to a directory).
- Otherwise, including the case in which lstat fails, return false.
- *ST is FILENAME's tstatus.
- Do not modify errno. */
-static inline bool
-is_dir_lstat (int fd_cwd, char const *filename, struct stat *st)
-{
- int saved_errno = errno;
- bool is_dir =
- (cache_fstatat (fd_cwd, filename, st, AT_SYMLINK_NOFOLLOW) == 0
- && S_ISDIR (st->st_mode));
- errno = saved_errno;
- return is_dir;
-}
-
/* Return true if FILENAME is a non-directory.
Otherwise, including the case in which lstat fails, return false.
*ST is FILENAME's tstatus.
--
1.7.11.2.249.g31c7954
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 13:03:02 GMT)
Full text and
rfc822 format available.
Message #135 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Jim Meyering [mailto:jim <at> meyering.net]
> Sent: Friday, July 20, 2012 2:35 PM
> To: Joachim Schmitz
> Cc: 'Paul Eggert'; 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric
Blake';
> 'Schmitz, Joachim'; nagendra.vs <at> hp.com
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> Joachim Schmitz wrote:
> ...
> > I've disable a bit of apparently dead code in src/remove.c
...
> Thanks. I've simply removed those unused functions and wrote a commit log
> entry for you.
>
> I'll wait for an ACK from you before pushing this, since you're listed as
the
> author:
ACK ;-)
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 13:21:02 GMT)
Full text and
rfc822 format available.
Message #138 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
>> From: Jim Meyering [mailto:jim <at> meyering.net]
>> Sent: Friday, July 20, 2012 2:35 PM
>> To: Joachim Schmitz
>> Cc: 'Paul Eggert'; 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric
> Blake';
>> 'Schmitz, Joachim'; nagendra.vs <at> hp.com
>> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>>
>> Joachim Schmitz wrote:
>> ...
>> > I've disable a bit of apparently dead code in src/remove.c
> ...
>> Thanks. I've simply removed those unused functions and wrote a commit log
>> entry for you.
>>
>> I'll wait for an ACK from you before pushing this, since you're listed as
> the
>> author:
>
> ACK ;-)
Thanks.
I also removed your name from THANKS.in (otherwise a syntax-check rule
would ding me). That sounds odd only when you don't realize that
commit authors are not listed there because we generate those names
automatically from git.
For more explanation, see the comments in THANKS.in.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 13:47:02 GMT)
Full text and
rfc822 format available.
Message #141 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Jim Meyering [mailto:jim <at> meyering.net]
> Sent: Friday, July 20, 2012 2:35 PM
> To: Joachim Schmitz
> Cc: 'Paul Eggert'; 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric
Blake';
> 'Schmitz, Joachim'; nagendra.vs <at> hp.com
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> Joachim Schmitz wrote:
> ...
> > I've disable a bit of apparently dead code in src/remove.c
> ...
> > /usr/local/bin/diff -EBbu ./src/remove.c.orig ./src/remove.c
> > --- ./src/remove.c.orig 2012-05-01 15:55:08 -0500
> > +++ ./src/remove.c 2012-06-18 10:06:04 -0500
> > @@ -88,6 +88,7 @@
> > return st;
> > }
> >
> > +#ifndef __TANDEM /* not used anywhere */
> > /* Return true if *ST has been statted. */
> > static inline bool
> > cache_statted (struct stat *st)
> > @@ -101,6 +102,7 @@
> > {
> > return (0 <= st->st_size);
> > }
> > +#endif /* !__TANDEM */
> >
> > /* Return 1 if FILE is an unwritable non-symlink,
> > 0 if it is writable or some other type of file,
> > @@ -311,6 +313,7 @@
> > return RM_OK;
> > }
> >
> > +#ifndef __TANDEM
> > /* Return true if FILENAME is a directory (and not a symlink to a
directory).
> > Otherwise, including the case in which lstat fails, return false.
> > *ST is FILENAME's tstatus.
> > @@ -340,6 +343,7 @@
> > errno = saved_errno;
> > return is_non_dir;
> > }
> > +#endif /* !__TANDEM */
> >
> > /* When a function like unlink, rmdir, or fstatat fails with an errno
> > value of ERRNUM, return true if the specified file system object
>
> Thanks. I've simply removed those unused functions
> and wrote a commit log entry for you.
>
> I'll wait for an ACK from you before pushing this,
> since you're listed as the author:
>
>
> From 033b669f50e3ef4de7ba5598c0b036069bd56778 Mon Sep 17 00:00:00
> 2001
> From: Joachim Schmitz <jojo <at> schmitz-digital.de>
> Date: Fri, 20 Jul 2012 14:32:53 +0200
> Subject: [PATCH] maint: rm: remove unused static-inlined functions
>
> * src/remove.c (cache_statted, is_dir_lstat): Remove unused
> static-inlined functions.
> Copyright-paperwork-exempt: Yes
> ---
> src/remove.c | 22 ----------------------
> 1 file changed, 22 deletions(-)
>
> diff --git a/src/remove.c b/src/remove.c
> index f44a982..42f2063 100644
> --- a/src/remove.c
> +++ b/src/remove.c
> @@ -88,13 +88,6 @@ cache_stat_init (struct stat *st)
> return st;
> }
>
> -/* Return true if *ST has been statted. */
> -static inline bool
> -cache_statted (struct stat *st)
> -{
> - return (st->st_size != -1);
> -}
> -
> /* Return true if *ST has been statted successfully. */
> static inline bool
> cache_stat_ok (struct stat *st)
> @@ -311,21 +304,6 @@ prompt (FTS const *fts, FTSENT const *ent, bool
is_dir,
> return RM_OK;
> }
>
> -/* Return true if FILENAME is a directory (and not a symlink to a
directory).
> - Otherwise, including the case in which lstat fails, return false.
> - *ST is FILENAME's tstatus.
> - Do not modify errno. */
> -static inline bool
> -is_dir_lstat (int fd_cwd, char const *filename, struct stat *st)
> -{
> - int saved_errno = errno;
> - bool is_dir =
> - (cache_fstatat (fd_cwd, filename, st, AT_SYMLINK_NOFOLLOW) == 0
> - && S_ISDIR (st->st_mode));
> - errno = saved_errno;
> - return is_dir;
> -}
> -
> /* Return true if FILENAME is a non-directory.
> Otherwise, including the case in which lstat fails, return false.
> *ST is FILENAME's tstatus.
> --
> 1.7.11.2.249.g31c7954
I just saw that my patch removed 2 functions more than your's, mine also
removes cache_stat_ok() and is_nondir_lstat().
Intention? Used where?
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 13:55:01 GMT)
Full text and
rfc822 format available.
Message #144 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
...
> I just saw that my patch removed 2 functions more than your's, mine also
> removes cache_stat_ok() and is_nondir_lstat().
> Intention? Used where?
Hah! I should have temporarily defined-away "inline" to be sure I'd
removed all of them -- then gcc warns about each defined-but-not-used
function. I've just done that. Those two in remove.c are the only
ones in src/.
As penance, I'll do this one for you, too.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 13:59:02 GMT)
Full text and
rfc822 format available.
Message #147 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Jim Meyering [mailto:jim <at> meyering.net]
> Sent: Friday, July 20, 2012 3:48 PM
> To: Joachim Schmitz
> Cc: 'Paul Eggert'; 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric
Blake';
> 'Schmitz, Joachim'; nagendra.vs <at> hp.com
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> Joachim Schmitz wrote:
> ...
> > I just saw that my patch removed 2 functions more than your's, mine
> > also removes cache_stat_ok() and is_nondir_lstat().
> > Intention? Used where?
>
> Hah! I should have temporarily defined-away "inline" to be sure I'd
removed
> all of them -- then gcc warns about each defined-but-not-used function.
I've
> just done that. Those two in remove.c are the only ones in src/.
>
> As penance, I'll do this one for you, too.
;-) Thanks!
Is anyone looking into my other patches too?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 14:01:02 GMT)
Full text and
rfc822 format available.
Message #150 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
...
> I just saw that my patch removed 2 functions more than your's, mine also
> removes cache_stat_ok() and is_nondir_lstat().
> Intention? Used where?
Here's the patch:
From c1263bb95e8ff84e819753c9050b96d16441aa81 Mon Sep 17 00:00:00 2001
From: Joachim Schmitz <jojo <at> schmitz-digital.de>
Date: Fri, 20 Jul 2012 15:52:10 +0200
Subject: [PATCH] maint: rm: remove two more unused static inline functions
* src/remove.c (cache_stat_ok, is_nondir_lstat): Remove unused
functions.
---
src/remove.c | 22 ----------------------
1 file changed, 22 deletions(-)
diff --git a/src/remove.c b/src/remove.c
index 42f2063..5ebd2ce 100644
--- a/src/remove.c
+++ b/src/remove.c
@@ -88,13 +88,6 @@ cache_stat_init (struct stat *st)
return st;
}
-/* Return true if *ST has been statted successfully. */
-static inline bool
-cache_stat_ok (struct stat *st)
-{
- return (0 <= st->st_size);
-}
-
/* Return 1 if FILE is an unwritable non-symlink,
0 if it is writable or some other type of file,
-1 and set errno if there is some problem in determining the answer.
@@ -304,21 +297,6 @@ prompt (FTS const *fts, FTSENT const *ent, bool is_dir,
return RM_OK;
}
-/* Return true if FILENAME is a non-directory.
- Otherwise, including the case in which lstat fails, return false.
- *ST is FILENAME's tstatus.
- Do not modify errno. */
-static inline bool
-is_nondir_lstat (int fd_cwd, char const *filename, struct stat *st)
-{
- int saved_errno = errno;
- bool is_non_dir =
- (cache_fstatat (fd_cwd, filename, st, AT_SYMLINK_NOFOLLOW) == 0
- && !S_ISDIR (st->st_mode));
- errno = saved_errno;
- return is_non_dir;
-}
-
/* When a function like unlink, rmdir, or fstatat fails with an errno
value of ERRNUM, return true if the specified file system object
is guaranteed not to exist; otherwise, return false. */
--
1.7.11.2.194.g7bdb748
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 14:14:02 GMT)
Full text and
rfc822 format available.
Message #153 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
>> From: Jim Meyering [mailto:jim <at> meyering.net]
>> Sent: Friday, July 20, 2012 3:48 PM
>> To: Joachim Schmitz
>> Cc: 'Paul Eggert'; 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric
> Blake';
>> 'Schmitz, Joachim'; nagendra.vs <at> hp.com
>> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>>
>> Joachim Schmitz wrote:
>> ...
>> > I just saw that my patch removed 2 functions more than your's, mine
>> > also removes cache_stat_ok() and is_nondir_lstat().
>> > Intention? Used where?
>>
>> Hah! I should have temporarily defined-away "inline" to be sure I'd
> removed
>> all of them -- then gcc warns about each defined-but-not-used function.
> I've
>> just done that. Those two in remove.c are the only ones in src/.
>>
>> As penance, I'll do this one for you, too.
>
> ;-) Thanks!
>
> Is anyone looking into my other patches too?
I don't know.
However, note that you're using an old version
of coreutils. In the latest, su.c has been removed
so you can drop the patches to that file.
If no one gets back to you on the other coreutils-specific
pieces in two or three weeks, please feel free to ping us at
coreutils <at> gnu.org.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 14:20:02 GMT)
Full text and
rfc822 format available.
Message #156 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> -----Original Message-----
> From: Jim Meyering [mailto:jim <at> meyering.net]
> Sent: Friday, July 20, 2012 4:07 PM
> To: Joachim Schmitz
> Cc: 'Paul Eggert'; bug-gnulib <at> gnu.org; nagendra.vs <at> hp.com;
> 10305 <at> debbugs.gnu.org; 'Schmitz, Joachim'; 'Eric Blake'
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> Joachim Schmitz wrote:
>
> >> From: Jim Meyering [mailto:jim <at> meyering.net]
> >> Sent: Friday, July 20, 2012 3:48 PM
> >> To: Joachim Schmitz
> >> Cc: 'Paul Eggert'; 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric
> > Blake';
> >> 'Schmitz, Joachim'; nagendra.vs <at> hp.com
> >> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
> >>
> >> Joachim Schmitz wrote:
> >> ...
> >> > I just saw that my patch removed 2 functions more than your's, mine
> >> > also removes cache_stat_ok() and is_nondir_lstat().
> >> > Intention? Used where?
> >>
> >> Hah! I should have temporarily defined-away "inline" to be sure I'd
> > removed
> >> all of them -- then gcc warns about each defined-but-not-used function.
> > I've
> >> just done that. Those two in remove.c are the only ones in src/.
> >>
> >> As penance, I'll do this one for you, too.
> >
> > ;-) Thanks!
> >
> > Is anyone looking into my other patches too?
>
> I don't know.
>
> However, note that you're using an old version of coreutils. In the
latest, su.c
> has been removed so you can drop the patches to that file.
Huh? 8.17 is old? It's the latest I could get and still has src/su.c.
Anyway, that patch isn't needed for NonStop anyway, as we need an entirely
different authentication method.
> If no one gets back to you on the other coreutils-specific pieces in two
or three
> weeks, please feel free to ping us at coreutils <at> gnu.org.
OK, I'll check, after my vacation.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 14:25:02 GMT)
Full text and
rfc822 format available.
Message #159 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Joachim Schmitz [mailto:jojo <at> schmitz-digital.de]
> Sent: Thursday, July 19, 2012 7:54 PM
<snip>
> After quite a few iterations and with integrating the things you already fixed for
> the next releases of gnulib, coreuitls and tar, we finally got it running fine for
> coreutils-8.15. Doing the equivalent changes (not 100% identical, the coreutils
> resp. gnulib code had changed and reshuffled quite a bit) lead us into an
> endless recursion (well as endless as the stack could grow without aborting).
> After quite some effort in debugging, Nagendra finally found the culprit: in 8.15
> configure checks for several functions to be declared without a macro, one of
> them is getcwd(), and then puts a #define HAVE_RAW_DECL_GETCWD into
> config.h. Coreutils-8.17 doesn't have that check anymore, hence doesn't set
> that define and then in getcwd.c enters that endless recursion loop: getcwd(),
> openat(), rpl_open(), get_name(), getcwd() ....
>
> Our (temp.?) fix is to add an "|| __TANDEM" to lib/getcwd.c, line 138.
Nagandra had another concern, but couldn't email, it got filtered apparently?
----snip---
Was doing more code study on the getcwd problem,
The coreutils config.hin in 8.17 no more defines any of RAW_DECL_* functions, which were present in 8.15. Can we expect more problems because of this?
Thanks & Regards
Nagendra.V.S
---snip---
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 14:35:01 GMT)
Full text and
rfc822 format available.
Message #162 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
>> However, note that you're using an old version of coreutils. In the
> latest, su.c
>> has been removed so you can drop the patches to that file.
>
> Huh? 8.17 is old? It's the latest I could get and still has src/su.c.
> Anyway, that patch isn't needed for NonStop anyway, as we need an entirely
> different authentication method.
It's removed in git, for the upcoming 8.18 release.
When you (or anyone) submit patches, we prefer that
they be against the latest in git. See the file, HACKING,
for coreutils contribution guidelines.
>> If no one gets back to you on the other coreutils-specific pieces in two
> or three
>> weeks, please feel free to ping us at coreutils <at> gnu.org.
>
> OK, I'll check, after my vacation.
You can make it easier for us to process your coreutils patches
by separating them into conceptually-related sets, with commit log
entries following HACKING's guidelines.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 14:50:01 GMT)
Full text and
rfc822 format available.
Message #165 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> -----Original Message-----
> From: Jim Meyering [mailto:jim <at> meyering.net]
> Sent: Friday, July 20, 2012 4:28 PM
> To: Joachim Schmitz
> Cc: 'Paul Eggert'; bug-gnulib <at> gnu.org; nagendra.vs <at> hp.com;
> 10305 <at> debbugs.gnu.org; 'Schmitz, Joachim'; 'Eric Blake'
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> Joachim Schmitz wrote:
> >> However, note that you're using an old version of coreutils. In the
> > latest, su.c
> >> has been removed so you can drop the patches to that file.
> >
> > Huh? 8.17 is old? It's the latest I could get and still has src/su.c.
> > Anyway, that patch isn't needed for NonStop anyway, as we need an
> > entirely different authentication method.
>
> It's removed in git, for the upcoming 8.18 release.
> When you (or anyone) submit patches, we prefer that they be against the
latest
> in git. See the file, HACKING, for coreutils contribution guidelines.
First I'd need to get git ported to NonStop, this is on my todolist already.
Appare4ny git install needs Python and a new one as had been ported, so that
one's needed first (started that one just yesterday, looks like a relative
easy port so far) and who knows what else is needed...
> >> If no one gets back to you on the other coreutils-specific pieces in
> >> two
> > or three
> >> weeks, please feel free to ping us at coreutils <at> gnu.org.
> >
> > OK, I'll check, after my vacation.
>
> You can make it easier for us to process your coreutils patches by
separating
> them into conceptually-related sets, with commit log entries following
> HACKING's guidelines.
OK, will try in futur...
Would you accept git pull requests?
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 14:55:01 GMT)
Full text and
rfc822 format available.
Message #168 received at 10305 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On 07/20/2012 08:42 AM, Joachim Schmitz wrote:
>>> Huh? 8.17 is old? It's the latest I could get and still has src/su.c.
>>> Anyway, that patch isn't needed for NonStop anyway, as we need an
>>> entirely different authentication method.
>>
>> It's removed in git, for the upcoming 8.18 release.
>> When you (or anyone) submit patches, we prefer that they be against the
> latest
>> in git. See the file, HACKING, for coreutils contribution guidelines.
>
> First I'd need to get git ported to NonStop, this is on my todolist already.
Do you have shared network drives? It is sufficient to do a git
checkout on another system where git is already ported, then copy the
files over to your nonstop system, without you having to directly port
git to nonstop.
>
> Would you accept git pull requests?
They certainly make it easier to review large patch series.
--
Eric Blake eblake <at> redhat.com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[signature.asc (application/pgp-signature, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 14:57:01 GMT)
Full text and
rfc822 format available.
Message #171 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 07/20/2012 04:42 PM, Joachim Schmitz wrote:
>
> First I'd need to get git ported to NonStop, this is on my todolist already.
> Appare4ny git install needs Python
>
AFAIK, only some non-fundamental programs and features in the Git toolbox
need python. Most of git is perfectly usable without python. I don't know
more details right away, and have little time to dig them up, sorry. You
might try to ask on the Git list for help and guidance, it's usually very
responsive and helpful.
HTH,
Stefano
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 14:58:01 GMT)
Full text and
rfc822 format available.
Message #174 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Joachim Schmitz wrote:
...
>> You can make it easier for us to process your coreutils patches by
> separating
>> them into conceptually-related sets, with commit log entries following
>> HACKING's guidelines.
>
> OK, will try in futur...
>
> Would you accept git pull requests?
Sure, but please also post the content of each commit to the mailing list.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 15:02:01 GMT)
Full text and
rfc822 format available.
Message #177 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Eric Blake [mailto:eblake <at> redhat.com]
> Sent: Friday, July 20, 2012 4:48 PM
> To: Joachim Schmitz
> Cc: 'Jim Meyering'; 'Paul Eggert'; bug-gnulib <at> gnu.org; nagendra.vs <at> hp.com;
> 10305 <at> debbugs.gnu.org; 'Schmitz, Joachim'
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 07/20/2012 08:42 AM, Joachim Schmitz wrote:
> >>> Huh? 8.17 is old? It's the latest I could get and still has src/su.c.
> >>> Anyway, that patch isn't needed for NonStop anyway, as we need an
> >>> entirely different authentication method.
> >>
> >> It's removed in git, for the upcoming 8.18 release.
> >> When you (or anyone) submit patches, we prefer that they be against
> >> the
> > latest
> >> in git. See the file, HACKING, for coreutils contribution guidelines.
> >
> > First I'd need to get git ported to NonStop, this is on my todolist
already.
>
> Do you have shared network drives? It is sufficient to do a git checkout
on
> another system where git is already ported, then copy the files over to
your
> nonstop system, without you having to directly port git to nonstop.
Well, Samba is ported (and pretty current too), but the box I'm doing the
ports on is behind a firewall and I have only ssh access. And from there
http and ftp to the outside world, so I usually use wget to pull packages.
Furthermore the ports should be on a stable release
I'll look into the git business. Just a few weeks ago I started using GitHub
for some other project and really start to like it.
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 15:26:02 GMT)
Full text and
rfc822 format available.
Message #180 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Stefano Lattarini [mailto:stefano.lattarini <at> gmail.com]
> Sent: Friday, July 20, 2012 4:50 PM
> To: Joachim Schmitz
> Cc: 'Jim Meyering'; 'Paul Eggert'; bug-gnulib <at> gnu.org; 'Eric Blake';
> 10305 <at> debbugs.gnu.org; 'Schmitz, Joachim'; nagendra.vs <at> hp.com
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 07/20/2012 04:42 PM, Joachim Schmitz wrote:
> >
> > First I'd need to get git ported to NonStop, this is on my todolist
already.
> > Appare4ny git install needs Python
> >
> AFAIK, only some non-fundamental programs and features in the Git toolbox
> need python. Most of git is perfectly usable without python. I don't
know more
> details right away, and have little time to dig them up, sorry. You might
try to
> ask on the Git list for help and guidance, it's usually very responsive
and
> helpful.
I've been told that git needs python, and in a newer version, for getting it
installed. Haven't verified that yet and as having newer version of Python
is a good idea anyway, I started looking into that first.
Unfortunately there are only 24 hours to a day ;-)
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Fri, 20 Jul 2012 16:55:01 GMT)
Full text and
rfc822 format available.
Message #183 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 07/20/2012 05:19 PM, Joachim Schmitz wrote:
> I've been told that git needs python, and in a newer version, for
> getting it installed.
>
That is false; quoting the comments in the git Makefile:
Define NO_PYTHON if you do not want Python scripts or libraries at all.
> Haven't verified that yet and as having newer version of Python
> is a good idea anyway, I started looking into that first.
> Unfortunately there are only 24 hours to a day ;-)
>
> Bye, Jojo
>
HTH,
Stefano
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Sat, 21 Jul 2012 05:45:02 GMT)
Full text and
rfc822 format available.
Message #186 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 07/20/2012 09:17 AM, Joachim Schmitz wrote:
> The coreutils config.hin in 8.17 no more defines any of RAW_DECL_* functions, which were present in 8.15. Can we expect more problems because of this?
Sorry, I've lost context -- there has been a blizzard of emails
in this thread and I don't know what the current state is any more.
As I understand it, the idea is that you submit your patches one
at a time, against the current git master. Which patch runs
afoul of the RAW_DECL_* change, and why?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Sat, 21 Jul 2012 10:49:02 GMT)
Full text and
rfc822 format available.
Message #189 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> Sent: Saturday, July 21, 2012 7:38 AM
> To: Joachim Schmitz
> Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric Blake'; 'Jim Meyering';
> 'Schmitz, Joachim'; nagendra.vs <at> hp.com
> Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> On 07/20/2012 09:17 AM, Joachim Schmitz wrote:
> > The coreutils config.hin in 8.17 no more defines any of RAW_DECL_*
> functions, which were present in 8.15. Can we expect more problems because
> of this?
> Sorry, I've lost context -- there has been a blizzard of emails in this thread and I
> don't know what the current state is any more.
>
> As I understand it, the idea is that you submit your patches one at a time,
> against the current git master. Which patch runs afoul of the RAW_DECL_*
> change, and why?
The patch in question here is this:
/usr/local/bin/diff -EBbu ./lib/getcwd.c.orig ./lib/getcwd.c
--- ./lib/getcwd.c.orig 2012-01-06 03:14:31 -0600
+++ ./lib/getcwd.c 2012-07-19 11:34:01 -0500
@@ -135,7 +135,7 @@
size_t allocated = size;
size_t used;
-#if HAVE_RAW_DECL_GETCWD && HAVE_MINIMALLY_WORKING_GETCWD
+#if (HAVE_RAW_DECL_GETCWD && HAVE_MINIMALLY_WORKING_GETCWD) || __TANDEM
/* If AT_FDCWD is not defined, the algorithm below is O(N**2) and
this is much slower than the system getcwd (at least on
GNU/Linux). So trust the system getcwd's results unless they
And the fact that somewhere between corutils-8.15 and 8.17 these HAVE_RAW_DECL_* have disappeared from config.hin.
Without the above patch we run into an endless recursion loop: getcwd(), openat(), rpl_open(), get_name(), getcwd() ....
until we hit the max. stack limit and abort.
While the above patch seems to fix this for use, Nagendra's concern is whether there is more to the removal of these HAVE_RAW_DECL_* stuff, whether there are other problems with these
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Sat, 21 Jul 2012 21:17:07 GMT)
Full text and
rfc822 format available.
Message #192 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Was doing more code study on the getcwd problem,
The coreutils config.hin no more defines any of RAW_DECL_* functions, which where present in 8.15. Can we except more problems because of this?
Thanks & Regards
Nagendra.V.S
-----Original Message-----
From: Joachim Schmitz [mailto:jojo <at> schmitz-digital.de]
Sent: Thursday, July 19, 2012 11:24 PM
To: 'Paul Eggert'
Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric Blake'; 'Jim Meyering'; Schmitz, Joachim; V S, Nagendra (Nonstop Filesystems Team)
Subject: RE: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
> From: Joachim Schmitz [mailto:jojo <at> schmitz-digital.de]
> Sent: Wednesday, June 27, 2012 9:25 AM
> To: 'Paul Eggert'
> Cc: '10305 <at> debbugs.gnu.org'; 'bug-gnulib <at> gnu.org'; 'Eric Blake'; 'Jim
> Meyering'
> Subject: RE: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> > From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> > Sent: Wednesday, June 27, 2012 2:49 AM
> > To: Joachim Schmitz
> > Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric Blake'; 'Jim
> Meyering'
> > Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
> >
> > On 06/26/2012 09:38 AM, Joachim Schmitz wrote:
> >
> > > Let me know what you think and where/how you'd do it differently.
> >
> > The changes mostly look good. The trivial ones we've incorporated
> > already. I have some comments on the nontrivial ones (please see below).
> > Here are some comments about that patch:
> > > --- ./gnu/dirfd.c.orig 2011-03-12 03:14:28.000000000 -0600
> > > +++ ./gnu/dirfd.c 2012-06-25 02:55:09.000000000 -0500
> > > ...
> > > +#ifdef __TANDEM
> > > +# include <unistd.h> /* for _gl_fnum2dt(), needed in C99 mode */
> > > +#endif
> >
> > Shouldn't that be "_gl_fnum2fd"?
>
> Yes, of course, stupid typo.
>
> > More important, doesn't the declaration of _gl_fnum2fd belong better
> > in dirent.h, not unistd.h? Among other things, that would mean the
> > above change can be omitted.
>
> My attempts to integrate this into coreutils-8.17 seem to indicate
> that this function and a couple more are used elsewhere too Looks like
> there closedir.o needs _gl_ungerister_fnum(), dirfd.c needs
> _gl_fnum2ds() and opendir.c needs _gl_register_fnum().
Furthermore that function needs access to fnum2fdmap, which is local to fchdir.c
> > > int
> > > dirfd (DIR *dir_p)
> > > {
> > > int fd = DIR_TO_FD (dir_p);
> > > if (fd == -1)
> > > errno = ENOTSUP;
> > > +#ifdef __TANDEM
> > > + fd = _gl_fnum2fd(fd);
> > > +#endif
> >
> > This might be cleaner if DIR_TO_FD invoked _gl_fnum2fd directly.
> > That way, dirfd.c could be left alone. (Or perhaps not; I don't
> > understand the code that well.)
>
> Won't that make that macro too complicated?
I believe it would. Prove me wrong ;-)
> > > + char fnum; /* 'y' or 'n', actually a bool */
> >
> > Why not use 1 and 0? That's far more typical for boolean values,
> > and generates better code.
Done, revealed a bad bug in our code, fixed now too.
> Maybe we could also make it a short and place fnum right there? That
> would change the implementation quite a bit though, but might make it leaner too.
> And the comment
> /* FIXME - add a DIR* member to make dirfd possible on mingw? */
> Indicates that there is a change pending for a similar purpose on a different platform...
Ok now...
After quite a few iterations and with integrating the things you already fixed for the next releases of gnulib, coreuitls and tar, we finally got it running fine for coreutils-8.15. Doing the equivalent changes (not 100% identical, the coreutils resp. gnulib code had changed and reshuffled quite a bit) lead us into an endless recursion (well as endless as the stack could grow without aborting). After quite some effort in debugging, Nagendra finally found the culprit: in 8.15 configure checks for several functions to be declared without a macro, one of them is getcwd(), and then puts a #define HAVE_RAW_DECL_GETCWD into config.h. Coreutils-8.17 doesn't have that check anymore, hence doesn't set that define and then in getcwd.c enters that endless recursion loop: getcwd(), openat(), rpl_open(), get_name(), getcwd() ....
Our (temp.?) fix is to add an "|| __TANDEM" to lib/getcwd.c, line 138.
Find the entire patch we use attached. Some more comments on these:
We had to hop thru several loops to get getmntent() implemented for NonStop, you may or may not be interested in the details. It is very system specific. Part of the stuff is outside this patch in our own GNUlib-like library (called floss, Freeware Look for Open System Services). Maybe eventually this gets added to our system libs, who knows...
The patch to lib/i-ring.h is needed for the fts-functions to recur deeper than 4 levels, at least on NonStop. It is not really fully understood why that is (not by me at least), but that change cured the symptom ;-). Probably doesn't need to be quit as big...
The patch to lib/readutmp.h is ugly but needed, at least for now, ignore it, unless you have a better idea. We don't have utmp and friends at all. This is a bit work in progress, probably falls into the same category as getmntent().
The patches reg. NO_UID and NO_GID might be better done someplace else, or not at all, I'm sure whether they are worth the effort.
I've disable a bit of apparently dead code in src/remove.c
I'm not sure what's wrong with src/stat.c, but our compiler throws up on the original code. Might well be a bug in our compiler?
Same for src/system.h, I can't get it thru the compiler without that hack, but haven't been able to find out why.
The patch in src/su.c is not really needed, we can't use this su anyway, as our authentication works differently. But the DEFAULT_USER being "root" might be worth getting added to root-uid.h, possibly?
In src/uptime.c it gets pretty system specific (but not as deeply as getmntent), don't know whether you're interested in this, but I included it here anyway.
I've tried to fix some tests, split/filter and touch/not-owner. Some more tests are failing for no good reason, but a) I haven't yet found why they fail nor how to fix it and b) never check for error conditions you can't handle, so I just don't care about these test too much ;-)
As mentioned further above some patches are taken what you already did to coreutils, gnulib and tar.
I've removed a few hunks out of the patch, this may result in warnings by patch about an offset, but I guess you wouldn't apply them unaltered anyway.
Wherever you see room for improvement or have more questions, we're open, just let Nagendra and me know (and yes, schmitz <at> hp.com and jojo <at> schmitz-digital.de is the same person, me, just in different roles, business and private, but feel free to pick your choice)
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 08:19:01 GMT)
Full text and
rfc822 format available.
Message #195 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Hi folks
In an attempt to port coreutils 8.21 to HP-NonStop I stumbled accross a couple problems, here are my fixes to them:
Here another file needs to get adjusted to using the new root-uid.h
diff -EBbu ./src/copy.c.orig ./src/copy.c
--- ./src/copy.c.orig 2013-02-07 03:37:05 -0600
+++ ./src/copy.c 2013-02-18 09:29:22 -0600
@@ -51,6 +51,7 @@
#include "ignore-value.h"
#include "ioblksize.h"
#include "quote.h"
+#include "root-uid.h"
#include "same.h"
#include "savedir.h"
#include "stat-size.h"
@@ -1127,7 +1128,7 @@
{
bool access_changed = false;
- if (!(sb.st_mode & S_IWUSR) && geteuid () != 0)
+ if (!(sb.st_mode & S_IWUSR) && geteuid () != ROOT_UID)
access_changed = fchmod_or_lchmod (dest_desc, dst_name, 0600) == 0;
if (!copy_attr (src_name, source_desc, dst_name, dest_desc, x)
@@ -2718,7 +2719,7 @@
priv_freeset (pset);
}
#else
- x->chown_privileges = x->owner_privileges = (geteuid () == 0);
+ x->chown_privileges = x->owner_privileges = (geteuid () == ROOT_UID);
#endif
}
On HP-NonStop we use 0x80000000 instead of -1 for getuid(), getgid() and friends to indicate NO_UID rsp. NO_GID
Guess that difference could go into gnulibs root-uid.h?
Such a change would affect coreutils in ...src/{groups,id,install,test,whoami}.c (in addition to root-uid.h of course)
Here two trailing _ seem missing?
diff -EBbu ./src/numfmt.c.orig ./src/numfmt.c
--- ./src/numfmt.c.orig 2013-02-14 08:49:30 -0600
+++ ./src/numfmt.c 2013-02-18 10:58:27 -0600
@@ -1195,7 +1195,7 @@
Returns a pointer to the *delimiter* of the requested field,
or a pointer to NUL (if reached the end of the string). */
static inline char *
-__attribute ((pure))
+__attribute__ ((pure))
skip_fields (char *buf, int fields)
{
char *ptr = buf;
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 08:39:01 GMT)
Full text and
rfc822 format available.
Message #198 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Joachim Schmitz [mailto:jojo <at> schmitz-digital.de]
> Sent: Saturday, July 21, 2012 12:42 PM
Yes, it's ben a while...
> To: 'Paul Eggert'
> Cc: '10305 <at> debbugs.gnu.org'; 'bug-gnulib <at> gnu.org'; 'Eric Blake'; 'Jim Meyering'; 'Schmitz, Joachim'; 'nagendra.vs <at> hp.com'
> Subject: RE: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
>
> > From: Paul Eggert [mailto:eggert <at> cs.ucla.edu]
> > Sent: Saturday, July 21, 2012 7:38 AM
> > To: Joachim Schmitz
> > Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org; 'Eric Blake'; 'Jim Meyering';
> > 'Schmitz, Joachim'; nagendra.vs <at> hp.com
> > Subject: Re: bug#10305: coreutils-8.14, "rm -r" fails with EBADF
> >
> > On 07/20/2012 09:17 AM, Joachim Schmitz wrote:
> > > The coreutils config.hin in 8.17 no more defines any of RAW_DECL_*
> > functions, which were present in 8.15. Can we expect more problems because
> > of this?
> > Sorry, I've lost context -- there has been a blizzard of emails in this thread and I
> > don't know what the current state is any more.
> >
> > As I understand it, the idea is that you submit your patches one at a time,
> > against the current git master. Which patch runs afoul of the RAW_DECL_*
> > change, and why?
>
> The patch in question here is this:
> /usr/local/bin/diff -EBbu ./lib/getcwd.c.orig ./lib/getcwd.c
> --- ./lib/getcwd.c.orig 2012-01-06 03:14:31 -0600
> +++ ./lib/getcwd.c 2012-07-19 11:34:01 -0500
> @@ -135,7 +135,7 @@
> size_t allocated = size;
> size_t used;
>
> -#if HAVE_RAW_DECL_GETCWD && HAVE_MINIMALLY_WORKING_GETCWD
> +#if (HAVE_RAW_DECL_GETCWD && HAVE_MINIMALLY_WORKING_GETCWD) || __TANDEM
> /* If AT_FDCWD is not defined, the algorithm below is O(N**2) and
> this is much slower than the system getcwd (at least on
> GNU/Linux). So trust the system getcwd's results unless they
>
> And the fact that somewhere between corutils-8.15 and 8.17 these HAVE_RAW_DECL_* have disappeared from config.hin.
> Without the above patch we run into an endless recursion loop: getcwd(), openat(), rpl_open(), get_name(), getcwd() ....
> until we hit the max. stack limit and abort.
>
> While the above patch seems to fix this for use, Nagendra's concern is whether there is more to the removal of these HAVE_RAW_DECL_*
> stuff, whether there are other problems with these
And the above patch is still needed to get coreutils-8.21 to build on HP-NonStop
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 09:11:02 GMT)
Full text and
rfc822 format available.
Message #201 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> -----Original Message-----
> From: Joachim Schmitz [mailto:jojo <at> schmitz-digital.de]
> Sent: Tuesday, February 19, 2013 9:18 AM
> To: '10305 <at> debbugs.gnu.org'; 'bug-gnulib <at> gnu.org'
> Subject: coreutils-8.21, some changes needed
>
> Hi folks
>
> In an attempt to port coreutils 8.21 to HP-NonStop I stumbled accross a couple problems, here are my fixes to them:
>
> Here another file needs to get adjusted to using the new root-uid.h
>
> diff -EBbu ./src/copy.c.orig ./src/copy.c
> --- ./src/copy.c.orig 2013-02-07 03:37:05 -0600
> +++ ./src/copy.c 2013-02-18 09:29:22 -0600
> @@ -51,6 +51,7 @@
> #include "ignore-value.h"
> #include "ioblksize.h"
> #include "quote.h"
> +#include "root-uid.h"
> #include "same.h"
> #include "savedir.h"
> #include "stat-size.h"
> @@ -1127,7 +1128,7 @@
> {
> bool access_changed = false;
>
> - if (!(sb.st_mode & S_IWUSR) && geteuid () != 0)
> + if (!(sb.st_mode & S_IWUSR) && geteuid () != ROOT_UID)
> access_changed = fchmod_or_lchmod (dest_desc, dst_name, 0600) == 0;
>
> if (!copy_attr (src_name, source_desc, dst_name, dest_desc, x)
> @@ -2718,7 +2719,7 @@
> priv_freeset (pset);
> }
> #else
> - x->chown_privileges = x->owner_privileges = (geteuid () == 0);
> + x->chown_privileges = x->owner_privileges = (geteuid () == ROOT_UID);
> #endif
> }
>
>
>
> On HP-NonStop we use 0x80000000 instead of -1 for getuid(), getgid() and friends to indicate NO_UID rsp. NO_GID
> Guess that difference could go into gnulibs root-uid.h?
> Such a change would affect coreutils in ...src/{groups,id,install,test,whoami}.c (in addition to root-uid.h of course)
>
>
> Here two trailing _ seem missing?
>
> diff -EBbu ./src/numfmt.c.orig ./src/numfmt.c
> --- ./src/numfmt.c.orig 2013-02-14 08:49:30 -0600
> +++ ./src/numfmt.c 2013-02-18 10:58:27 -0600
> @@ -1195,7 +1195,7 @@
> Returns a pointer to the *delimiter* of the requested field,
> or a pointer to NUL (if reached the end of the string). */
> static inline char *
> -__attribute ((pure))
> +__attribute__ ((pure))
> skip_fields (char *buf, int fields)
> {
> char *ptr = buf;
>
And here as a git diff:
diff --git a/src/copy.c b/src/copy.c
index 3f2cc2b..affdda1 100644
--- a/src/copy.c
+++ b/src/copy.c
@@ -51,6 +51,7 @@
#include "ignore-value.h"
#include "ioblksize.h"
#include "quote.h"
+#include "root-uid.h"
#include "same.h"
#include "savedir.h"
#include "stat-size.h"
@@ -1127,7 +1128,7 @@ preserve_metadata:
{
bool access_changed = false;
- if (!(sb.st_mode & S_IWUSR) && geteuid () != 0)
+ if (!(sb.st_mode & S_IWUSR) && geteuid () != ROOT_UID)
access_changed = fchmod_or_lchmod (dest_desc, dst_name, 0600) == 0;
if (!copy_attr (src_name, source_desc, dst_name, dest_desc, x)
@@ -2718,7 +2719,7 @@ cp_options_default (struct cp_options *x)
priv_freeset (pset);
}
#else
- x->chown_privileges = x->owner_privileges = (geteuid () == 0);
+ x->chown_privileges = x->owner_privileges = (geteuid () == ROOT_UID);
#endif
}
diff --git a/src/numfmt.c b/src/numfmt.c
index 8c21c2b..50f295d 100644
--- a/src/numfmt.c
+++ b/src/numfmt.c
@@ -1195,7 +1195,7 @@ process_suffixed_number (char *text, long double *result,
Returns a pointer to the *delimiter* of the requested field,
or a pointer to NUL (if reached the end of the string). */
static inline char *
-__attribute ((pure))
+__attribute__ ((pure))
skip_fields (char *buf, int fields)
{
char *ptr = buf;
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 10:30:02 GMT)
Full text and
rfc822 format available.
Message #204 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 02/19/2013 09:08 AM, Joachim Schmitz wrote:
>> -----Original Message-----
>> From: Joachim Schmitz [mailto:jojo <at> schmitz-digital.de]
>> Sent: Tuesday, February 19, 2013 9:18 AM
>> To: '10305 <at> debbugs.gnu.org'; 'bug-gnulib <at> gnu.org'
>> Subject: coreutils-8.21, some changes needed
>>
>> Hi folks
>>
>> In an attempt to port coreutils 8.21 to HP-NonStop I stumbled accross a couple problems, here are my fixes to them:
>>
>> Here another file needs to get adjusted to using the new root-uid.h
>>
>> diff -EBbu ./src/copy.c.orig ./src/copy.c
>> --- ./src/copy.c.orig 2013-02-07 03:37:05 -0600
>> +++ ./src/copy.c 2013-02-18 09:29:22 -0600
>> @@ -51,6 +51,7 @@
>> #include "ignore-value.h"
>> #include "ioblksize.h"
>> #include "quote.h"
>> +#include "root-uid.h"
>> #include "same.h"
>> #include "savedir.h"
>> #include "stat-size.h"
>> @@ -1127,7 +1128,7 @@
>> {
>> bool access_changed = false;
>>
>> - if (!(sb.st_mode & S_IWUSR) && geteuid () != 0)
>> + if (!(sb.st_mode & S_IWUSR) && geteuid () != ROOT_UID)
>> access_changed = fchmod_or_lchmod (dest_desc, dst_name, 0600) == 0;
>>
>> if (!copy_attr (src_name, source_desc, dst_name, dest_desc, x)
>> @@ -2718,7 +2719,7 @@
>> priv_freeset (pset);
>> }
>> #else
>> - x->chown_privileges = x->owner_privileges = (geteuid () == 0);
>> + x->chown_privileges = x->owner_privileges = (geteuid () == ROOT_UID);
>> #endif
>> }
I'll apply this in your name.
>> On HP-NonStop we use 0x80000000 instead of -1 for getuid(), getgid() and friends to indicate NO_UID rsp. NO_GID
>> Guess that difference could go into gnulibs root-uid.h?
You could wrap get[gu]id() to return -1 in that case,
or alternatively define NO_UID and NO_GID in root-uid.h
and use that everywhere. Probably the easiest approach
for coreutils at least since it already users NO_GID since:
http://bugs.gnu.org/10021
Though I note that root-uid.h would be an inaccurate
name if we did that.
BTW, Is 0 a valid "non root" user id on nonstop?
If not then we could use the wrapper approach to
hide the ROOT_UID issue also.
In the meantime we should at least document these differences
in gnulib in doc/posix-functions/getuid.texi.
>> Such a change would affect coreutils in ...src/{groups,id,install,test,whoami}.c (in addition to root-uid.h of course)
>>
>> Here two trailing _ seem missing?
>>
>> diff -EBbu ./src/numfmt.c.orig ./src/numfmt.c
>> --- ./src/numfmt.c.orig 2013-02-14 08:49:30 -0600
>> +++ ./src/numfmt.c 2013-02-18 10:58:27 -0600
>> @@ -1195,7 +1195,7 @@
>> Returns a pointer to the *delimiter* of the requested field,
>> or a pointer to NUL (if reached the end of the string). */
>> static inline char *
>> -__attribute ((pure))
>> +__attribute__ ((pure))
Oops. I'll fix this up with a more extensive patch in coreutils.
Thanks,
Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 10:56:02 GMT)
Full text and
rfc822 format available.
Message #207 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> From: Pádraig Brady [mailto:P <at> draigBrady.com]
> Sent: Tuesday, February 19, 2013 11:29 AM
> To: Joachim Schmitz
> Cc: 10305 <at> debbugs.gnu.org; bug-gnulib <at> gnu.org
> Subject: Re: bug#10305: coreutils-8.21, some changes needed
>
> On 02/19/2013 09:08 AM, Joachim Schmitz wrote:
> >> -----Original Message-----
> >> From: Joachim Schmitz [mailto:jojo <at> schmitz-digital.de]
> >> Sent: Tuesday, February 19, 2013 9:18 AM
> >> To: '10305 <at> debbugs.gnu.org'; 'bug-gnulib <at> gnu.org'
> >> Subject: coreutils-8.21, some changes needed
> >>
> >> Hi folks
> >>
> >> In an attempt to port coreutils 8.21 to HP-NonStop I stumbled accross a couple problems, here are my fixes to them:
> >>
> >> Here another file needs to get adjusted to using the new root-uid.h
> >>
> >> diff -EBbu ./src/copy.c.orig ./src/copy.c
> >> --- ./src/copy.c.orig 2013-02-07 03:37:05 -0600
> >> +++ ./src/copy.c 2013-02-18 09:29:22 -0600
> >> @@ -51,6 +51,7 @@
> >> #include "ignore-value.h"
> >> #include "ioblksize.h"
> >> #include "quote.h"
> >> +#include "root-uid.h"
> >> #include "same.h"
> >> #include "savedir.h"
> >> #include "stat-size.h"
> >> @@ -1127,7 +1128,7 @@
> >> {
> >> bool access_changed = false;
> >>
> >> - if (!(sb.st_mode & S_IWUSR) && geteuid () != 0)
> >> + if (!(sb.st_mode & S_IWUSR) && geteuid () != ROOT_UID)
> >> access_changed = fchmod_or_lchmod (dest_desc, dst_name, 0600) == 0;
> >>
> >> if (!copy_attr (src_name, source_desc, dst_name, dest_desc, x)
> >> @@ -2718,7 +2719,7 @@
> >> priv_freeset (pset);
> >> }
> >> #else
> >> - x->chown_privileges = x->owner_privileges = (geteuid () == 0);
> >> + x->chown_privileges = x->owner_privileges = (geteuid () == ROOT_UID);
> >> #endif
> >> }
>
> I'll apply this in your name.
Thanks
> >> On HP-NonStop we use 0x80000000 instead of -1 for getuid(), getgid() and friends to indicate NO_UID rsp. NO_GID
> >> Guess that difference could go into gnulibs root-uid.h?
Additional info, here's what the manual says:
RETURN VALUES
The getuid() function returns the requested user ID. It is
always successful.
When the authentication information for a process is
uninitialized, the "uninitialized" user ID (hexadecimal
80000000) is returned.
So it not exactly NO_UID, but close enough?
(and similar for getgid().
> You could wrap get[gu]id() to return -1 in that case,
> or alternatively define NO_UID and NO_GID in root-uid.h
> and use that everywhere. Probably the easiest approach
> for coreutils at least since it already users NO_GID since:
> http://bugs.gnu.org/10021
That's why I think it to be best suited there
> Though I note that root-uid.h would be an inaccurate
> name if we did that.
Well, yes, but does this matter a lot? It is about mapping a userid after all.
> BTW, Is 0 a valid "non root" user id on nonstop?
It is. Sort of 'nobody' in the rest of the UNIX world
> If not then we could use the wrapper approach to
> hide the ROOT_UID issue also.
I thought about this a long time, but couldn't come up with a 'water proof' method.
And after all we're dealing with a system's security here, so better stay on the safe side...
> In the meantime we should at least document these differences
> in gnulib in doc/posix-functions/getuid.texi.
>
> >> Such a change would affect coreutils in ...src/{groups,id,install,test,whoami}.c (in addition to root-uid.h of course)
> >>
>
> >> Here two trailing _ seem missing?
> >>
> >> diff -EBbu ./src/numfmt.c.orig ./src/numfmt.c
> >> --- ./src/numfmt.c.orig 2013-02-14 08:49:30 -0600
> >> +++ ./src/numfmt.c 2013-02-18 10:58:27 -0600
> >> @@ -1195,7 +1195,7 @@
> >> Returns a pointer to the *delimiter* of the requested field,
> >> or a pointer to NUL (if reached the end of the string). */
> >> static inline char *
> >> -__attribute ((pure))
> >> +__attribute__ ((pure))
>
> Oops. I'll fix this up with a more extensive patch in coreutils.
>
> Thanks,
> Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 11:55:02 GMT)
Full text and
rfc822 format available.
Message #210 received at 10305 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>> diff -EBbu ./src/numfmt.c.orig ./src/numfmt.c
>>> -__attribute ((pure))
>>> +__attribute__ ((pure))
>
> Oops. I'll fix this up with a more extensive patch in coreutils.
3 patches attached.
thanks,
Pádraig.
[coreutils-nonstop.diff (text/x-patch, attachment)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 12:12:02 GMT)
Full text and
rfc822 format available.
Message #213 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> -----Original Message-----
> From: Pádraig Brady [mailto:P <at> draigBrady.com]
> Sent: Tuesday, February 19, 2013 12:53 PM
> To: Joachim Schmitz
> Cc: 10305 <at> debbugs.gnu.org
> Subject: Re: bug#10305: coreutils-8.21, some changes needed
>
> >>> diff -EBbu ./src/numfmt.c.orig ./src/numfmt.c
> >>> -__attribute ((pure))
> >>> +__attribute__ ((pure))
> >
> > Oops. I'll fix this up with a more extensive patch in coreutils.
>
> 3 patches attached.
Thanks. Of course the 3rd patch works for me, I've tested the first patch and that is fine too. Haven't yet checked the (quite big) 2nd patch though.
You seem to have missed one change, unless I'm missing something? This is your patch:
diff --git a/src/chroot.c b/src/chroot.c
index 1c1a976..bb45825 100644
--- a/src/chroot.c
+++ b/src/chroot.c
@@ -57,7 +57,7 @@ static struct option const long_opts[] =
always-successful replacement to avoid checking for setgroups
availability everywhere, just to support broken platforms. */
static int
-setgroups (size_t size ATTRIBUTE_UNUSED, gid_t const *list ATTRIBUTE_UNUSED)
+setgroups (size_t size _GL_UNUSED, gid_t const *list ATTRIBUTE_UNUSED)
{
return 0;
}
Guess it should be this instead:
diff --git a/src/chroot.c b/src/chroot.c
index 1c1a976..bb45825 100644
--- a/src/chroot.c
+++ b/src/chroot.c
@@ -57,7 +57,7 @@ static struct option const long_opts[] =
always-successful replacement to avoid checking for setgroups
availability everywhere, just to support broken platforms. */
static int
-setgroups (size_t size ATTRIBUTE_UNUSED, gid_t const *list ATTRIBUTE_UNUSED)
+setgroups (size_t size _GL_UNUSED, gid_t const *list _GL_UNUSED)
{
return 0;
}
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 12:27:01 GMT)
Full text and
rfc822 format available.
Message #216 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 02/19/2013 12:10 PM, Joachim Schmitz wrote:
> You seem to have missed one change, unless I'm missing something? This is your patch:
>
> diff --git a/src/chroot.c b/src/chroot.c
> index 1c1a976..bb45825 100644
> --- a/src/chroot.c
> +++ b/src/chroot.c
> @@ -57,7 +57,7 @@ static struct option const long_opts[] =
> always-successful replacement to avoid checking for setgroups
> availability everywhere, just to support broken platforms. */
> static int
> -setgroups (size_t size ATTRIBUTE_UNUSED, gid_t const *list ATTRIBUTE_UNUSED)
> +setgroups (size_t size _GL_UNUSED, gid_t const *list ATTRIBUTE_UNUSED)
Good catch!
My sed was missing a /g
and that function was excluded from my compile.
thanks!
Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 16:27:01 GMT)
Full text and
rfc822 format available.
Message #219 received at 10305 <at> debbugs.gnu.org (full text, mbox):
_Noreturn is typically put before the return type, e.g.,:
static _Noreturn void randread_error (void const *);
rather than putting the _Noreturn after the 'void',
or after the ')'.
C11 does not allow putting _Noreturn after the ')',
if I'm reading the spec correctly.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 16:47:01 GMT)
Full text and
rfc822 format available.
Message #222 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 02/19/2013 04:25 PM, Paul Eggert wrote:
> _Noreturn is typically put before the return type, e.g.,:
>
> static _Noreturn void randread_error (void const *);
>
> rather than putting the _Noreturn after the 'void',
> or after the ')'.
>
> C11 does not allow putting _Noreturn after the ')',
> if I'm reading the spec correctly.
Oops, right.
I might defer the _Noreturn change so,
to one that depends on stdnoreturn
and then does:
#include <stdnoreturn.h>
...
noreturn ...
cheers,
Pádraig.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 19 Feb 2013 20:34:01 GMT)
Full text and
rfc822 format available.
Message #225 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 02/19/13 08:45, Pádraig Brady wrote:
> I might defer the _Noreturn change so,
> to one that depends on stdnoreturn
stdnoreturn isn't suited for projects that
want to port to MSVC, unfortunately.
(Does coreutils want to port to MSVC? I've forgotten.)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Wed, 20 Feb 2013 08:10:01 GMT)
Full text and
rfc822 format available.
Message #228 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 07/19/2012 11:55 PM, V S, Nagendra (Nonstop Filesystems Team) wrote:
> The coreutils config.hin no more defines any of RAW_DECL_* functions, which where present in 8.15.
Thanks, good catch. I have pushed the following patch to gnulib to fix this;
it should appear in the next coreutils release. I'll look into the other
NonStop issues later.
---
ChangeLog | 13 +++++++++++++
lib/getcwd.c | 2 +-
m4/getcwd-path-max.m4 | 3 +++
m4/getcwd.m4 | 2 +-
4 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index a6c50ff..a5b6b13 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,18 @@
2013-02-19 Paul Eggert <eggert <at> cs.ucla.edu>
+ getcwd: support coreutils better
+ Like strtod, getcwd incorrectly referred to HAVE_RAW_DECL_GETCWD,
+ but this might not be correct in coreutils, which disables
+ the raw decl checks. Problem reported by Nagendra in
+ <http://bugs.gnu.org/10305#192>.
+ * lib/getcwd.c (__getcwd): Do not depend on HAVE_RAW_DECL_GETCWD.
+ * m4/getcwd-path-max.m4 (gl_FUNC_GETCWD_PATH_MAX):
+ Test the getcwd function, not any macro, since getcwd.c wants the
+ function.
+ * m4/getcwd.m4 (gl_FUNC_GETCWD):
+ Don't define HAVE_MINIMALLY_WORKING_GETCWD if the code doesn't
+ compile, as might happen if there's a macro but no function.
+
strtod: support coreutils better
* lib/strtod.c (underlying_strtod): Just invoke the underlying strtod.
HAVE_RAW_DECL_STRTOD might not be correct in coreutils, which
diff --git a/lib/getcwd.c b/lib/getcwd.c
index 4b78138..f31c07e 100644
--- a/lib/getcwd.c
+++ b/lib/getcwd.c
@@ -135,7 +135,7 @@ __getcwd (char *buf, size_t size)
size_t allocated = size;
size_t used;
-#if HAVE_RAW_DECL_GETCWD && HAVE_MINIMALLY_WORKING_GETCWD
+#if HAVE_MINIMALLY_WORKING_GETCWD
/* If AT_FDCWD is not defined, the algorithm below is O(N**2) and
this is much slower than the system getcwd (at least on
GNU/Linux). So trust the system getcwd's results unless they
diff --git a/m4/getcwd-path-max.m4 b/m4/getcwd-path-max.m4
index d30e1b3..0b03b66 100644
--- a/m4/getcwd-path-max.m4
+++ b/m4/getcwd-path-max.m4
@@ -52,6 +52,9 @@ AC_DEFUN([gl_FUNC_GETCWD_PATH_MAX],
# define is_ENAMETOOLONG(x) 0
#endif
+/* Use the getcwd function, not any macro. */
+#undef getcwd
+
/* Don't get link errors because mkdir is redefined to rpl_mkdir. */
#undef mkdir
diff --git a/m4/getcwd.m4 b/m4/getcwd.m4
index 93b3b86..6f91bd9 100644
--- a/m4/getcwd.m4
+++ b/m4/getcwd.m4
@@ -123,7 +123,7 @@ AC_DEFUN([gl_FUNC_GETCWD],
dnl Define HAVE_MINIMALLY_WORKING_GETCWD and HAVE_PARTLY_WORKING_GETCWD
dnl if appropriate.
case "$gl_cv_func_getcwd_path_max" in
- "no, it has the AIX bug") ;;
+ "no"|"no, it has the AIX bug") ;;
*)
AC_DEFINE([HAVE_MINIMALLY_WORKING_GETCWD], [1],
[Define to 1 if getcwd minimally works, that is, its result can be
--
1.7.11.7
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 21 Feb 2013 05:42:03 GMT)
Full text and
rfc822 format available.
Message #231 received at 10305 <at> debbugs.gnu.org (full text, mbox):
On 07/19/2012 11:55 PM, V S, Nagendra (Nonstop Filesystems Team) wrote:
> Find the entire patch we use attached.
Thanks, a brief review of the patch suggests that there
is enough material in it that we should get copyright papers
signed before we can incorporate all those changes
in the GNU version. Would you like to do that?
If so, please let me know, and I'll start the ball rolling
with the copyright clerk on our end.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Thu, 21 Feb 2013 05:50:02 GMT)
Full text and
rfc822 format available.
Message #234 received at 10305 <at> debbugs.gnu.org (full text, mbox):
> On 07/19/2012 11:55 PM, V S, Nagendra (Nonstop Filesystems Team) wrote:
> > Find the entire patch we use attached.
>
> Thanks, a brief review of the patch suggests that there is enough material in
> it that we should get copyright papers signed before we can incorporate all
> those changes in the GNU version. Would you like to do that?
> If so, please let me know, and I'll start the ball rolling with the copyright clerk
> on our end.
I have already got in touch with the copyright clerk, Donald R Robertson III (via RT <copyright-clerk <at> fsf.org>) is helping us with rights assignment.
I have asked our company attorney go through the rights forms, once it's through there review process I will send out the rights copy.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Mon, 04 Mar 2013 20:14:01 GMT)
Full text and
rfc822 format available.
Message #237 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Hi folks
In an attempt to port coreutils 8.21 to HP-NonStop I stumbled accross a couple problems, here are my fixes to them:
I had to tweak configure like this
diff -EBbu ./configure.orig ./configure
--- ./configure.orig 2013-02-14 09:54:18 -0600
+++ ./configure 2013-02-18 11:04:51 -0600
@@ -8134,7 +8134,7 @@
-ALLOCA=\${LIBOBJDIR}alloca.$ac_objext
+ALLOCA=alloca.$ac_objext
$as_echo "#define C_ALLOCA 1" >>confdefs.h
Otherwise make complained "no rule to make target lib/lib/alloca.o", I'm pretty sure though that there got to be a better fix for this
There are quite a few more changes that pertain to the recursive directory traversal
Bye, Jojo
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#10305; Package
coreutils.
(Tue, 05 Mar 2013 02:53:02 GMT)
Full text and
rfc822 format available.
Message #240 received at 10305 <at> debbugs.gnu.org (full text, mbox):
Thanks, I pushed the following gnulib patch:
---
ChangeLog | 8 ++++++++
m4/non-recursive-gnulib-prefix-hack.m4 | 3 ---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 725fe13..0d2715c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2013-03-04 Paul Eggert <eggert <at> cs.ucla.edu>
+
+ non-recursive-gnulib-prefix-hack: port coreutils 8.21 to HP NonStop
+ * m4/non-recursive-gnulib-prefix-hack.m4
+ (gl_NON_RECURSIVE_GNULIB_PREFIX_HACK): Don't mess with ALLOCA.
+ Problem reported for HP NonStop + coreutils 8.21 by Joachim Schmitz in
+ <http://bugs.gnu.org/10305#237>.
+
2013-03-04 Eric Blake <eblake <at> redhat.com>
test-getsockopt: avoid compiler warning
diff --git a/m4/non-recursive-gnulib-prefix-hack.m4 b/m4/non-recursive-gnulib-prefix-hack.m4
index 3153e0f..6d27f06 100644
--- a/m4/non-recursive-gnulib-prefix-hack.m4
+++ b/m4/non-recursive-gnulib-prefix-hack.m4
@@ -29,7 +29,4 @@ AC_DEFUN([gl_NON_RECURSIVE_GNULIB_PREFIX_HACK],
(*_H:*.h) eval "$ac_var=$1/\$$ac_var";;
esac
done
-
- # If $ALLOCA is not empty, prefix its value with "lib/".
- test -n "$ALLOCA" && ALLOCA="lib/$ALLOCA"
])
--
1.7.11.7
This bug report was last modified 11 years and 49 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.