date:20080716

[PATCH] * HACKING: describe how to find a misplaced change-set

2008-07-16 Thread Jim Meyering

This isn't the sort of thing you do every day, but it's handy
not to have to dig through documentation for a recipe:

Here's a proposed change to HACKING:

>From a28d580f4729170f26a7ec40a19ee4d6301acf3d Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Wed, 16 Jul 2008 12:25:00 +0200
Subject: [PATCH] * HACKING: describe how to find a misplaced change-set

---
 HACKING |   14 ++
 1 files changed, 14 insertions(+), 0 deletions(-)

diff --git a/HACKING b/HACKING
index 457048e..7d8bcb3 100644
--- a/HACKING
+++ b/HACKING
@@ -360,6 +360,20 @@ Miscellaneous useful git commands
   you an interface with which you can reorder and modify arbitrary
   change sets on that branch.

+  * if you "misplace" a change set, i.e., via git reset --hard ..., so that
+it's no longer reachable by any branch, you can use "git fsck" to find
+its SHA1 and then tag it or cherry-pick it onto an existing branch.
+For example, run this:
+  git fsck --lost-found HEAD && cd .git/lost-found/commit \
+   && for i in *; do git show $i|grep SOME_IDENTIFYING_STRING \
+   && echo $i; done
+The "git fsck ..." command creates the .git/lost-found/... hierarchy
+listing all unreachable objects.  Then the for loop
+print SHA1s for commits that match via log or patch.
+For example, say that found 556fbb57216b119155cdda824c98dc579b8121c8,
+you could run "git show 556fbb57216b119" to examine the change set,
+or "git checkout -b found 556fbb5721" to give it a branch name.
+
 ---

 Finding things to do
--
1.5.6.3.386.gc8666


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

if you use ptx, please let us know [Re: ptx bug (invalid read)

2008-07-16 Thread Jim Meyering

Cristian Cadar <[EMAIL PROTECTED]> wrote:
>Hello, I found an older bug report generated by our tool for ptx,
> which I forgot to report.  The bug is still present in the current
> version of Coreutils (6.12).  I did not have time to investigate the
> root cause of the bug, but I'm including a very simple test case and the
> output reported by valgrind:
>
> $ echo -n a>A && valgrind ptx x A
> ==9357== Memcheck, a memory error detector.
> ==9357== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ...
> ==9357== Invalid read of size 1
> ==9357==at 0x804B0F5: define_all_fields (ptx.c:1516)
> ==9357==by 0x804BF64: generate_all_output (ptx.c:1846)
> ==9357==by 0x804C9D9: main (ptx.c:2218)
> ==9357==  Address 0x4022391 is 0 bytes after a block of size 1 alloc'd
> ==9357==at 0x40054E5: malloc (vg_replace_malloc.c:149)
> ==9357==by 0x804F4C5: xmalloc (xmalloc.c:49)
> ==9357==by 0x804984C: swallow_file_in_memory (ptx.c:547)
> ==9357==by 0x804C994: main (ptx.c:2203)

Thanks for finding and reporting that!
Looking into it, I found two shallow bugs (patched below)
and added some basic tests.
With this patch, the problem you found is still reproducible,
but requires a slightly different invocation:

  echo -n a>A && valgrind ptx A A

The trouble is that global state is reused
when processing the second and subsequent
file argument.  Fixing that will require a more
invasive change, and I'm not convinced it's even
worth my time.  Does anyone even use ptx these day?
Does anyone rely on the GNU extension of accepting more
than one input file?  Since it appears that feature has never
worked properly, I seriously doubt it.  So I'm considering
whether to add ptx to the list of programs that are not
installed by default.

Jim

>From 773be9eca85da9a9a33d42d29ecfd04c9aec5c3f Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Tue, 15 Jul 2008 08:30:38 +0200
Subject: [PATCH] fix two bugs in ptx

* src/ptx.c (fix_output_parameters): Don't let before_max_width
go negative -- that would cause an infloop in define_all_fields.
(main): Don't clobber name[0] with lists of two or more input files.
* tests/misc/ptx: New file.  Test for the above.
* tests/Makefile.am (TESTS): Add misc/ptx.
---
 src/ptx.c |7 ---
 tests/Makefile.am |1 +
 tests/misc/ptx|   44 
 3 files changed, 49 insertions(+), 3 deletions(-)
 create mode 100755 tests/misc/ptx

diff --git a/src/ptx.c b/src/ptx.c
index 827d22e..c04c90c 100644
--- a/src/ptx.c
+++ b/src/ptx.c
@@ -1353,6 +1353,8 @@ fix_output_parameters (void)
 right side, or one on either side.  */

   before_max_width -= 2 * truncation_string_length;
+  if (before_max_width < 0)
+   before_max_width = 0;
   keyafter_max_width -= 2 * truncation_string_length;
 }
   else
