On Sat, 23 Feb 2008, Theodoros V. Kalamatianos wrote:
as the subject says, the tests/misc/pwd-long test fails with a 'Permission
denied' error when / is not readable by the user that runs the test.
Same goes for tests/du/slash, which tries to read / directly.
Regards,
Theodoros
/ is unreadable.
* tests/du/slash: Likewise.
This is required at least for Mandrake/Mandriva in secure mode.
Reported by Theodoros V. Kalamatianos in
http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/12800
After a minor modification to apply to coreutils-6.10, I
...as the subject says, this test fails when run as root because root is
not restricted by file permissions. AFAICT coreutils-6.5 introduced this
and coreutils-6.6 is still affected. The following patch fixes the test:
diff -uNr coreutils-6.5/tests/du/inacc-dest
Hi,
I just downloaded coreutils-6.3 and the testsuite fails in chown/basic:
# make TESTS=basic VERBOSE=yes check
+ chgrp --version
+ . ./../envvar-check
++ as_unset=unset
++ envvar_check_failed=0
++ vars='
_POSIX2_VERSION
BLOCKSIZE
BLOCK_SIZE
CDPATH
COLUMNS
DF_BLOCK_SIZE
On Tue, 3 Oct 2006, Jim Meyering wrote:
Theodoros V. Kalamatianos [EMAIL PROTECTED] wrote:
I just downloaded coreutils-6.3 and the testsuite fails in chown/basic:
...
make[1]: Leaving directory `/usr/src/RPM/BUILD/coreutils-6.3/tests/chown'
...
++ ls -n slink
+ set _ lrwxrwxrwx 1 0 0 1
On Fri, 30 Dec 2005, Bob Proulx wrote:
On what systems is env located in /bin/env? The normal location is in
/usr/bin/env. I checked HP-UX, AIX, Solaris, FreeBSD, and various
GNU/Linux systems. All had /usr/bin/env. This is counted upon by many
scripts using /usr/bin/env as a launcher. I
On Sat, 31 Dec 2005, The Wanderer wrote:
Entering 'info mv' brings up an info interface to the exact same page,
including the same suggestion at the bottom. This is probably more a
Debian issue than a coreutils one, though.
I think it has to do with whether the directory file (dir) in
On Thu, 17 Nov 2005, Jim Meyering wrote:
When you use ls's -L option, that makes it use stat(2) rather
than lstat(2). To give the better diagnostic, ls would have
to treat ENOENT specially when invoked with -L: it would perform
an additional lstat on the offending file, and if that succeeds,
On Mon, 31 Oct 2005, Paul Eggert wrote:
It should still lseek and ftruncate, if stdout is a regular file, a
directory (!), or a shared memory object.
Otherwise I guess it has to write null bytes, yes.
What about special files ? lseek is valid on e.g. /dev/hda and people
would not expect dd
On Tue, 1 Nov 2005, Paul Eggert wrote:
Theodoros V. Kalamatianos [EMAIL PROTECTED] writes:
lseek is valid on e.g. /dev/hda and people
would not expect dd to null their data till it reached the desired
offset.
True. I guess the algorithm should be to use lseek if possible, and
to write
On Mon, 31 Oct 2005, Theodoros V. Kalamatianos wrote:
It seems that it just reads and drops one more record than it should.
I have verified with `wc' that the characters are indeed dropped end not e.g.
replaced with a null. I'll see if I can trace this bug, but it may take some
time.
Ok
On Sun, 30 Oct 2005, Paul Eggert wrote:
Solaris dd already uses oseek= for something else, so different option
names should be chosen. Perhaps ibskip= and obseek= for skipping
before each block (in effect, punning on ibs and iseek and obs and
oseek), and ibskiptail= and obseektail= for
Hello,
While trying to implement the per-block seek/skip options I suggested I
encountered an inconsistency between the handling of regular files and
stdout in the following case:
dd if=/dev/zero count=0 seek=1
To reproduce the inconsistency:
# rm -f test; dd if=/dev/zero count=0 seek=1
On Mon, 31 Oct 2005, Theodoros V. Kalamatianos wrote:
I was thinking to have the following:
bseek=BYTES skip BYTES bytes at start of output\n\
bskip=BYTES skip BYTES bytes at start of input\n\
obseek=M[,N]skip M bytes at start of each output block and N bytes after
ibskip=M[,N
On Mon, 31 Oct 2005, Theodoros V. Kalamatianos wrote:
I think that the proper behaviour would be to ftruncate() the output file
only when it is larger than the requested seek size.
Hmm, I seem to have forgotten that what _I_ think doesn't really matter
that much :-). So I just checked
On Mon, 31 Oct 2005, Paul Eggert wrote:
Before proceeding too far in this matter can you please check the
compatibility of your solution with the proposed action in XCU ERN 64?
Please see http://www.opengroup.org/austin/aardvark/latest/xcubug2.txt
and look for 'Enhancement Request Number 64'.
On Sun, 30 Oct 2005, Paul Eggert wrote:
Theodoros V. Kalamatianos [EMAIL PROTECTED] writes:
I have built coreutils-5.92 on my system (Linux-2.6.11.6/i686,
glibc-2.3.3CVS) and was testing the build when I came up with a failed
test for tests/cp/fail-perm. The testsuite is run as root.
...
open
On Sun, 30 Oct 2005, Paul Eggert wrote:
Theodoros V. Kalamatianos [EMAIL PROTECTED] writes:
It seems that my distribution (Mandrake 10.1) in the high security
mode restricts access to /proc,
Hmmm, I just realised that my system was originally a Mandrake 10.0, but I
have tweaked/modified
On Sun, 30 Oct 2005, Theodoros V. Kalamatianos wrote:
And after all of this is finished I end up with the tests/tail-2/big-4gb
skipped because the new dd is unable to handle large files. After a strace on
my current and the new dd I discovered the following difference:
dd 5.2.1:
.
.
.
open
Quite often I find myself with the task of extracting data from files such
as CD images. These files encapsulate the needed data bloks in larger
blocks with a header and possibly some tailing data. E.g. a typical
.bin/.cue CD image has each 2048 usable data sector encapsulated in a 2352
byte
On Sun, 30 Oct 2005, Paul Eggert wrote:
I'm pretty sure that Mandrake's policy of not letting programs look at
/proc/self will break a lot of other software in possibly-subtle ways,
so could you please report it as a bug? I don't see any reason why a
process shouldn't be able to look at
While trying to implement the per-block seek/skip options I suggested I
stumbled on yet another bug in coreutils-5.92. This time it affects dd and
I believe it is major enough to consider coreutils-5.92 unusable and pull
that release back. Initially I thought that the dd skip= option drops
2 *
22 matches
Mail list logo
