On Thursday 12 February 2009 14:27:09 Jim Meyering wrote:
While rewriting that,
install accepts a new option, --compare (-C): compare each pair of source
and destination files, and if the destination has identical content and
any specified owner, group, permissions, and possibly SELinux
Kamil Dudka wrote:
On Thursday 12 February 2009 14:27:09 Jim Meyering wrote:
While rewriting that,
install accepts a new option, --compare (-C): compare each pair of source
and destination files, and if the destination has identical content and
any specified owner, group, permissions,
On Monday 16 February 2009 11:07:56 you wrote:
Kamil Dudka wrote:
On Thursday 12 February 2009 14:27:09 Jim Meyering wrote:
While rewriting that,
install accepts a new option, --compare (-C): compare each pair of
source and destination files, and if the destination has identical
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Pádraig Brady on 2/16/2009 3:07 AM:
+static bool
+have_same_content (int a_fd, int b_fd)
+{
+#define CMP_BLOCK_SIZE 65536
+ char a_buff[CMP_BLOCK_SIZE];
+ char b_buff[CMP_BLOCK_SIZE];
Is 128KiB of stack OK?
In general, no.
Kamil Dudka kdu...@redhat.com wrote:
On Thursday 12 February 2009 14:27:09 Jim Meyering wrote:
While rewriting that,
install accepts a new option, --compare (-C): compare each pair of source
and destination files, and if the destination has identical content and
any specified owner,
Jim Meyering wrote:
Unfortunately, with this patch, make check fails the cp/link-heap test.
Investigating why, I discovered that it introduces a huge leak into
cp -a, at least on F10. 80MB worth in this case.
I'll let you investigate that one ;-)
Leak is in libattr - added by 2.4.43 (~8
Kamil Dudka wrote:
On Monday 16 February 2009 11:07:56 you wrote:
Is 128KiB of stack OK?
I noticed this related email from Eric:
http://lists.gnu.org/archive/html/m4-patches/2008-08/msg1.html
The idea of 64KiB on stack allocated buffers was taken from RHEL4
implementation. But you are
Ondřej Vašík ova...@redhat.com wrote:
Jim Meyering wrote:
Unfortunately, with this patch, make check fails the cp/link-heap test.
Investigating why, I discovered that it introduces a huge leak into
cp -a, at least on F10. 80MB worth in this case.
I'll let you investigate that one ;-)
Leak
Pádraig Brady p...@draigbrady.com wrote:
Kamil Dudka wrote:
On Monday 16 February 2009 11:07:56 you wrote:
Is 128KiB of stack OK?
I noticed this related email from Eric:
http://lists.gnu.org/archive/html/m4-patches/2008-08/msg1.html
The idea of 64KiB on stack allocated buffers was taken
In http://bugzilla.redhat.com/485507
Eric Sandeen proposed to add ext4 to the list of names
currently reported for that type of file system (ext2/ext3).
I'm reluctant to change that string, because doing so might
well break scripts that rely on them:
case $(stat -f --format %T .) in
Eric Sandeen sand...@redhat.com wrote:
Jim Meyering wrote:
In http://bugzilla.redhat.com/485507
Eric Sandeen proposed to add ext4 to the list of names
currently reported for that type of file system (ext2/ext3).
I'm reluctant to change that string, because doing so might
well break scripts
Jim Meyering wrote:
Eric Sandeen sand...@redhat.com wrote:
Jim Meyering wrote:
In http://bugzilla.redhat.com/485507
Eric Sandeen proposed to add ext4 to the list of names
currently reported for that type of file system (ext2/ext3).
I'm reluctant to change that string, because doing so
Eric Sandeen wrote on 02/16/2009 06:53 PM:
Jim Meyering wrote:
How much code (and how ugly) would be required to distinguish ext4
from ext[23]?
it'd need to be able to do some parsing of the ext2/3/4 feature flags,
so it'd need to know some ext2/3/4 details.
lib/blkid/probe.c in e2fsprogs is
13 matches
Mail list logo