@@ -2112,11 +2114,10 @@ main (int argc, char **argv)

   for (file_index = 0; file_index < number_input_files; file_index++)
{
- input_file_name[file_index] = argv[optind];
  if (!*argv[optind] || STREQ (argv[optind], "-"))
-   input_file_name[0] = NULL;
+   input_file_name[file_index] = NULL;
  else
-   input_file_name[0] = argv[optind];
+   input_file_name[file_index] = argv[optind];
  optind++;
}
 }
diff --git a/tests/Makefile.am b/tests/Makefile.am
index f7275f8..c2da630 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -120,6 +120,7 @@ TESTS = \
   chgrp/no-x   \
   chgrp/posix-H\
   chgrp/recurse\
+  misc/ptx \
   misc/test\
   misc/seq \
   misc/head\
diff --git a/tests/misc/ptx b/tests/misc/ptx
new file mode 100755
index 000..cfc1544
--- /dev/null
+++ b/tests/misc/ptx
@@ -0,0 +1,44 @@
+#!/usr/bin/perl
+
+# Copyright (C) 2008 Free Software Foundation, Inc.
+
+# This program is free software: you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see .
+
+use strict;
+
+my $prog = 'ptx';
+
+# Turn off localization of executable's output.
[EMAIL PROTECTED](LANGUAGE LANG LC_ALL)} = ('C') x 3;
+
+my @Tests =
+(
+["1tok", '-w10', {IN=>"bar\n"}, {OUT=>

Re: if you use ptx, please let us know [Re: ptx bug (invalid read)

2008-07-16 Thread Bauke Jan Douma


Jim Meyering wrote on 16-07-08 12:47:


The trouble is that global state is reused
when processing the second and subsequent
file argument.  Fixing that will require a more
invasive change, and I'm not convinced it's even
worth my time.  Does anyone even use ptx these day?


Me, sometimes.


Does anyone rely on the GNU extension of accepting more
than one input file?  Since it appears that feature has never
worked properly, I seriously doubt it.  So I'm considering


Not me.


whether to add ptx to the list of programs that are not
installed by default.


Hmmm...


bjd


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: [bug #23798] Proposal to add some new free & open file formats to src/dircolors.hin

2008-07-16 Thread Jim Meyering

> Details:
>
> With reference to this Xiph.org (the organisation behind free video and audio
> codecs) document http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
> I'd propose to add the following lines to src/dircolors.hin:
>
> # the list of image & video formats
> .axv 01;35
> .anx 01;35
> .ogv 01;35
> .ogx 01;35
>
> # the list of audio formats
> .axa 00:;36
> .oga 00:;36
> .spx 00:;36
> .xspf 00:;36

Thank you!
I expect to push this patch soon:

>From 6ce2e99201a03f034f804ab9f2407f78f76b54d2 Mon Sep 17 00:00:00 2001
From: Jim Meyering <[EMAIL PROTECTED]>
Date: Wed, 16 Jul 2008 13:01:03 +0200
Subject: [PATCH] dircolors.hin: Add Ogg/Theora-realted extensions.

* dircolors.hin: Add extensions from
http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
Suggestion from [EMAIL PROTECTED]
---
 src/dircolors.hin |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/src/dircolors.hin b/src/dircolors.hin
index 25dfc6e..38914c8 100644
--- a/src/dircolors.hin
+++ b/src/dircolors.hin
@@ -169,6 +169,12 @@ EXEC 01;32
 .xwd 01;35
 .yuv 01;35

+# http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
+.axv 01;35
+.anx 01;35
+.ogv 01;35
+.ogx 01;35
+
 # audio formats
 .aac 00;36
 .au 00;36
@@ -181,3 +187,9 @@ EXEC 01;32
 .ogg 00;36
 .ra 00;36
 .wav 00;36
+
+# http://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions
+.axa 00;36
+.oga 00;36
+.spx 00;36
+.xspf 00;36
--
1.5.6.3.386.gc8666


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[bug #23798] Proposal to add some new free & open file formats to src/dircolors.hin

2008-07-16 Thread Jim Meyering


Update of bug #23798 (project coreutils):

  Status:None => Fixed  

___

Follow-up Comment #1:

Thanks!  I've addressed this with the following patch:

http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/14037/focus=14082

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: du: cache directory size

2008-07-16 Thread Pádraig Brady

Pádraig Brady wrote:
> Mildred wrote:
>> Hi,
>>
>> I noticed that du takes a long time to scan directories and measure
>> disk usage.
>>
>> I was thinking that perhaps caching the size of directories could bu
>> useful. Perhaps, after du computes the size of a directory, it could
>> write its size in its extended attributes (if the filesystem support
>> it). Next time, du would only compare the directory atime (or mtime
>> perhaps) with the time of the scan. That could possibly save some time
>> during the scan.
> 
> Those values would be invalidated though once a change
> has been written anywhere in the tree under a directory.

I just noticed the announcement of the Ceph distributed file system
which does maintain tree sizes for each node:

http://lkml.org/lkml/2008/7/15/385



___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

sha1sum

2008-07-16 Thread U. George

is there a way to get an option that will print ONLY failed 
check(summed) files ?


There are thousand of files, and really only want to know of the ones 
that failed.


thanks


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: sha1sum

2008-07-16 Thread Eric Blake


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to U. George on 7/16/2008 5:55 AM:
| is there a way to get an option that will print ONLY failed
| check(summed) files ?

As a matter of fact, there will be, in coreutils 6.13.  But unfortunately,
no released version has it yet.

http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=86535835f

- --
Don't work too hard, make some time for fun as well!

Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh96O4ACgkQ84KuGfSFAYBCZACfXdIcBIY9AG7p3300wG7YnPGp
O9sAoJDS+VaaxvYL1CB1rTJmYx8GyJvd
=nQBT
-END PGP SIGNATURE-


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

filesizes/diskusage with ls, du, df only on xen-images

2008-07-16 Thread tstaps


Hallo!

I have a problem, that is testet only on one machine.

I've created an filesystem with 5G:
[EMAIL PROTECTED] ~]# lvcreate -L 5G -n lv_opt_image1 vg_opt
Logical volume "lv_opt_image1" created
[EMAIL PROTECTED] ~]# mke2fs -j /dev/vg_opt/lv_opt_image1
mke2fs 1.39 (29-May-2006)

[EMAIL PROTECTED] ~]# tune2fs -c0 -i0 /dev/vg_opt/lv_opt_image1
[EMAIL PROTECTED] ~]# mkdir /opt/image1
[EMAIL PROTECTED] ~]# mount /dev/vg_opt/lv_opt_image1 /opt/image1
[EMAIL PROTECTED] ~]# cd /opt/image1
[EMAIL PROTECTED] image1]# df -k .
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg_opt-lv_opt_image1
5160576 141440 4756992 3% /opt/image1
[EMAIL PROTECTED] image1]#

