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
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
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
: coreutils-8.14, rm -r fails with EBADF
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Saturday, July 21, 2012 7:38 AM
To: Joachim Schmitz
Cc: 10...@debbugs.gnu.org; bug-gnu...@gnu.org; 'Eric Blake'; 'Jim Meyering';
'Schmitz, Joachim'; nagendra...@hp.com
Subject: Re: bug#10305: coreutils
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Saturday, July 21, 2012 7:38 AM
To: Joachim Schmitz
Cc: 10...@debbugs.gnu.org; bug-gnu...@gnu.org; 'Eric Blake'; 'Jim Meyering';
'Schmitz, Joachim'; nagendra...@hp.com
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
On 07
-digital.de]
Sent: Thursday, July 19, 2012 11:24 PM
To: 'Paul Eggert'
Cc: 10...@debbugs.gnu.org; bug-gnu...@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
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.c2012-06-18 10:06:04 -0500
@@ -88,6 +88,7 @@
return st;
}
From: Jim Meyering [mailto:j...@meyering.net]
Sent: Friday, July 20, 2012 2:35 PM
To: Joachim Schmitz
Cc: 'Paul Eggert'; 10...@debbugs.gnu.org; bug-gnu...@gnu.org; 'Eric
Blake';
'Schmitz, Joachim'; nagendra...@hp.com
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
Joachim
Joachim Schmitz wrote:
From: Jim Meyering [mailto:j...@meyering.net]
Sent: Friday, July 20, 2012 2:35 PM
To: Joachim Schmitz
Cc: 'Paul Eggert'; 10...@debbugs.gnu.org; bug-gnu...@gnu.org; 'Eric
Blake';
'Schmitz, Joachim'; nagendra...@hp.com
Subject: Re: bug#10305: coreutils-8.14, rm -r
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
From: Jim Meyering [mailto:j...@meyering.net]
Sent: Friday, July 20, 2012 3:48 PM
To: Joachim Schmitz
Cc: 'Paul Eggert'; 10...@debbugs.gnu.org; bug-gnu...@gnu.org; 'Eric
Blake';
'Schmitz, Joachim'; nagendra...@hp.com
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
Joachim
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
Joachim Schmitz wrote:
From: Jim Meyering [mailto:j...@meyering.net]
Sent: Friday, July 20, 2012 3:48 PM
To: Joachim Schmitz
Cc: 'Paul Eggert'; 10...@debbugs.gnu.org; bug-gnu...@gnu.org; 'Eric
Blake';
'Schmitz, Joachim'; nagendra...@hp.com
Subject: Re: bug#10305: coreutils-8.14, rm -r
-Original Message-
From: Jim Meyering [mailto:j...@meyering.net]
Sent: Friday, July 20, 2012 4:07 PM
To: Joachim Schmitz
Cc: 'Paul Eggert'; bug-gnu...@gnu.org; nagendra...@hp.com;
10...@debbugs.gnu.org; 'Schmitz, Joachim'; 'Eric Blake'
Subject: Re: bug#10305: coreutils-8.14, rm -r
From: Joachim Schmitz [mailto:j...@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
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
-Original Message-
From: Jim Meyering [mailto:j...@meyering.net]
Sent: Friday, July 20, 2012 4:28 PM
To: Joachim Schmitz
Cc: 'Paul Eggert'; bug-gnu...@gnu.org; nagendra...@hp.com;
10...@debbugs.gnu.org; 'Schmitz, Joachim'; 'Eric Blake'
Subject: Re: bug#10305: coreutils-8.14, rm -r
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
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
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
From: Eric Blake [mailto:ebl...@redhat.com]
Sent: Friday, July 20, 2012 4:48 PM
To: Joachim Schmitz
Cc: 'Jim Meyering'; 'Paul Eggert'; bug-gnu...@gnu.org; nagendra...@hp.com;
10...@debbugs.gnu.org; 'Schmitz, Joachim'
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
On 07/20
From: Stefano Lattarini [mailto:stefano.lattar...@gmail.com]
Sent: Friday, July 20, 2012 4:50 PM
To: Joachim Schmitz
Cc: 'Jim Meyering'; 'Paul Eggert'; bug-gnu...@gnu.org; 'Eric Blake';
10...@debbugs.gnu.org; 'Schmitz, Joachim'; nagendra...@hp.com
Subject: Re: bug#10305: coreutils-8.14, rm
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
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Wednesday, June 27, 2012 2:49 AM
To: Joachim Schmitz
Cc: 10...@debbugs.gnu.org; bug-gnu...@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
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Sunday, January 15, 2012 7:01 AM
To: Joachim Schmitz
Cc: 10...@debbugs.gnu.org; bug-gnu...@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
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 br...@clisp.org
argp, regex:
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
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
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
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Sunday, January 15, 2012 7:01 AM
To: Joachim Schmitz
Cc: 10...@debbugs.gnu.org; bug-gnu...@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
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Thursday, December 22, 2011 10:15 AM
To: Joachim Schmitz
Cc: 'Eric Blake'; 'Jim Meyering'; 10...@debbugs.gnu.org; bug-gnu...@gnu.org
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
On 12/21/11 23:54, Joachim Schmitz wrote
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
From: Eric Blake [mailto:ebl...@redhat.com]
Sent: Wednesday, December 21, 2011 6:32 PM
To: Joachim Schmitz
Cc: 'Jim Meyering'; 10...@debbugs.gnu.org; 'Paul Eggert'; bug-
gnu...@gnu.org
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
On 12/21/2011 10:12 AM, Joachim Schmitz
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,
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Monday, December 19, 2011 6:29 PM
To: Joachim Schmitz
Cc: 10...@debbugs.gnu.org; bug-gnu...@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
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)
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
From: Eric Blake [mailto:ebl...@redhat.com]
Sent: Wednesday, December 21, 2011 5:28 PM
To: Jim Meyering
Cc: Joachim Schmitz; 10...@debbugs.gnu.org; 'Paul Eggert'; bug-
gnu...@gnu.org
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
On 12/21/2011 09:06 AM, Jim Meyering wrote
From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
Sent: Wednesday, December 21, 2011 6:12 PM
To: 'Eric Blake'; 'Jim Meyering'
Cc: '10...@debbugs.gnu.org'; 'Paul Eggert'; 'bug-gnu...@gnu.org'
Subject: RE: bug#10305: coreutils-8.14, rm -r fails with EBADF
From: Eric Blake [mailto:ebl
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
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,
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
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Wednesday, December 21, 2011 7:42 PM
To: Eric Blake
Cc: Jim Meyering; 10...@debbugs.gnu.org; Joachim Schmitz; bug-
gnu...@gnu.org
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
On 12/21/11 08:27, Eric Blake wrote:
maybe
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Sunday, December 18, 2011 11:24 PM
To: Joachim Schmitz
Cc: 10...@debbugs.gnu.org; bug-gnu...@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
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
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Saturday, December 17, 2011 1:27 AM
To: Joachim Schmitz
Cc: 'Eric Blake'; 'Jim Meyering'; 10...@debbugs.gnu.org; bug-gnu...@gnu.org
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
On 12/16/11 13:21, Joachim Schmitz wrote
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;
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Thursday, December 15, 2011 7:07 PM
To: Joachim Schmitz
Cc: Jim Meyering; bug-coreutils@gnu.org; bug-gnu...@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
From: Jim Meyering [mailto:j...@meyering.net]
Sent: Friday, December 16, 2011 11:51 AM
To: Joachim Schmitz
Cc: 'Paul Eggert'; bug-gnu...@gnu.org; bug-coreutils@gnu.org
Subject: Re: coreutils-8.14, rm -r fails with EBADF
Joachim Schmitz wrote:
From: Paul Eggert
Joachim Schmitz wrote:
From: Jim Meyering [mailto:j...@meyering.net]
Sent: Friday, December 16, 2011 11:51 AM
To: Joachim Schmitz
Cc: 'Paul Eggert'; bug-gnu...@gnu.org; bug-coreutils@gnu.org
Subject: Re: coreutils-8.14, rm -r fails with EBADF
Joachim Schmitz wrote:
From: Paul Eggert
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.
From: Eric Blake [mailto:ebl...@redhat.com]
Sent: Friday, December 16, 2011 2:42 PM
To: Joachim Schmitz
Cc: 'Jim Meyering'; 10...@debbugs.gnu.org; egg...@cs.ucla.edu; bug-
gnu...@gnu.org
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
On 12/16/2011 06:02 AM, Joachim Schmitz
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.
From: Paul Eggert [mailto:egg...@cs.ucla.edu]
Sent: Friday, December 16, 2011 7:47 PM
To: Joachim Schmitz
Cc: 'Eric Blake'; 'Jim Meyering'; 10...@debbugs.gnu.org; bug-gnu...@gnu.org
Subject: Re: bug#10305: coreutils-8.14, rm -r fails with EBADF
On 12/16/11 05:46, Joachim Schmitz wrote
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
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
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
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
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
59 matches
Mail list logo
