[EMAIL PROTECTED] (Eric Blake) writes:
> I'll have to test if your fix helps (my hack was just to check
> in lib/at-func.c if the current file name is "..",
That doesn't suffice in general, since the file name might be a
symlink to "..", either directly or indirectly (But you probably knew
that.
> I noticed that a build of CVS coreutils on Solaris 8 created
> executables that didn't run on Solaris 10, because on Solaris 10
> /proc/self/fd/NNN/.. is equivalent to /proc/sef/fd, not to the parent
> directory of the file with descriptor NNN. I'm not sure why Sun made
> this change, but it bro
I noticed that a build of CVS coreutils on Solaris 8 created
executables that didn't run on Solaris 10, because on Solaris 10
/proc/self/fd/NNN/.. is equivalent to /proc/sef/fd, not to the parent
directory of the file with descriptor NNN. I'm not sure why Sun made
this change, but it broke the ope
mwoehlke <[EMAIL PROTECTED]> writes:
> Would that (and the 2003 update date) mean that gzip is unmaintained?
Not necessarily, no.
Paul Eggert wrote:
[EMAIL PROTECTED] (Karl Berry) writes:
http://directory.fsf.org/gzip.html; no mention there
1.3.5 is mentioned on that Directory page as the "(devel)" release.
Anyway, I wrote rms about the lack of official releases in recent
decades.
For what it's worth, I was responsibl
Paul Eggert wrote:
> As I understand it this affects only programs
> that issue "warnings" (i.e., they output to stderr but then continue
> without affecting the exit status)
Yes, exactly. xgettext is such a program. Or also GNU tar, when
invoked as "tar xOvf tarfile somefile-in-it".
> However, w
Bruno Haible <[EMAIL PROTECTED]> writes:
> + /* Close standard error. This is simpler than fwriteerror_no_ebadf,
> because
> + upon failure we don't need an errno - all we can do at this point is to
> + set an exit status. */
> + errno = 0;
> + if (ferror (stderr) || fflush (st
Bruno Haible <[EMAIL PROTECTED]> writes:
> Hi Paul and Jim,
>
> It bothers me that in order to implement a basic functionality like the
> 'closeout' module, you need the __fpending module, which is not based on
> POSIX but rather a case-by-case hack for various platforms.
>
> Here is a proposed pa
Jim Meyering meyering.net> writes:
>
> Hi Bruno,
>
> I like the idea, but I've never worried about this case on the principle
> that if a program is already writing to stderr, it's usually because
> it's going to exit nonzero anyway.
M4 is an example of an exception - it can write to stderr wi
Jim Meyering wrote:
> This looks potentially disruptive.
> Have you tested it much?
I've verified (in gettext) that the fwriteerror_no_ebadf function works
as advertised. I haven't tested close-stream and closeout, since I don't
use them directly in my packages. You're always invited to proofread/
> In fact, I am unable to measure any significant performance difference.
Nice! It'd have been a pain if a bug on one system forced a significant
performance hit on all other systems.
Bruno
[EMAIL PROTECTED] (Karl Berry) writes:
> > with http://directory.fsf.org/gzip.html; no mention there)... which, of
>
> 1.3.5 is mentioned on that Directory page as the "(devel)" release.
>
> Anyway, I wrote rms about the lack of official releases in recent
> decades.
For what it's worth, I w
I hope this is the final iteration for a while.
Thanks to Bruno for helping to get this done right.
2006-09-29 Jim Meyering <[EMAIL PROTECTED]>
Since any system may be affected by the Darwin readdir bug,
perform the extra rewinddir unconditionally. The performance
impac
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Paul and Jim,
>
> It bothers me that in order to implement a basic functionality like the
> 'closeout' module, you need the __fpending module, which is not based on
> POSIX but rather a case-by-case hack for various platforms.
>
> Here is a proposed patc
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Paul and Jim,
>
> The closeout module currently ignores write failures on stderr.
> This patch makes it report failures on stderr through an exit status.
Hi Bruno,
I like the idea, but I've never worried about this case on the principle
that if a progr
Bruno Haible <[EMAIL PROTECTED]> wrote:
> Hi Jim,
>
> The Darwin HFS+ bug is even reproducible on Linux, on NFS mounts from a
> Darwin 10.3.9 machine. Here is that same directory, of which Darwin's
> readdir() bug occurred after 178 removals. Here it occurs already after
> 13 removals on average:
Hi Paul and Jim,
The closeout module currently ignores write failures on stderr.
This patch makes it report failures on stderr through an exit status.
2006-09-29 Bruno Haible <[EMAIL PROTECTED]>
* modules/closeout (Description): Mention stderr too.
* lib/closeout.c (close_stdo
Hi Paul and Jim,
It bothers me that in order to implement a basic functionality like the
'closeout' module, you need the __fpending module, which is not based on
POSIX but rather a case-by-case hack for various platforms.
Here is a proposed patch to lift this dependency. Instead of using
__fpendi
Hi,
I'm adding an alternative entry point to the fwriteerror module. One that
allows to ignore EBADF if it occurs only in the final fclose, i.e. if
the file descriptor had not been written and was not connected from the
beginning.
2006-09-29 Bruno Haible <[EMAIL PROTECTED]>
* fwriteer
Hi Jim,
> You mean you've found *another* problem with GNU rm?
> Is so, please provide details.
The second bug is harder to reproduce.
I have a big tar file with hard links in it.
$ tar tvf cross-hppa.tar | grep ' link '
hrwxr-xr-x bruno/user0 2002-06-02 01:20:05
cross/hppa-linux-tools/
Hi Jim,
The Darwin HFS+ bug is even reproducible on Linux, on NFS mounts from a
Darwin 10.3.9 machine. Here is that same directory, of which Darwin's
readdir() bug occurred after 178 removals. Here it occurs already after
13 removals on average:
$ ll charmaps | wc -l
195
$ rm -r charmaps
rm: cann
Paolo Bonzini wrote:
> How so? Only for EAGAIN and EINTR. If FIONREAD is supported, it will
> return EINVAL or something like that.
You're right, sorry. I was confused by the unified diffs (prefer context
diffs).
> >> + errno = 0;
> >>
> >
> > What's the purpose of that? I
Bruno Haible <[EMAIL PROTECTED]> wrote:
>> Is there any type of file system where readdir works?
>
> Yes. It does work on vfat file systems. No readdir bug reproducible there.
FYI, I've worked around that Darwin 7.9.0 bug.
The only caveat is that when running "configure" on a buggy system,
the bui
23 matches
Mail list logo