correct

(the image I used, was created as a disk with 2GB size)

[EMAIL PROTECTED] image1]# cp /var/lib/xen/images/xc51small.hda .
[EMAIL PROTECTED] image1]# file xc51small.hda
xc51small.hda: x86 boot sector; partition 1: ID=0x83, active, starthead 1, 
startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, 
startsector 208845, 3984120 sectors, code offset 0x48

[EMAIL PROTECTED] image1]# df -k .
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg_opt-lv_opt_image1
5160576 1087236 3811196 23% /opt/image1
^^^ ?
[EMAIL PROTECTED] image1]# ls -l
insgesamt 945812
drwx-- 2 root root 16384 16. Jul 17:52 lost+found
-rwxr-xr-x 1 root root 2147483649 16. Jul 17:55 xc51small.hda
[EMAIL PROTECTED] image1]# du -k xc51small.hda
945796 xc51small.hda ?
[EMAIL PROTECTED] image1]# du -b xc51small.hda
2147483649 xc51small.hda

Other way: I will change the filetype:

[EMAIL PROTECTED] image1]# dd if=/dev/zero of=dummy bs=1k count=1
1+0 Datensätze ein
1+0 Datensätze aus
1024 Bytes (1,0 kB) kopiert, 3,3e-05 Sekunden, 31,0 MB/s

[EMAIL PROTECTED] image1]# cat xc51small.hda >> dummy

