Re: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem

On Wed, May 20, 2009 at 1:33 AM, Matthew Woehlke mw_tr...@users.sourceforge.net wrote: Chris Weston wrote: I'm trying debug an issue with my one of my disks in my system. I have an ext3 file system mounted and ls -l is reporting an impossible size for two of the files:

Re: tail +n does not work under Linux?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christophe LYON on 5/12/2009 2:19 AM: On 11.05.2009 20:28, Bob Proulx wrote: It is only because 'n' and 'N' are different cases of the same letter that people's minds play tricks on them. Indeed. Maybe a slight rewording of the man

bomb out quicker if cannot set date

$ date -s date: cannot set date: Operation not permitted Wed May 20 11:11:00 CST 2009 OK, then please don't print out that date afterward. Just bomb out. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org

Re: tail +n does not work under Linux?

Eric Blake wrote: ... ... ), stdout); printf (_(\ - -n, --lines=Noutput the last N lines, instead of the last %d;\n\ - or use +N to output lines starting with the Nth\n\ + -n, --lines=CNT output the last CNT lines, instead of the last

Re: tail +n does not work under Linux?

Eric Blake wrote: What do you think about the attached patch to the --help output (and thus man page)? Yes there are too many Ns. - -n, --lines=Noutput the last N lines, instead of the last %d;\n\ - or use +N to output lines starting with the Nth\n\

Re: tail +n does not work under Linux?

Pádraig Brady P at draigBrady.com writes: - -n, --lines=Noutput the last N lines, instead of the last % d;\n\ - or use +N to output lines starting with the Nth\n\ + -n, --lines=CNT output the last CNT lines, instead of the last % d;\n\ +

Re: [PATCH] chroot specify user/group feature

Giuseppe Scrivano wrote: this is an updated version for the previous patch. I added documentation and new tests. Since I don't use short-named options, there are not conflicts with -u, -g and -G used by different chroot implementations. In my first version -g has a different meaning than

Re: [PATCH] chroot specify user/group feature

Jim Meyering j...@meyering.net writes: diff --git a/tests/chroot/credentials b/tests/chroot/credentials index f3e7a32..fd87a86 100644 --- a/tests/chroot/credentials +++ b/tests/chroot/credentials @@ -29,13 +29,15 @@ require_root_ fail=0 # Verify that root credentials are kept. -test

Re: [PATCH] chroot specify user/group feature

Giuseppe Scrivano wrote: diff --git a/src/chroot.c b/src/chroot.c + +#ifndef GID_T_MAX +# define GID_T_MAX TYPE_MAXIMUM (gid_t) +#endif The above is redundant and already done in system.h + +#ifndef MAXGID +# define MAXGID GID_T_MAX +#endif Why add the new MAXGID name? + if

Re: [PATCH] chroot specify user/group feature

Andreas Schwab wrote: Jim Meyering j...@meyering.net writes: diff --git a/tests/chroot/credentials b/tests/chroot/credentials index f3e7a32..fd87a86 100644 --- a/tests/chroot/credentials +++ b/tests/chroot/credentials @@ -29,13 +29,15 @@ require_root_ fail=0 # Verify that root

Re: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem

Chris Weston wwes...@redback.com writes: Yes, the platform is MIPS with a 64-bit Kernel and 32-bit userland. Looks like your ls is an n32 binary, but your strace can only decode o32 traces. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3

Re: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem

James Youngman wrote: On Wed, May 20, 2009 at 1:33 AM, Matthew Woehlke mw_tr...@elided wrote: Please do not quote my e-mail address unobfuscated in message bodies. Chris Weston wrote: I'm trying debug an issue with my one of my disks in my system. I have an ext3 file system mounted and ls

RE: ls reports incorrect file size compared to what debugfs reports for ext3 filesystem

On Wed, May 20, 2009 at 1:37 AM James Youngman j...@gnu.org wrote: On Wed, May 20, 2009 at 1:33 AM, Matthew Woehlke mw_tr...@users.sourceforge.net wrote: Chris Weston wrote: I'm trying debug an issue with my one of my disks in my system. I have an ext3 file system mounted and ls -l is

Re: tail +n does not work under Linux?

Maybe a slight rewording of the man page could highlight this? (eg add another reference to the info page for this trick) What do you think about the attached patch to the --help output (and thus man page)? Thanks for taking my comment into account! It is indeed clearer with your proposal,

cp --help: -L doubled

When I view cp --help part of it looks like this(its german): -L, --dereference symbolischen Verknüpfungen in QUELLE immer folgen -n, --no-clobberkeine existierenden Dateien überschreiben (überstimmt eine vorangehende Option -n) -L,

Re: tail +n does not work under Linux?

Eric Blake wrote: COUNT runs into length problems - adding 4 characters per instance builds up fast. I'll try with NUM instead. As it is, I already had to rephrase things since nth is a word, but count'th and num'th are not. s/N/K/ ? :-) Is K'th item too awkward? (Or some other letter that

Re: [PATCH] chroot specify user/group feature

Pádraig Brady p...@draigbrady.com writes: +#ifndef MAXGID +# define MAXGID GID_T_MAX +#endif Why add the new MAXGID name? I took this code from the gnulib userspec.c file. I guess there are cases when MAXGID is defined and GID_T_MAX is not, and in such case it is better to use the real

Re: cp --help: -L doubled

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [adding the German translation team in cc] According to pe...@gmx.at on 5/20/2009 11:05 AM: When I view cp --help part of it looks like this(its german): -L, --dereference symbolischen Verknüpfungen in QUELLE immer folgen -n,