Hi
This little patch adds 64-bit inode support for stat utility (my system
has ino_t and st_blocks 64-bit).
As there are already a lot of fields with uintmax_t type and PRIuMAX
format, I think the patch won't cause any side effects.
Mikulas
--- STAT.C_ 2004-10-23 21:12:11.0 +0100
++
Hi
I got this message from du from coreutils 5.2.1:
du: fts_read failed: No such file or directory
*** glibc detected *** corrupted double-linked list: 0x0806c390 ***
I was sometimes able reproduce on an AFS filesystem. It turned out that
AFS filesystem changes inode numbers or device numbers,
On Mon, 10 Oct 2005, Jim Meyering wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
I got this message from du from coreutils 5.2.1:
du: fts_read failed: No such file or directory
*** glibc detected *** corrupted double-linked list: 0x0806c390 ***
I was sometimes able reproduce on
On Mon, 10 Oct 2005, Paul Eggert wrote:
Mikulas Patocka <[EMAIL PROTECTED]> writes:
ftp://alpha.gnu.org/gnu/coreutils/coreutils-5.90.tar.bz2
BTW. How stable are alpha versions of GNU software from this server?
Do you think they are OK for a production multiuser machine?
That depe
On Mon, 10 Oct 2005, Paul Eggert wrote:
Mikulas Patocka <[EMAIL PROTECTED]> writes:
I mean if there's some probability that these experimental versions
will break system, possibly even breaking make install and preventing
reinstallation of old versions?
I doubt that would happ
Mikulas Patocka <[EMAIL PROTECTED]> writes:
Intel compiler's interprocedural optimizations (-ipo) optimizes this
out even though the symbol is unknown.
Wonderful. (:-)
I installed the following patch to try to catch this.
The compilation gets a bit further with the patch, b
On Mon, 24 Oct 2005, Paul Eggert wrote:
Mikulas Patocka <[EMAIL PROTECTED]> writes:
The compilation gets a bit further with the patch, but it still
doesn't work --- this time it is problem of intel compiler --- it
can't extract its intercode from *.a files.
The Intel com
On Mon, 24 Oct 2005, Stepan Kasal wrote:
Ahoj Mikulasi,
On Mon, Oct 24, 2005 at 04:01:09PM +0200, Mikulas Patocka wrote:
You can modify libtool so that when it is creating static library and
compiler is "icc" or "icpc" (or "some/path/icc" or "some/path/
Hi
I have a system that precaches directory content at opendir call and I
found that coreutils-6.7 rm -r command doesn't work on it (it used to work
fine in coreutils 5).
The problem is this: when walking up to the root in directory tree, rm
opens parent directory with opendir, then deletes
BTW. looking at the code leads me to another observation --- all those
security checks against 'rm'-vs-'mv' race break apart if the attacker is
able to create directories with colliding inode number (which can happen
on 64-bit filesystems that can store more than 2^32 files --- for example
NFS
On Wed, 20 Dec 2006, Jim Meyering wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
BTW. looking at the code leads me to another observation --- all those
security checks against 'rm'-vs-'mv' race break apart if the attacker is
Thank you for bringing this up. Howev
Mikulas Patocka <[EMAIL PROTECTED]> writes:
They have 32-bit ino_t but 64-bit stat64.st_ino
(stat64 has unsigned long long st_ino) --- although kernel has the
deficiency that it can pass only 32-bit values to it --- BTW. can you
accept that fact that sizeof(st_ino) > sizeof(ino_t) in
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
I have a system that precaches directory content at opendir call and I
found that coreutils-6.7 rm -r command doesn't work on it (it used to work
fine in coreutils 5).
The problem is this: when walking up to the root in directory tree, rm
o
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
BTW. looking at the code leads me to another observation --- all those
security checks against 'rm'-vs-'mv' race break apart if the attacker is
Thank you for bringing this up. However, note that such systems are not
POSI
Mikulas Patocka <[EMAIL PROTECTED]> writes:
If POSIX specifies something that is unimplementable (unique stable
inode numbers) the question is why to rely on it?
But it's easily implementable, if your file system was written with
POSIX in mind.
And if someone else designed it -
On Fri, 29 Dec 2006, Paul Eggert wrote:
Mikulas Patocka <[EMAIL PROTECTED]> writes:
Mikulas Patocka <[EMAIL PROTECTED]> writes:
If POSIX specifies something that is unimplementable (unique stable
inode numbers) the question is why to rely on it?
But it's easily imple
On Sat, 30 Dec 2006, Jim Meyering wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
...
There are a lot of packages that will break (sometimes subtly) on file
systems that lack stable file serial numbers: coreutils, diffutils,
git, tar, the list goes on for quite a ways. I'm afra
On Sat, 30 Dec 2006, Paul Eggert wrote:
Mikulas Patocka <[EMAIL PROTECTED]> writes:
BTW. could it be possible to change POSIX on this issue?
I very much doubt it. POSIX deliberately does not specify the
behavior of non-POSIX file systems, or of programs operating on
non-POSI
Hi
There is a bug in dd --- if libc doesn't have __fpending, coreutils will
use a stub that always returns 1. A side effect of this stub is that
close_stdout always calls fclose(stdout) --- it normally doesn't matter
for most utilities except dd --- dd calls close(1) on its own and later
fclo
On Sat, 6 Jan 2007, Jim Meyering wrote:
Mikulas Patocka <[EMAIL PROTECTED]> wrote:
There is a bug in dd --- if libc doesn't have __fpending, coreutils will
use a stub that always returns 1. A side effect of this stub is that
close_stdout always calls fclose(stdout) --- it norma
Hi
This patch fixes segmentation fault with ls on systems, where SIZE_MAX is
different from -1.
Mikulas
--- SRC/LS.C_ 2004-04-23 16:06:44.0 +0100
+++ SRC/LS.C2004-04-23 16:06:49.0 +0100
@@ -3244,7 +3244,7 @@
size_t *width)
{
char smallbuf[BUFSIZ];
- size_t
On Fri, 23 Apr 2004, Jim Meyering wrote:
> Mikulas Patocka <[EMAIL PROTECTED]> wrote:
>
> > This patch fixes segmentation fault with ls on systems, where SIZE_MAX is
> > different from -1.
>
> Thank you!
> I suppose you noticed the actual segfault.
> What t
22 matches
Mail list logo