[EMAIL PROTECTED] image1]# file xc51small.hda dummy
xc51small.hda: x86 boot sector; partition 1: ID=0x83, active, starthead 1, 
startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, 
startsector 208845, 3984120 sectors, code offset 0x48

dummy: data

[EMAIL PROTECTED] image1]# ls -l
insgesamt 3045020
-rw-r--r-- 1 root root 2147484673 16. Jul 18:00 dummy
drwx-- 2 root root 16384 16. Jul 17:52 lost+found
-rwxr-xr-x 1 root root 2147483649 16. Jul 17:55 xc51small.hda

[EMAIL PROTECTED] image1]# du -k BOINC Desktop Mail basis bin daten dead.letter 
druck firefox handbuch.pdf ldap libjavaplugin_oji.so lost+found mail privat 
prog raeume rep.txt tmp tmp1 tmp2 vmw vmw.sh vmware
2099208 dummy
16 lost+found
945796 xc51small.hda

[EMAIL PROTECTED] image1]# du -b BOINC Desktop Mail basis bin daten dead.letter 
druck firefox handbuch.pdf ldap libjavaplugin_oji.so lost+found mail privat 
prog raeume rep.txt tmp tmp1 tmp2 vmw vmw.sh vmware
2147484673 dummy
16384 lost+found
2147483649 xc51small.hda

[EMAIL PROTECTED] image1]# df -k .
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg_opt-lv_opt_image1
5160576 3186444 1711988 66% /opt/image1

it seems, that the original image only need round about 1GB


Next way: df shows low use, also can I copy?

[EMAIL PROTECTED] image1]# rm dummy
[EMAIL PROTECTED] image1]# ll
insgesamt 945812
drwx-- 2 root root 16384 16. Jul 17:52 lost+found
-rwxr-xr-x 1 root root 2147483649 16. Jul 17:55 xc51small.hda
[EMAIL PROTECTED] image1]# for D in 1 2 3 4 ; do cp xc51small.hda xc51small.hda$D 
; done

[EMAIL PROTECTED] image1]# echo $?
0
[EMAIL PROTECTED] image1]# du -b
16384 ./lost+found
10737438725 .
[EMAIL PROTECTED] image1]# du -b BOINC Desktop Mail basis bin daten dead.letter 
druck firefox handbuch.pdf ldap libjavaplugin_oji.so lost+found mail privat 
prog raeume rep.txt tmp tmp1 tmp2 vmw vmw.sh vmware
16384 lost+found
2147483649 xc51small.hda
2147483649 xc51small.hda1
2147483649 xc51small.hda2
2147483649 xc51small.hda3
2147483649 xc51small.hda4
[EMAIL PROTECTED] image1]# du -k BOINC Desktop Mail basis bin daten dead.letter 
druck firefox handbuch.pdf ldap libjavaplugin_oji.so lost+found mail privat 
prog raeume rep.txt tmp tmp1 tmp2 vmw vmw.sh vmware
16 lost+found
945796 xc51small.hda
945796 xc51small.hda1
945796 xc51small.hda2
945796 xc51small.hda3
945796 xc51small.hda4
[EMAIL PROTECTED] image1]# df -k .
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg_opt-lv_opt_image1
5160576 4870420 28012 100% /opt/image1
[EMAIL PROTECTED] image1]# ls -l
insgesamt 4728996
drwx-- 2 root root 16384 16. Jul 17:52 lost+found
-rwxr-xr-x 1 root root 2147483649 16. Jul 17:55 xc51small.hda
-rwxr-xr-x 1 root root 2147483649 16. Jul 18:04 xc51small.hda1
-rwxr-xr-x 1 root root 2147483649 16. Jul 18:05 xc51small.hda2
-rwxr-xr-x 1 root root 2147483649 16. Jul 18:05 xc51small.hda3
-rwxr-xr-x 1 root root 2147483649 16. Jul 18:06 xc51small.hda4

there are now 5 files with 2G each in one 5G filesystem I don't no 
why...

I hope, you can help (possible not only) me!

Thanks for your work!

tstaps
___
Bug-coreutils mailing

filesizes/diskusage with ls, du, df only on xen-images (fwd)

2008-07-16 Thread tstaps




-- Forwarded message --
Date: Wed, 16 Jul 2008 19:13:04 +0200 (CEST)
From: tstaps <[EMAIL PROTECTED]>
To: bug-coreutils@gnu.org
Subject: filesizes/diskusage with ls, du, df only on xen-images

Hallo!

I have a problem, that is testet only on one machine.

I've created an filesystem with 5G:
[EMAIL PROTECTED] ~]# lvcreate -L 5G -n lv_opt_image1 vg_opt
Logical volume "lv_opt_image1" created
[EMAIL PROTECTED] ~]# mke2fs -j /dev/vg_opt/lv_opt_image1
mke2fs 1.39 (29-May-2006)

[EMAIL PROTECTED] ~]# tune2fs -c0 -i0 /dev/vg_opt/lv_opt_image1
[EMAIL PROTECTED] ~]# mkdir /opt/image1
[EMAIL PROTECTED] ~]# mount /dev/vg_opt/lv_opt_image1 /opt/image1
[EMAIL PROTECTED] ~]# cd /opt/image1
[EMAIL PROTECTED] image1]# df -k .
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg_opt-lv_opt_image1
5160576 141440 4756992 3% /opt/image1
[EMAIL PROTECTED] image1]#

correct

(the image I used, was created as a disk with 2GB size)

[EMAIL PROTECTED] image1]# cp /var/lib/xen/images/xc51small.hda .
[EMAIL PROTECTED] image1]# file xc51small.hda
xc51small.hda: x86 boot sector; partition 1: ID=0x83, active, starthead 1, 
startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, startsector 
208845, 3984120 sectors, code offset 0x48

[EMAIL PROTECTED] image1]# df -k .
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg_opt-lv_opt_image1
5160576 1087236 3811196 23% /opt/image1
^^^ ?
[EMAIL PROTECTED] image1]# ls -l
insgesamt 945812
drwx-- 2 root root 16384 16. Jul 17:52 lost+found
-rwxr-xr-x 1 root root 2147483649 16. Jul 17:55 xc51small.hda
[EMAIL PROTECTED] image1]# du -k xc51small.hda
945796 xc51small.hda ?
[EMAIL PROTECTED] image1]# du -b xc51small.hda
2147483649 xc51small.hda

Other way: I will change the filetype:

[EMAIL PROTECTED] image1]# dd if=/dev/zero of=dummy bs=1k count=1
1+0 Datensätze ein
1+0 Datensätze aus
1024 Bytes (1,0 kB) kopiert, 3,3e-05 Sekunden, 31,0 MB/s

[EMAIL PROTECTED] image1]# cat xc51small.hda >> dummy

[EMAIL PROTECTED] image1]# file xc51small.hda dummy
xc51small.hda: x86 boot sector; partition 1: ID=0x83, active, starthead 1, 
startsector 63, 208782 sectors; partition 2: ID=0x8e, starthead 0, startsector 
208845, 3984120 sectors, code offset 0x48

dummy: data

[EMAIL PROTECTED] image1]# ls -l
insgesamt 3045020
-rw-r--r-- 1 root root 2147484673 16. Jul 18:00 dummy
drwx-- 2 root root 16384 16. Jul 17:52 lost+found
-rwxr-xr-x 1 root root 2147483649 16. Jul 17:55 xc51small.hda

[EMAIL PROTECTED] image1]# du -k BOINC Desktop Mail basis bin daten dead.letter 
druck firefox handbuch.pdf ldap libjavaplugin_oji.so lost+found mail privat 
prog raeume rep.txt tmp tmp1 tmp2 vmw vmw.sh vmware
2099208 dummy
16 lost+found
945796 xc51small.hda

[EMAIL PROTECTED] image1]# du -b BOINC Desktop Mail basis bin daten dead.letter 
druck firefox handbuch.pdf ldap libjavaplugin_oji.so lost+found mail privat 
prog raeume rep.txt tmp tmp1 tmp2 vmw vmw.sh vmware
2147484673 dummy
16384 lost+found
2147483649 xc51small.hda

[EMAIL PROTECTED] image1]# df -k .
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg_opt-lv_opt_image1
5160576 3186444 1711988 66% /opt/image1

it seems, that the original image only need round about 1GB


Next way: df shows low use, also can I copy?

[EMAIL PROTECTED] image1]# rm dummy
[EMAIL PROTECTED] image1]# ll
insgesamt 945812
drwx-- 2 root root 16384 16. Jul 17:52 lost+found
-rwxr-xr-x 1 root root 2147483649 16. Jul 17:55 xc51small.hda
[EMAIL PROTECTED] image1]# for D in 1 2 3 4 ; do cp xc51small.hda xc51small.hda$D ; 
done

[EMAIL PROTECTED] image1]# echo $?
0
[EMAIL PROTECTED] image1]# du -b
16384 ./lost+found
10737438725 .
[EMAIL PROTECTED] image1]# du -b BOINC Desktop Mail basis bin daten dead.letter 
druck firefox handbuch.pdf ldap libjavaplugin_oji.so lost+found mail privat 
prog raeume rep.txt tmp tmp1 tmp2 vmw vmw.sh vmware
16384 lost+found
2147483649 xc51small.hda
2147483649 xc51small.hda1
2147483649 xc51small.hda2
2147483649 xc51small.hda3
2147483649 xc51small.hda4
[EMAIL PROTECTED] image1]# du -k BOINC Desktop Mail basis bin daten dead.letter 
druck firefox handbuch.pdf ldap libjavaplugin_oji.so lost+found mail privat 
prog raeume rep.txt tmp tmp1 tmp2 vmw vmw.sh vmware
16 lost+found
945796 xc51small.hda
945796 xc51small.hda1
945796 xc51small.hda2
945796 xc51small.hda3
945796 xc51small.hda4
[EMAIL PROTECTED] image1]# df -k .
Dateisystem 1K-Blöcke Benutzt Verfügbar Ben% Eingehängt auf
/dev/mapper/vg_opt-lv_opt_image1
5160576 4870420 28012 100% /opt/image1
[EMAIL PROTECTED] image1]# ls -l
insgesamt 4728996
drwx-- 2 root root 16384 16. Jul 17:52 lost+found
-rwxr-xr-x 1 root root 2147483649 16. Jul 17:55 xc51small.hda
-rwxr-xr-x 1 root root 2147483649 16. Jul 18:04 xc51small.hda1
-rwxr-xr-x 1 root root 2147483649 16. Jul 18:05 xc51small.hda2
-rwxr-xr-x 1 root root 2147483649 16. Jul 18:05 xc51small.hda3
-rwxr-xr-x 1 root root 2147483649 16. Jul 18:06 xc51small.hda4

there are now 5

Re: if you use ptx, please let us know [Re: ptx bug (invalid read)

2008-07-16 Thread Cristian Cadar


  Hi Jim, thanks for confirming the bug.  I don't use ptx myself, but
more importantly, I wanted to add that in our experience with testing
Coreutils, we found ptx to be one of the most complex utilities (for
example, it is the fourth in terms of lines of code in the front-end, so
more opportunities for bugs), and at the same time one of the most
poorly tested programs in the suite (at only 19.9% statement coverage as
of v6.10, in strong contrast with the other utilities -- the average
being at 67.5% in v6.10, see
http://keeda.stanford.edu/~cristic/coreutils-dev-tests/src/ for
details).
 
  Best,
  Cristian

On Wed, 2008-07-16 at 12:47 +0200, Jim Meyering wrote:
> Cristian Cadar <[EMAIL PROTECTED]> wrote:
> >Hello, I found an older bug report generated by our tool for ptx,
> > which I forgot to report.  The bug is still present in the current
> > version of Coreutils (6.12).  I did not have time to investigate the
> > root cause of the bug, but I'm including a very simple test case and the
> > output reported by valgrind:
> >
> > $ echo -n a>A && valgrind ptx x A
> > ==9357== Memcheck, a memory error detector.
> > ==9357== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> > ...
> > ==9357== Invalid read of size 1
> > ==9357==at 0x804B0F5: define_all_fields (ptx.c:1516)
> > ==9357==by 0x804BF64: generate_all_output (ptx.c:1846)
> > ==9357==by 0x804C9D9: main (ptx.c:2218)
> > ==9357==  Address 0x4022391 is 0 bytes after a block of size 1 alloc'd
> > ==9357==at 0x40054E5: malloc (vg_replace_malloc.c:149)
> > ==9357==by 0x804F4C5: xmalloc (xmalloc.c:49)
> > ==9357==by 0x804984C: swallow_file_in_memory (ptx.c:547)
> > ==9357==by 0x804C994: main (ptx.c:2203)
> 
> Thanks for finding and reporting that!
> Looking into it, I found two shallow bugs (patched below)
> and added some basic tests.
> With this patch, the problem you found is still reproducible,
> but requires a slightly different invocation:
> 
>   echo -n a>A && valgrind ptx A A
> 
> The trouble is that global state is reused
> when processing the second and subsequent
> file argument.  Fixing that will require a more
> invasive change, and I'm not convinced it's even
> worth my time.  Does anyone even use ptx these day?
> Does anyone rely on the GNU extension of accepting more
> than one input file?  Since it appears that feature has never
> worked properly, I seriously doubt it.  So I'm considering
> whether to add ptx to the list of programs that are not
> installed by default.
> 
> Jim
> 
> From 773be9eca85da9a9a33d42d29ecfd04c9aec5c3f Mon Sep 17 00:00:00 2001
> From: Jim Meyering <[EMAIL PROTECTED]>
> Date: Tue, 15 Jul 2008 08:30:38 +0200
> Subject: [PATCH] fix two bugs in ptx
> 
> * src/ptx.c (fix_output_parameters): Don't let before_max_width
> go negative -- that would cause an infloop in define_all_fields.
> (main): Don't clobber name[0] with lists of two or more input files.
> * tests/misc/ptx: New file.  Test for the above.
> * tests/Makefile.am (TESTS): Add misc/ptx.
> ---
>  src/ptx.c |7 ---
>  tests/Makefile.am |1 +
>  tests/misc/ptx|   44 
>  3 files changed, 49 insertions(+), 3 deletions(-)
>  create mode 100755 tests/misc/ptx
> 
> diff --git a/src/ptx.c b/src/ptx.c
> index 827d22e..c04c90c 100644
> --- a/src/ptx.c
> +++ b/src/ptx.c
> @@ -1353,6 +1353,8 @@ fix_output_parameters (void)
>right side, or one on either side.  */
> 
>before_max_width -= 2 * truncation_string_length;
> +  if (before_max_width < 0)
> + before_max_width = 0;
>keyafter_max_width -= 2 * truncation_string_length;
>  }
>else
> @@ -2112,11 +2114,10 @@ main (int argc, char **argv)
> 
>for (file_index = 0; file_index < number_input_files; file_index++)
>   {
> -   input_file_name[file_index] = argv[optind];
> if (!*argv[optind] || STREQ (argv[optind], "-"))
> - input_file_name[0] = NULL;
> + input_file_name[file_index] = NULL;
> else
> - input_file_name[0] = argv[optind];
> + input_file_name[file_index] = argv[optind];
> optind++;
>   }
>  }
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index f7275f8..c2da630 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -120,6 +120,7 @@ TESTS =   \
>chgrp/no-x \
>chgrp/posix-H  \
>chgrp/recurse  \
> +  misc/ptx   \
>misc/test  \
>misc/seq   \
>misc/head  \
> diff --git a/tests/misc/ptx b/tests/misc/ptx
> new file mode 100755
> index 000..cfc1544
> --- /dev/null
> +++ b/tests/misc/ptx
> @@ -0,0 +1,44 @@
> +#!/usr/bin/perl
> +
> +# Copyright (C) 2008 Free Software Foundation, Inc.
> +

Re: making GNU ls -i (--inode) work around the linux readdir bug

2008-07-16 Thread Phillip Susi


Micah Cowan wrote:

He means that there _is_ no optimization. When you're applying ls -i
directly to files ("ls -i non-directory", the scenario he mentioned as
not being affected), there is no readdir, there are no directory
entries, and so there is no optimization to be made. A call to stat is
required. There is no effect to reduce.

I may be completely off-base here, but that's how I read it, at least
(how do you get inode info from dir entries you don't have?!).




Of course... I wasn't keying in on the non-directory argument for some 
reason I was taking that as indicating that you were still doing an 
ls -i in a directory that *contained* non directory children.




___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

[PATCH] * HACKING: describe how to find a misplaced change-set

if you use ptx, please let us know [Re: ptx bug (invalid read)

Re: if you use ptx, please let us know [Re: ptx bug (invalid read)

Re: [bug #23798] Proposal to add some new free & open file formats to src/dircolors.hin

[bug #23798] Proposal to add some new free & open file formats to src/dircolors.hin

Re: du: cache directory size

sha1sum

Re: sha1sum

filesizes/diskusage with ls, du, df only on xen-images

filesizes/diskusage with ls, du, df only on xen-images (fwd)

Re: if you use ptx, please let us know [Re: ptx bug (invalid read)

Re: making GNU ls -i (--inode) work around the linux readdir bug

12 matches

Site Navigation

Mail list logo

Footer information