bug-coreutils is back on-line (I hope)

[Jim Meyering]

I've just heard from Justin Baugh that bug-coreutils
may be back in business.  It's been broken (a result of a hardware
failure -- fixed quickly -- that caused a corrupted database (took
longer)) since about March 6.


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

Re: dd new iflag= oflag= flags directory, nolinks

[Phillip Susi]

What is atomic about having dd do this?  open() with O_DIRECTORY to test 
for existence of a directory is exactly what test does isn't it?  If 
your goal is to test for the existence of a directory then test is what 
you want to use, not dd.  The purpose of dd is to copy/convert data 
between devices, not test if files or directories exist, so I don't 
think this patch is very appropriate. 


Paul Eggert wrote:

You can open a directory without writing to it.  Something like this:

   $ mkdir foo
   $ dd if=foo iflag=directory count=0
   0+0 records in
   0+0 records out
   0 bytes (0 B) copied, 2e-05 seconds, 0 B/s

You can think of this as a way to do a "test -d foo && test -r foo"
atomically, without race conditions.  Admittedly this is somewhat
twisted, but the new documentation does say that iflag=directory is of
"limited utility"

  


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

Re: Bug#354875: /bin/cp directory full vs. disk full messages

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Dan Jacobson on 2/28/2006 10:44 PM:
> Version: 5.93-5

The latest stable version is 5.94 - consider upgrading.

> 
> Separate "directory full" from "disk full" when giving messages to the
> user, else he might never guess the solution.

This would require support from the kernel - coreutils is just faithfully
printing the error string associated with ENOSPC, which is unfortunately
the same error returned by the kernel whether the directory or the disk is
full.

> 
> Maybe historically for UNIX this would never happen, so the messages
> were never improved.

Correct - FAT is one of the few filesystems where the root directory is
inherently limited in the number of files it can contain; normal Unix
filesystems can use as many inodes in any directory as the device
contains.  In other words, a directory is normally never full unless the
disk has no spare inodes anywhere, whereas in your case, you could still
create files in an existing subdirectory, just not in the root directory.

Also, be aware that even on traditional Unix filesystems it is possible to
consume all of a device's inodes while still having spare space (existing
files can grow, but no new files created), or to consume all the non-inode
space while still having spare inodes (existing files can't grow beyond
their current block size, but it may be possible to create empty files).
In other words, a "no space left" error message is about as accurate as
you can get.

In my mind, it is unfortunate that FAT was chosen as the filesystem of
choice for flash drives, since FAT cannot preserve file permissions.

- --
Life is short - so eat dessert first!

Eric Blake [EMAIL PROTECTED]

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEDYT584KuGfSFAYARArOBAKDUQGOm5GGtuxy2eVhapmeowehqLgCgvBp/
NY3PVGXoWL9LrMHFe0VOwEc=
=6zOc
-END PGP SIGNATURE-


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

Re: dd new iflag= oflag= flags directory, nolinks

[Paul Eggert]

Phillip Susi <[EMAIL PROTECTED]> writes:

> What is atomic about having dd do this?  open() with O_DIRECTORY to test for
> existence of a directory is exactly what test does isn't it?

No, because "test -d foo && test -r foo" is _two_ invocations of
"test", not one.  A race condition is therefore possible.  The race
condition is not possible with dd if=foo iflag=directory count=0.

Admittedly this usage is unusual.  The main arguments for it are
(1) "dd" supports all the other O_* flags, so why not O_DIRECTORY? and
(2) I ran into a situation where I could use O_DIRECTORY.
(1) is far more important than (2).


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

document that echo can't be given a NULL

[Dan Jacobson]

No way to hand echo or /bin/echo a NULL.
$ set a $'\x00' b
$ echo $#
3
$ echo A$'\x01'B|wc -c
4
$ echo A$'\x00'B|wc -c
3
$ echo -n `echo -ne 000`|wc -c
0
BASH_VERSION='3.1.0(1)-release'

At least the echo docs should say so.


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

Re: dd new iflag= oflag= flags directory, nolinks

[Phillip Susi]

Paul Eggert wrote:

No, because "test -d foo && test -r foo" is _two_ invocations of
"test", not one.  A race condition is therefore possible.  The race
condition is not possible with dd if=foo iflag=directory count=0.

  


Ok, so this allows you to atomically test if the named object is both a 
directory and is readable, but why bother?  It's a bit silly to worry 
about a race between the two tests when you still have a race between 
the dd-test and whatever it is the script actually does with the 
directory, such as try to list the files in it.  Practically, 
eliminating the one pedantic race condition doesn't solve any problems 
because you've still got a dozen others. 




Admittedly this usage is unusual.  The main arguments for it are
(1) "dd" supports all the other O_* flags, so why not O_DIRECTORY? and
(2) I ran into a situation where I could use O_DIRECTORY.
(1) is far more important than (2).


The purpose of dd is to transfer data.  Since O_DIRECTORY excludes 
transfering data, its use goes against the grain of dd, and since it 
doesn't actually accomplish anything useful either, I don't think it 
should be done.  It just adds complexity for no good reason.



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

tests/dd/misc patch for typo in noatime test

[Paul Eggert]

I installed this patch which I caught by code inspection (I don't have
easy access to a kernel with the noatime feature):

2006-03-08  Paul Eggert  <[EMAIL PROTECTED]>

* tests/dd/misc: iflags->iflag.  This fixes a typo that meant the
noatime test never tested anything.

--- tests/dd/misc   9 Dec 2005 21:52:50 -   1.4
+++ tests/dd/misc   8 Mar 2006 18:11:55 -
@@ -1,6 +1,6 @@
 #!/bin/sh
 # Ensure dd treats `--' properly.
-# Also ensure that iflags=noatime works.
+# Also ensure that iflag=noatime works.
 
 tmp_in=dd-in.$$
 tmp_out=dd-out.$$
@@ -26,10 +26,10 @@ cmp $tmp_in $tmp_out || fail=1
 
 old_ls=`ls -u --full-time $tmp_in`
 sleep 1
-if dd iflags=noatime if=$tmp_in of=$tmp_out > /dev/null 2>&1; then
+if dd iflag=noatime if=$tmp_in of=$tmp_out > /dev/null 2>&1; then
   new_ls=`ls -u --full-time $tmp_in`
   if test "x$old_ls" != "x$new_ls"; then
-echo "dd iflags=noatime updated atime; O_NOATIME bug in your kernel?" >&2
+echo "dd iflag=noatime updated atime; O_NOATIME bug in your kernel?" >&2
 fail=1
   fi
 fi


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

ptx --copyright

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Is it time to retire 'ptx --copyright' in favor of the standard
- --version/--help used by all the other coreutils?  If so, I can prepare a
patch that removes this redundant option, and touches up NEWS and
coreutils.texi accordingly.

- --
Life is short - so eat dessert first!

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

iD8DBQFEEYM984KuGfSFAYARAseSAJ9lFDlBDvfE6qMfuT+WXtAbAdt8CQCcDIk4
irKkhUMCIM4VkDbUGKNssi4=
=FrCB
-END PGP SIGNATURE-


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

Re: root-dev-ino.c limitation

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to Jim Meyering on 3/3/2006 9:53 AM:
>
> Why do you want to merge this change with the
> already-big basename/dirname one?
>

OK, I'll send the root-dev-ino patch separately from the basename/dirname one.

> Thanks, this does look good.
> Would you please keep the bug-fix separate, and include
> a test for it, if possible?

The bug is present only when xgetcwd fails to determine that you are in /;
then robust_getcwd kicks in, determines that you are already at the root,
and was prepending "/" to "/" resulting in "//".  The fix is to prepend
"/" to "", but I don't see how it is possible to write a test without the
use of a debugger (since if xgetcwd fails to determine you are in /, your
system has major problems).

2006-03-11  Eric Blake  <[EMAIL PROTECTED]>

* src/pwd.c (robust_getcwd): Prepend only one slash, not two.

- --
Life is short - so eat dessert first!

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

iD8DBQFEEutA84KuGfSFAYARAjCQAKDVOPdxVpdDoK/ahoKT952lOIH5BwCfQiSg
G5SPHu0D1EF2vrBmbv4GaOc=
=yT2g
-END PGP SIGNATURE-
Index: src/pwd.c
===
RCS file: /sources/coreutils/coreutils/src/pwd.c,v
retrieving revision 1.59
diff -u -p -r1.59 pwd.c
--- src/pwd.c   26 Feb 2006 10:02:49 -  1.59
+++ src/pwd.c   11 Mar 2006 15:19:04 -
@@ -279,8 +279,9 @@ robust_getcwd (struct file_name *file_na
   find_dir_entry (&dot_sb, file_name, height++);
 }
 
+  /* See if a leading slash is needed; file_name_prepend adds one.  */
   if (file_name->start[0] == '\0')
-file_name_prepend (file_name, "/", 1);
+file_name_prepend (file_name, "", 0);
 }
 
 int
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: Remove Utility- need guidance

[Jim Meyering]

vineet chadha <[EMAIL PROTECTED]> wrote:
> I a grad at Univ of Florida and working to develop an application
> (copy-on-write) for my research. When working on it, I found remove
> utility "circular directory test" little intriguing. Here is the reason:
>
> Modern operating system put the in-core inode into free list and
> sometimes re-allocates inode immediately to NEXT creation of file system
> object. remove UTILITY heavily works on assumption that
> directory-to-be-deleted is of single thread and not being modified by
> other user or prcoess. Sepcifically, I will give you as example of my
> copy-on-write implementation. i have been trying to replicate  a directory
> hierarchy from main server to a dummy server called as shadow server
> dynamically. Now if I issue "rm -rf", due to certain restrictions my
> implementation starts replicating file ( untill it is already done so) in
> shadow server and subsequetnly delete it and update state of corresponding
> dir in a hash table. Point is that during is process of remove, directory
> is also being changed (as being replicated). Since, OS is allocating
> inodes, almost most of time, remove fails on circular directory structure
> as OS has reallocated the inode to newly replicated file object in same
> diretory hierachy. So, probabiity of matching inode in state buffer
> (stored as power of two) is almost certain.
>
> I confirmed this phenomenon ( though not conistently ) through running two
> scripts (one creating 1 dir hierachy and other deleting it. I tried
> nearly 10 times and it failed 2 times (even though it is completely
> different dir) .
> I am thinking to work on a patch for the same. Please comment on issue.

Thank you very much for tracking that down and reporting it!
I reproduced the problem like this:

(mkdir x && cd x && perl -e 'while (1) { mkdir int rand  }') &
pid=$!
sleep 3; rm -rf x
kill $pid

Here's the output I got, using ReiserFS3[*] on linux-2.6.15 with
the latest version of GNU rm:

rm: WARNING: Circular directory structure.
This almost certainly means that you have a corrupted file system.
NOTIFY YOUR SYSTEM MANAGER.
The following directory is part of the cycle:
  `x'

[Exit 1]

[*] I tried a few times using ext3, xfs, and tmpfs, but the above
did not trigger the failure.  Different inode-reuse policy, I suppose.


Here's a fix for the CVS trunk (it'll also go onto the b5 branch,
from which coreutils-5.95 will come).

2006-03-10  Jim Meyering  <[EMAIL PROTECTED]>

* src/remove.c (AD_pop_and_chdir): Fix a bug whereby a user with
write access to a directory being removed could cause the removal
of that directory to fail with an erroneous diagnostic about a
directory cycle.  Reported by Vineet Chadha.

Index: remove.c
===
RCS file: /fetish/cu/src/remove.c,v
retrieving revision 1.146
diff -u -p -r1.146 remove.c
--- remove.c12 Feb 2006 07:55:38 -  1.146
+++ remove.c10 Mar 2006 21:21:22 -
@@ -391,7 +391,9 @@ ds_free (Dirstack_state *ds)
 static void
 AD_pop_and_chdir (DIR **dirp, Dirstack_state *ds, char **prev_dir)
 {
-  enum RM_status old_status = AD_stack_top(ds)->status;
+  struct AD_ent *leaf_dir_ent = AD_stack_top(ds);
+  struct dev_ino leaf_dev_ino = leaf_dir_ent->dev_ino;
+  enum RM_status old_status = leaf_dir_ent->status;
   struct AD_ent *top;
 
   /* Get the name of the current (but soon to be `previous') directory
@@ -402,6 +404,16 @@ AD_pop_and_chdir (DIR **dirp, Dirstack_s
   pop_dir (ds);
   top = AD_stack_top (ds);
 
+  /* If the directory we're about to leave (and try to rmdir)
+ is the one whose dev_ino is being used to detect a cycle,
+ reset cycle_check_state.dev_ino to that of the parent.
+ Otherwise, once that directory is removed, its dev_ino
+ could be reused in the creation (by some other process)
+ of a directory that this rm process would encounter,
+ which would result in a false-positive cycle indication.  */
+  if (SAME_INODE (ds->cycle_check_state.dev_ino, leaf_dev_ino))
+ds->cycle_check_state.dev_ino = top->dev_ino;
+
   /* Propagate any failure to parent.  */
   UPDATE_STATUS (top->status, old_status);
 


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

Re: document that echo can't be given a NULL

[Paul Jarc]

Dan Jacobson <[EMAIL PROTECTED]> wrote:
> No way to hand echo or /bin/echo a NULL.

For /bin/echo, that's because execve() uses null-terminated strings.
For bash's builtin echo, it could be done, but then it would be
inconsistent with external commands, which might be surprising.


paul


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

How to fix an existing translation

[Ismail Donmez]

Hi all,

I am with the Pardus Linux team [1] , which is a sponsored project by the 
Turkish government via TUBITAK [2]. We found a problem in coreutils Turkish 
translation and I wonder whats the correct way to send it? Should I send a 
patch here or something else?

Regards,
ismail

[1] http://www.pardus.org.tr/eng/index.html
[2] http://www.tubitak.gov.tr/english/index.htm
-- 
An eye for eye will make the whole world blind -- Gandhi


pgpCJLEwSpjSL.pgp
Description: PGP signature
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils

Re: document that echo can't be given a NULL

[Eric Blake]

> No way to hand echo or /bin/echo a NULL.

You mean NUL, not NULL.  And printf can do it.

> $ set a $'\x00' b
> $ echo $#
> 3
> $ echo A$'\x01'B|wc -c
> 4
> $ echo A$'\x00'B|wc -c
> 3

Here, command substitutions strip all NULs from the command's
output.  POSIX doesn't specify whether this behavior is allowed
or not, but I think it makes more sense for command substitution
to strip NULs than to risk the inconsistency of arguments being
chopped short as they are passed through exec() calls.

-- 
Eric Blake


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

FYI: cycle-check bug: the next step

[Jim Meyering]

There was a weakness in the cycle-check module, described here:

  http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/6600

I've just fixed fts.c (via the changes to fts-cycle.c, see below)
so that it too avoids the problem.

At the same time, I've factored the simple definition of SAME_INODE
into its own file.  It's just a 3-line definition, but those three
lines appeared in so many places that I felt I had to do it, even
if it meant modifying a handful of .m4 files each to `require' the
new .h file.

lib/ChangeLog
2006-03-12  Jim Meyering  <[EMAIL PROTECTED]>

* fts-cycle.c (leave_dir): If cycle-check's saved dev-ino pair matches
that of the current directory (which we're about to chdir ".." out of),
then save the dev-ino of the parent, instead.

* same-inode.h (SAME_INODE): New file/macro.
* chdir-safer.c (SAME_INODE): Remove definition.
Include "same-inode.h", instead.
* same.c: Likewise.
* cycle-check.h: Include "same-inode.h".
(CYCLE_CHECK_REFLECT_CHDIR_UP): Define.
* cycle-check.c (SAME_INODE): Remove definition.
* root-dev-ino.h: Include "same-inode.h".

ChangeLog
2006-03-12  Jim Meyering  <[EMAIL PROTECTED]>

* src/remove.c (AD_pop_and_chdir): Use new macro,
CYCLE_CHECK_REFLECT_CHDIR_UP, rather than open-coding it.

* src/system.h (SAME_INODE): Remove definition.
Include "same-inode.h", instead.

m4/ChangeLog
2006-03-12  Jim Meyering  <[EMAIL PROTECTED]>

* chdir-safer.m4 (gl_CHDIR_SAFER): Add same-inode.h to the list.
* cycle-check.m4 (gl_CYCLE_CHECK): Likewise.
* same.m4 (gl_SAME): Likewise.
* root-dev-ino.m4 (gl_ROOT_DEV_INO): Likewise.

Here are selected diffs:

Index: lib/cycle-check.h
===
RCS file: /fetish/cu/lib/cycle-check.h,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -p -u -r1.6 -r1.7
--- lib/cycle-check.h   14 May 2005 07:58:06 -  1.6
+++ lib/cycle-check.h   12 Mar 2006 22:01:29 -  1.7
@@ -1,6 +1,6 @@
 /* help detect directory cycles efficiently
 
-   Copyright (C) 2003, 2004 Free Software Foundation, Inc.
+   Copyright (C) 2003, 2004, 2006 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
@@ -30,6 +30,7 @@
 # endif
 # include 
 # include "dev-ino.h"
+# include "same-inode.h"
 
 struct cycle_check_state
 {
@@ -41,4 +42,15 @@ struct cycle_check_state
 void cycle_check_init (struct cycle_check_state *state);
 bool cycle_check (struct cycle_check_state *state, struct stat const *sb);
 
+# define CYCLE_CHECK_REFLECT_CHDIR_UP(State, SB_dir, SB_subdir)\
+  do   \
+{  \
+  if (SAME_INODE ((State)->dev_ino, SB_subdir))\
+   {   \
+ (State)->dev_ino.st_dev = (SB_dir).st_dev;\
+ (State)->dev_ino.st_ino = (SB_dir).st_ino;\
+   }   \
+}  \
+  while (0)
+
 #endif
Index: lib/fts-cycle.c
===
RCS file: /fetish/cu/lib/fts-cycle.c,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -p -u -r1.4 -r1.5
--- lib/fts-cycle.c 27 Sep 2005 08:58:55 -  1.4
+++ lib/fts-cycle.c 12 Mar 2006 22:03:17 -  1.5
@@ -1,6 +1,6 @@
 /* Detect cycles in file tree walks.
 
-   Copyright (C) 2003, 2004, 2005 Free Software Foundation, Inc.
+   Copyright (C) 2003, 2004, 2005, 2006 Free Software Foundation, Inc.
 
Written by Jim Meyering.
 
@@ -129,9 +129,9 @@ enter_dir (FTS *fts, FTSENT *ent)
 static void
 leave_dir (FTS *fts, FTSENT *ent)
 {
+  struct stat const *st = ent->fts_statp;
   if (fts->fts_options & (FTS_TIGHT_CYCLE_CHECK | FTS_LOGICAL))
 {
-  struct stat const *st = ent->fts_statp;
   struct Active_dir obj;
   void *found;
   obj.dev = st->st_dev;
@@ -141,6 +141,13 @@ leave_dir (FTS *fts, FTSENT *ent)
abort ();
   free (found);
 }
+  else
+{
+  FTSENT *parent = ent->fts_parent;
+  if (parent != NULL)
+   CYCLE_CHECK_REFLECT_CHDIR_UP (fts->fts_cycle.state,
+ *(parent->fts_statp), *st);
+}
 }
 
Index: src/remove.c
===
RCS file: /fetish/cu/src/remove.c,v
retrieving revision 1.147
retrieving revision 1.148
diff -u -p -u -r1.147 -r1.148
--- src/remove.c10 Mar 2006 21:47:34 -  1.147
+++ src/remove.c12 Mar 2006 22:21:05 -  1.148
@@ -411,8 +411,8 @@ AD_pop_and_chdir (DIR **dirp, Dirstack_s
  could be reused in the creation (by

rm -r can be tricked into reporting non-existent cycle

[Jim Meyering]

I wrote:
> 2006-03-10  Jim Meyering  <[EMAIL PROTECTED]>
>
>   * src/remove.c (AD_pop_and_chdir): Fix a bug whereby a user with
>   write access to a directory being removed could cause the removal
>   of that directory to fail with an erroneous diagnostic about a
>   directory cycle.  Reported by Vineet Chadha.

For those who haven't seen it yet, here's a copy of the original
report and fix:
  http://meyering.net/2006-03-10-rm-bug.txt

It might appear on Gmane's mirror, soon (the number is just a guess):
(the GNU mailman bug-coreutils archive appears to be about 4 days behind)
  http://article.gmane.org/gmane.comp.gnu.core-utils.bugs/6600

In CVS, the code is here:
  http://cvs.savannah.gnu.org/viewcvs/coreutils/src/remove.c?root=coreutils

This newly-exposed cycle-detection weakness means that the gnulib
cycle-check module needs an extension -- a mechanism that's not quite
as ugly as what I did in remove.c.  Having a single function taking
both parent and child dev/inode pairs sounds rather onerous, but maybe
cleanest.  If it ends up being too much trouble or expense, clients like
the fts-cycle module can rely solely on the existing O(depth)-memory
(rather than O(1)) cycle-detection code.

Bear in mind that while this bug may affect even fts-using programs like
chgrp, chown, chmod (but not du, since it uses FTS_TIGHT_CYCLE_CHECK)
that don't modify the hierarchy structure, it's much harder to provoke
the failure when the coprocess must manage to remove a key directory as
well as create lots of new ones.

Technically, even the canonicalize module's use of cycle_check is
susceptible, when traversing symlinks -- and should probably be fixed --
but the typical window is pretty darn small there.  In this case, even
I have doubts about whether it's worth the cost of a full-blown set
(implemented via hash.c) just to detect this highly unlikely failure mode.


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

test: posting through gmane.comp.gnu.core-utils.bugs

[Jim Meyering]

Testing whether articles posted to Gmane
  
make it back to the bug-coreutils@gnu.org mailing list...



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

[patch #4978] hexadecimal support for dd

[anonymous]

URL:
  

 Summary: hexadecimal support for dd
 Project: GNU Core Utilities
Submitted by: None
Submitted on: Fri 03/17/06 at 13:11
Category: None
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
Originator Email: [EMAIL PROTECTED]
 Open/Closed: Open

___

Details:

This patch adds support for parsing hexadecimal numbers to dd.
So instead of writing:

 dd if=/dev/zero of=test bs=`perl -e 'printf("%d",0xe);'` count=1

you can just write

 dd if=/dev/zero of=test bs=0xe count=1

It's a feature I use everyday and I'd be really glad if you could take it
into the official release of GNU coreutils.



___

Carbon-Copy List:

CC Address  | Comment
+-
stepan --AT-- coresystems --DOT-- de | Originator Email



___

File Attachments:


---
Date: Fri 03/17/06 at 13:11  Name: dd.diff  Size: 667B   By: None
Patch to add hexadecimal support to dd, against coreutils CVS from 2006-03-17


___

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

controlling stdio buffering

[Pádraig Brady]

I was trying today to filter my access.log apache log with some coreutils
and was annoyed by the default buffering applied by glibc.
I was trying to do `tail -f ~/access.log | cut ... | uniq` but I was
only getting output when cut had more than 4K written to stdout.

So how to control this? Well each app could add an extra config
parameter (see grep --line-buffered for example), but this doesn't
seem general, and just requires duplicating both logic and documentation
for each application. What would be ideal IMHO would be to
add the config logic in glibc (which would have to be controlled
with environment variables). There seems to be resitance to that though:
http://sources.redhat.com/ml/bug-glibc/1999-09/msg00041.html

Anyway whether it's implemented in libc or the application (coreutils lib),
I think they should have the same config interface which would
be environment variables with something like the following format:
BUF_X_=Y
Where X = the fd number
and Y = 0 for unbuffered, 1 for line buffered and >1 for a specific
buffer size.

So for my particular problem I could do:

tail -f ~/access.log | BUF_1_=1 cut ... | uniq

Would this be a useful addition to coreutils lib, called from the
appropriate apps?
Or better again, could this possibly be added to glibc?

cheers,
Pádraig.

p.s. $ rpm -q fedora-release gcc glibc
fedora-release-4-2
gcc-4.0.0-8
glibc-2.3.5-10

p. p.s. Note glibc changes the buffering automatically for stdout only like:
if (isatty(fileno(stdout)) setlinebuf(stdout)
Also it always leaves stdin buffered and stdout unbuffered.

p.p.s. setvbuf(stdin, (char*) NULL, _IOFBF, 12345) is not honoured,
which is fair enough as buf==NULL.
However 0 is returned indicating it was honoured?

p.p.p.s. reads on stdin default to 4096 bytes on my system
even though BUFSIZ is defined as 8912 ?


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

Re: Bug#355810: coreutils: pwd fails on bind mount

[Jim Meyering]

Kenshi Muto <[EMAIL PROTECTED]> wrote:
> At Wed, 08 Mar 2006 08:59:55 +0100,
> Jim Meyering wrote:
>> Kenshi Muto <[EMAIL PROTECTED]> wrote:
>> So far, I am unable to reproduce the failure on ia32.
...
>> also, please run the failing command under strace, e.g.
>>
>>   cd /home/kmuto/d-i
>>   strace -o /tmp/log /bin/pwd
>
> $ strace -o /tmp/log /bin/pwd outputs following to stderr:
> umovestr: Input/output error
...
> /bin/pwd: couldn't find directory entry in `../../..' with matching i-node

Thanks.

Your strace log showed that /bin/pwd was not calling getcwd.
Yet when I build coreutils-5.94 myself on leisner.debian.org
and try the same experiment, that binary does call getcwd, and
works just fine,

  leisner$ dchroot unstable /home/meyering/coreutils-5.94/src/pwd
  Executing pwd in chroot: /org/leisner.debian.org/chroot/sid
  /home/meyering
  leisner$ dchroot unstable /bin/pwd
  Executing pwd in chroot: /org/leisner.debian.org/chroot/sid
  pwd: couldn't find directory entry in `../..' with matching i-node
  [Exit 1]

I suspect that the arm binary was built against an older version of
libc -- one that made coreutils use its getcwd.c replacement.
I confirmed the theory by forcing coreutils to use the replacement getcwd:

  gl_cv_func_getcwd_null=no gl_cv_func_getcwd_path_max=no ./configure

Then the resulting binary fails (in leisner's chroot), just as
in the example above.

Debugging that failure, I found the source of the problem: a subtle flaw
in lib/getcwd.c (which is based on glibc's sysdeps/posix/getcwd.c).
See the comments in the patch for details.
(fyi, it looks big, but most of it is due to an indentation change)

Technically, this is grounds for changing m4/getcwd.m4 to detect
the deficiency in glibc's getcwd, but performing the actual test
would be tricky, to say the least, and the replacement would be
of only marginal value, since it'd come into play only in a chroot
when the working directory name is too long for the getcwd syscall
to work.  So I won't bother right now.

I've applied the following only in coreutils, for starters:

2006-03-19  Jim Meyering  <[EMAIL PROTECTED]>

Work even in a chroot where d_ino values for entries in "/"
don't match the stat.st_ino values for the same names.
* getcwd.c (__getcwd): When no d_ino value matches the target inode
number, iterate through all entries again, using lstat instead.
Reported by Kenshi Muto in http://bugs.debian.org/355810.

Index: lib/getcwd.c
===
RCS file: /fetish/cu/lib/getcwd.c,v
retrieving revision 1.19
retrieving revision 1.20
diff -u -p -u -r1.19 -r1.20
--- lib/getcwd.c19 Mar 2006 17:18:32 -  1.19
+++ lib/getcwd.c19 Mar 2006 18:27:51 -  1.20
@@ -211,6 +211,7 @@ __getcwd (char *buf, size_t size)
   int parent_status;
   size_t dirroom;
   size_t namlen;
+  bool use_d_ino = true;
 
   /* Look at the parent directory.  */
 #ifdef AT_FDCWD
@@ -257,6 +258,21 @@ __getcwd (char *buf, size_t size)
 NULL.  */
  __set_errno (0);
  d = __readdir (dirstream);
+
+ /* When we've iterated through all directory entries without finding
+one with a matching d_ino, rewind the stream and consider each
+name again, but this time, using lstat.  This is necessary in a
+chroot on at least one system (glibc-2.3.6 + linux 2.6.12), where
+.., ../.., ../../.., etc. all had the same device number, yet the
+d_ino values for entries in / did not match those obtained
+via lstat.  */
+ if (d == NULL && errno == 0 && use_d_ino)
+   {
+ use_d_ino = false;
+ rewinddir (dirstream);
+ d = __readdir (dirstream);
+   }
+
  if (d == NULL)
{
  if (errno == 0)
@@ -269,58 +285,65 @@ __getcwd (char *buf, size_t size)
  (d->d_name[1] == '\0' ||
   (d->d_name[1] == '.' && d->d_name[2] == '\0')))
continue;
- if (MATCHING_INO (d, thisino) || mount_point)
+
+ if (use_d_ino)
{
- int entry_status;
+ bool match = (MATCHING_INO (d, thisino) || mount_point);
+ if (! match)
+   continue;
+   }
+
+ {
+   int entry_status;
 #ifdef AT_FDCWD
- entry_status = fstatat (fd, d->d_name, &st, AT_SYMLINK_NOFOLLOW);
+   entry_status = fstatat (fd, d->d_name, &st, AT_SYMLINK_NOFOLLOW);
 #else
- /* Compute size needed for this file name, or for the file
-name ".." in the same directory, whichever is larger.
-Room for ".." might be needed the next time through
-the outer loop.  */
- size_t name_alloc = _D_ALLOC_NAMLEN (d);
- size_t filesize = dotlen + MAX (sizeof "..", name_alloc);
-
- if (filesize < dotlen)

Bug: "echo -e "\0NNN" doesn't require leading '0'

[L. Walsh]

An incompatibility in echo has crept into the gnu version
of echo.  In extended processing, the leading "0" is no
longer required to start an octal sequence.  This is not
compatible with other extended echo implementations and
can cause un-anticipated side effects (like echoing "awk"
replacement args "\1" into an awk input script).

Linda




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

Re: gnulib regex problem

[Paul Eggert]

Jim Meyering <[EMAIL PROTECTED]> writes:

> -AC_DEFINE([_REGEX_WIDE_OFFSETS], 1,
> +AC_DEFINE([_REGEX_LARGE_OFFSETS], 1,

Ouch, thanks for the quick fix.

exg mentions that there must be a better way, in case glibc ever buys
back the _REGEX_LARGE_OFFSETS fix.  I'll see if I can do that.


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

Re: gnulib regex problem

[Jim Meyering]

Paul Eggert <[EMAIL PROTECTED]> wrote:
...
> 2006-03-16  Paul Eggert  <[EMAIL PROTECTED]>
>
>   * lib/regex.h (regoff_t) [defined _REGEX_LARGE_OFFSETS]:
>   Typedef to long int, not to off_, as POSIX will likely change
>   in that direction.
>
>   * m4/regex.m4 (gl_REGEX): Don't check for off_t, since the code
>   no longer needs it.  Instead, check that regoff_t is as least
>   as wide as ptrdiff_t.
>
>   Don't define _REGEX_WIDE_OFFSETS unless using the included regex,
>   so that our regex.h stays compatible with the installed regex.
>   This is helpful for installers who configure --without-included-regex.
>   Problem reported by Emanuele Giaquinta.

I needed this additional change.
Applied in both gnulib and coreutils:

2006-03-17  Jim Meyering  <[EMAIL PROTECTED]>

* regex.m4 (gl_REGEX): Fix typo in last change:
s/_REGEX_WIDE_OFFSETS/_REGEX_LARGE_OFFSETS/.

Index: m4/regex.m4
===
RCS file: /fetish/cu/m4/regex.m4,v
retrieving revision 1.43
retrieving revision 1.44
diff -u -p -u -r1.43 -r1.44
--- m4/regex.m4 17 Mar 2006 07:33:06 -  1.43
+++ m4/regex.m4 17 Mar 2006 10:07:28 -  1.44
@@ -1,4 +1,4 @@
-#serial 32
+#serial 33
 
 # Copyright (C) 1996, 1997, 1998, 1999, 2000, 2001, 2003, 2004, 2005,
 # 2006 Free Software Foundation, Inc.
@@ -116,7 +116,7 @@ AC_DEFUN([gl_REGEX],
   esac
 
   if test $ac_use_included_regex = yes; then
-AC_DEFINE([_REGEX_WIDE_OFFSETS], 1,
+AC_DEFINE([_REGEX_LARGE_OFFSETS], 1,
   [Define if you want regoff_t to be at least as wide POSIX requires.])
 AC_DEFINE([re_syntax_options], [rpl_re_syntax_options],
   [Define to rpl_re_syntax_options if the replacement should be used.])


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

FYI, bug-coreutils list/archive woes

[Jim Meyering]

FYI, the web (mailman) database has had problems.
  
People have been working on it.  For details and status, see
  

In the mean time, most of the messages missing from the mailman
archive can be found on the Gmane mirror, here:

  http://news.gmane.org/gmane.comp.gnu.core-utils.bugs


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

Re: How to fix an existing translation

[Jim Meyering]

Ismail Donmez <[EMAIL PROTECTED]> wrote:
> I am with the Pardus Linux team [1] , which is a sponsored project by the
> Turkish government via TUBITAK [2]. We found a problem in coreutils Turkish
> translation and I wonder whats the correct way to send it? Should I send a
> patch here or something else?

Thank you for working on those translations.

Would you please coordinate with the Turkish translation
team at the translation project?

  http://www.iro.umontreal.ca/translation/HTML/

All of coreutils' translations come via the translation project.


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

--preserve (cp is still changing file?)

[The Batterson's]

The preserve function isn't working properly.  rsync copies over the 
existing file even though it's the same file.  Is cp changing something 
even though I have --preserve?  It doesn't seem to be preserving the 
time stamp.  Please see the script below.


# KFI Tech Guy
ls -t ~/iPodderData/downloads/'KFI Tech Guy' | head -2 | xargs -i cp -v 
--preserve ~/iPodderData/downloads/'KFI Tech Guy'/{} 
~/iPodderData/downloads/temp/{}

rm ~/iPodderData/downloads/'KFI Tech Guy'/*
cp -v --preserve ~/iPodderData/downloads/temp/* 
~/iPodderData/downloads/'KFI Tech Guy'/
rsync -a --progress --delete ~/iPodderData/downloads/'KFI Tech Guy'/ 
/media/usbdisk/Podcasts/'KFI Tech Guy'/

rm ~/iPodderData/downloads/temp/*

Thank You,

Miles Batterson
Saline, Michigan


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

Re: df enhancment for removable media

[Kevin R. Bulgrien]

Did anything final every come out of this thread.  I've written a
plug-in script for amaroK that a Suse user is complaining about.
I never heard of a system unmounting a disk automagically behind
the user's back when a mount was explicitly requested.

df is reporting USB media to be have 0 bytes free.  The simple
ls /media/USB_DISK >/dev/null; df /media/USB_DISK example is not
sufficient to get df to report something real.

Does anyone feel like giving some idea how this might best be
handled.  I hate to kludge things by creating a file on the USB
device, and it seems silly to over-access the media just to get
a df to output what I want.  I could do a find, because some
other function in my script does that and df reports properly,
but it seems pretty heavy-handed for a simple space check to
run through a USB drive that might be a few GB in size with
hundreds of files.

Is this something that was "fixed" so that a later version of
Suse might have a df that works?  If so, I might just allow the
user to override the space checking in the event he has an
affected system.

Thanks,

Kevin R. Bulgrien

Juergen Weigert wrote:

> Hi coreutils people!
> 
> On a recent SUSE Linux df became unreliable for e.g. USB-drives.
> This is because hald automatically mounts and unmounts such drives
> as they are accessed.
> 
> Usually I get something like:
> 
> $ df /media/USB_DISK
> Filesystem   1K-blocks  Used Available Use% Mounted on
> /dev/sda10 0 0   -  /media/USB_DISK
> 
> only if the USB_DISK is being accessed, I get the expected output.
> 
> $ ls /media/USB_DISK > /dev/null; df /media/USB_DISK
> Filesystem   1K-blocks  Used Available Use% Mounted on
> /dev/sda1   252522238718 13804  95% /media/USB_DISK
> 
> A simple enhancement for df is to actively access the USB_DISK while
> running statfs(). I've added an opendir() call in the attached patch. This
> can be suppressed with a new commandline option -n.
> 
> Please keep me in CC, I am not subscribed.
> 
> thanks,
> Jw.

Paul Eggert wrote:

> Juergen Weigert <[EMAIL PROTECTED]> writes:
> 
>>> Unless I'm missing something I'd rather not change the default behavor
>>> of df, as that would be a compatibility hassle.  That is, df shouldn't
>>> attempt to mount file systems by default; it should do so only if the
>>> user asks, with a new option.
>>
>> These hald mounts are different. For almost every aspect such a device
>> appears to be mounted. So I figured, df should also pretend the
>> device is mounted.
> 
> But lots of programs other than df invoke statfs.  We shouldn't have
> to change them all.  Instead, it would be much better to fix statfs to
> do the right thing with hald mounts.  statfs should return values that
> are consistent with every other system call: it should not return
> incorrect values simply for the convenience of some low-level hardware
> abstraction layer.
> 
> Please also see the message from Ivan Guyrdiev of Cornell archived at
>  dated
> 2005-07-20 in which he says something similar: the statfs
> implementation needs to get fixed.
> 
> 
>> Looks ugly in df.c, right. But in fsusage.c we'd have to place the
>> new code in multiple implementations. Ugly too.
> 
> It would only need to be placed in sections corresponding to
> implementations that have the bug.  Currently, that's just one
> implementation: GNU/Linux, and only a small subset of these hosts as
> well.  Since the workaround issues more system calls, it would be nice
> to detect the broken implementations at compile-time somehow, or at
> least filter out the obviously non-broken implementations.




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

Re: df enhancment for removable media

[Kevin R. Bulgrien]

Paul Eggert wrote:

> Juergen Weigert <[EMAIL PROTECTED]> writes:
> 
>>> Unless I'm missing something I'd rather not change the default behavor
>>> of df, as that would be a compatibility hassle.  That is, df shouldn't
>>> attempt to mount file systems by default; it should do so only if the
>>> user asks, with a new option.
>>
>> These hald mounts are different. For almost every aspect such a device
>> appears to be mounted. So I figured, df should also pretend the
>> device is mounted.
> 
> But lots of programs other than df invoke statfs.  We shouldn't have
> to change them all.  Instead, it would be much better to fix statfs to
> do the right thing with hald mounts.  statfs should return values that
> are consistent with every other system call: it should not return
> incorrect values simply for the convenience of some low-level hardware
> abstraction layer.
> 
> Please also see the message from Ivan Guyrdiev of Cornell archived at
>  dated
> 2005-07-20 in which he says something similar: the statfs
> implementation needs to get fixed.

Did this ever come to anything.  I have a bash script plug-in for a KDE
application that is hosed on Suse 10 something or another because df
is not reporting the free space on a mounted USB device.

Is there a practical and reliable work-around for a shell script?  Not
sure what questions to ask.  I never heard of df doing this before, 
though now I see it is apparently not df per se.  What is a shell
script to do?

Thanks,

Kevin R. Bulgrien




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

Bug report (as s/w requests).

[Hugh Sasse]

I've tried to subscribe using bug-coreutils-request but I get
no response, so I'm sending this in the hope that it will reach
a useful destination nonetheless.

PASS: not-rewound
-: test block-sync-1: stderr mismatch, comparing block-sync-1.E (actual) and 
block-sync-1.3 (expected)
*** block-sync-1.E  Thu Mar  9 18:50:30 2006
--- block-sync-1.3  Thu Mar  9 18:50:30 2006
***
*** 1,3 
  2+1 records in
  0+1 records out
! 1 truncated records
--- 1,3 
  2+1 records in
  0+1 records out
! 1 truncated record
FAIL: skip-seek
PASS: skip-seek2
3+1 records in
0+1 records out
18 bytes (18 B) copied, 0.000685894 seconds, 26.2 kB/s
PASS: unblock-sync
==
1 of 5 tests failed
Please report to bug-coreutils@gnu.org
==
gmake[3]: *** [check-TESTS] Error 1
gmake[3]: Leaving directory `/export/home/Scratch/hgs/coreutils-5.94/tests/dd'
gmake[2]: *** [check-am] Error 2
gmake[2]: Leaving directory `/export/home/Scratch/hgs/coreutils-5.94/tests/dd'
gmake[1]: *** [check-recursive] Error 1
gmake[1]: Leaving directory `/export/home/Scratch/hgs/coreutils-5.94/tests'
gmake: *** [check-recursive] Error 1


The only difference I can see is that record is singular in one case.
This is on a Sun, Sparc, Solaris 2.9 if that helps

Hugh


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

Re: dd new iflag= oflag= flags directory, nolinks

[Olivier Delhomme]

Le Mon, 06 Mar 2006 18:20:12 -0500, Phillip Susi disait :

> I'm confused.  You can't open() and write() to a directory, so how does 
> it make any sense to ask dd to set O_DIRECTORY?

So do I ...I never used open() with a directory, but why shouldn't it
be possible ?

I looked to the man 2 open page and I saw the following which confuses
me more :

 O_DIRECTORY
  If  pathname  is not a directory, cause the open to
fail.  This flag is Linux-specific, and was added in kernel version
2.1.126, to avoid denial-of- service problems if opendir(3) is called
on a FIFO or tape device, but should not be used outside of the
implementation of opendir.


So if this flag is linux specific does it mean that dd iflag=directory
won't run on other unices ?

Thanks,

Olivier.


> Paul Eggert wrote:
> > I wanted to use dd iflag=directory (to test whether a file is a
> > directory, atomically), and noticed that dd didn't have it.  The use
> > was a fairly obscure one (just testing the O_DIRECTORY flag) but I
> > figured dd should support all the flags.  I noticed also that dd
> > doesn't support the Solaris 10 O_NOLINKS option.  So I installed this:
> >
> > 2006-03-05  Paul Eggert  <[EMAIL PROTECTED]>
> >
> > * doc/coreutils.texi (dd invocation): New flags directory, nolinks.
> > Alphabetize nofollow.
> > * src/dd.c (flags, usage): New flags directory, nolinks.
> > * src/system.h (O_NOLINKS): Define to 0 if not already defined.
> >
> > Index: doc/coreutils.texi
> > ===
> > RCS file: /fetish/cu/doc/coreutils.texi,v
> > retrieving revision 1.315
> > diff -p -u -r1.315 coreutils.texi
> > --- doc/coreutils.texi  27 Feb 2006 10:47:23 -  1.315
> > +++ doc/coreutils.texi  6 Mar 2006 07:15:27 -
> > @@ -7003,7 +7003,8 @@ argument(s).  (No spaces around any comm
> >  Access the output file using the flags specified by the @var{flag}
> >  argument(s).  (No spaces around any comma(s).)
> >  
> > -Flags:
> > +Here are the flags.  Not every flag is supported on every operating
> > +system.
> >  
> >  @table @samp
> >  
> > @@ -7019,6 +7020,13 @@ contents of the file.  This flag makes s
> >  @cindex direct I/O
> >  Use direct I/O for data, avoiding the buffer cache.
> >  
> > [EMAIL PROTECTED] directory
> > [EMAIL PROTECTED] directory
> > [EMAIL PROTECTED] directory I/O
> > +
> > +Fail unless the file is a directory.  Most operating systems do not
> > +allow I/O to a directory, so this flag has limited utility.
> > +
> >  @item dsync
> >  @opindex dsync
> >  @cindex synchronized data reads
> > @@ -7043,11 +7051,6 @@ Use non-blocking I/O.
> >  @cindex access time
> >  Do not update the file's access time.
> >  
> > [EMAIL PROTECTED] nofollow
> > [EMAIL PROTECTED] nofollow
> > [EMAIL PROTECTED] symbolic links, following
> > -Do not follow symbolic links.
> > -
> >  @item noctty
> >  @opindex noctty
> >  @cindex controlling terminal
> > @@ -7056,6 +7059,16 @@ This has no effect when the file is not 
> >  On many hosts (e.g., @acronym{GNU}/Linux hosts), this option has no effect
> >  at all.
> >  
> > [EMAIL PROTECTED] nofollow
> > [EMAIL PROTECTED] nofollow
> > [EMAIL PROTECTED] symbolic links, following
> > +Do not follow symbolic links.
> > +
> > [EMAIL PROTECTED] nolinks
> > [EMAIL PROTECTED] nolinks
> > [EMAIL PROTECTED] hard links
> > +Fail if the file has multiple hard links.
> > +
> >  @item binary
> >  @opindex binary
> >  @cindex binary I/O
> > Index: src/dd.c
> > ===
> > RCS file: /fetish/cu/src/dd.c,v
> > retrieving revision 1.190
> > diff -p -u -r1.190 dd.c
> > --- src/dd.c7 Dec 2005 21:12:12 -   1.190
> > +++ src/dd.c6 Mar 2006 07:15:27 -
> > @@ -263,10 +263,12 @@ static struct symbol_value const flags[]
> >{"append",   O_APPEND},
> >{"binary",   O_BINARY},
> >{"direct",   O_DIRECT},
> > +  {"directory",O_DIRECTORY},
> >{"dsync",O_DSYNC},
> >{"noatime",  O_NOATIME},
> >{"noctty",   O_NOCTTY},
> >{"nofollow", O_NOFOLLOW},
> > +  {"nolinks",  O_NOLINKS},
> >{"nonblock", O_NONBLOCK},
> >{"sync", O_SYNC},
> >{"text", O_TEXT},
> > @@ -460,6 +462,8 @@ Each FLAG symbol may be:\n\
> >  "), stdout);
> >if (O_DIRECT)
> > fputs (_("  directuse direct I/O for data\n"), stdout);
> > +  if (O_DIRECTORY)
> > +   fputs (_("  directory fail unless a directory\n"), stdout);
> >if (O_DSYNC)
> > fputs (_("  dsync use synchronized I/O for data\n"), stdout);
> >if (O_SYNC)
> > @@ -468,11 +472,13 @@ Each FLAG symbol may be:\n\
> > fputs (_("  nonblock  use non-blocking I/O\n"), stdout);
> >if (O_NOATIME)
> > fputs (_("  noatime   do not update access time\n"), stdout);
> > -  if (O_NOFOLLOW)
> > -   fputs (_("  nofollow  do not follow symlinks\n"), stdout);
> >if (O_NOCTTY)
> > fputs (_("  noctty 

Using SORT on Linux

[Oshea, Richard]

Not sure if this is a bug or a problem with the way my environment it setup - 
or the way I'm using sort 
- But...
Given the following data in a file, the sort command does not produce the 
correct output.
I have even tried setting the LC_ALL as suggested in the sort --help  (set 
LC_ALL=C)

AG1
AG2   3
AG2   2
AG3   4
AG4
AG3   3
AG4   5
AG4   6

The results are

AG1
AG2   2
AG2   3
AG3   3
AG3   4
AG4
AG4   5
AG4   6


I would expect the output to be more like ...

AG1
AG4
AG2   2
AG2   3
AG3   3
AG3   4
AG4   5
AG4   6

Any suggestions would be appreciated.


Thanks,

Dick O'Shea
Credit Suisse

==
Please access the attached hyperlink for an important electronic communications 
disclaimer: 

http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
==



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

possible bug in coreutils?

[Scott Griffith]

I am not sure if this is as designed, but the following produce results
that you would not expect:

given the following excerpt from my system log:

Mar 18 19:12:40 newer sshd[19518]: Illegal user blah from 127.0.0.1
Mar 18 19:12:40 newer sshd[19518]: Failed none for illegal user blah
from 127.0.0.1 port 34433 ssh2
Mar 18 19:12:41 newer sshd[19518]: Failed password for illegal user
blah from 127.0.0.1 port 34433 ssh2


using the following produces expected results:

 cat /var/log/messages | grep -i fail | cut -f 9- -d ' '

illegal user blah from 127.0.0.1 port 34433 ssh2
illegal user blah from 127.0.0.1 port 34433 ssh2


using the following produces nothing, yet it should continually yield
the above messages when watching the system log:

  tail -f /var/log/messages | grep -i fail | cut -f 9- -d ' '

however, I am able to use the following command and get output:

  tail -f /var/log/messages | grep -i fail


My main question is...  Is this as designed, or is there really a
problem here.  Also, if this is as designed, how would I go about
getting the same results with tail that I do with cat?

If there is any other information that you require, please do not
hesitate to contact me.

Shell:  bash version 2.05b.0(1)

Sincerely,

Scott W. Griffith
(520)248-9160
[EMAIL PROTECTED]



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


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

Re: df enhancment for removable media

[Kevin R. Bulgrien]

"Juergen Weigert" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED]
> Hi coreutils people!
>
> On a recent SUSE Linux df became unreliable for e.g. USB-drives.
> This is because hald automatically mounts and unmounts such drives
> as they are accessed.
>
> Usually I get something like:
>
> $ df /media/USB_DISK
> Filesystem   1K-blocks  Used Available Use% Mounted on
> /dev/sda10 0 0   -  /media/USB_DISK
>
> only if the USB_DISK is being accessed, I get the expected output.
>
> $ ls /media/USB_DISK > /dev/null; df /media/USB_DISK
> Filesystem   1K-blocks  Used Available Use% Mounted on
> /dev/sda1   252522238718 13804  95% /media/USB_DISK
>
> A simple enhancement for df is to actively access the USB_DISK while running
> statfs(). I've added an opendir() call in the attached patch. This can be
> suppressed with a new commandline option -n.

I have just bumped into this issue for a bash plug-in I wrote for an
application that someone is running on Suse.  I had never heard of df
not showing up output when some filesystem had been mounted.

So now I have to decide how to harden the bash script against this.
I see in this thread that some discussion was had about fixing a
statfs() function instead of df.  Was there resolution to this and
is the user who is having trouble having it because he is on an older
version of df?

The simple example,

  $ ls /media/USB_DISK > /dev/null; df /media/USB_DISK

does not work for my user.  df still reports a size of 0.

One of my functions does work on this system, but it is a series of
find commands.  I don't want to clog the link to the USB device with
things that aren't necessary when I really just need free space.

Does anyone have any ideas on a simple and concise way to might deal
with this in the script.  I realize that it is odd because hald is
someone else's doing, but I'm not sure if there is some reasonably
simple way for me to make sure the media is mounted so df will report
what it needs to report.  I already issued the mount command, so from
the script's (and my) perspective it should be still mounted when df
runs.

Thanks,

Kevin R. Bulgrien
kbulgrien (at) att dot net





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

remove - bug ???

[Vineet Chadha]

** Modern operating system put the in-core inode into
free list and
sometimes re-allocates inode immediately to NEXT creation of file system
object. remove UTILITY heavily works on assumption that
directory-to-be-deleted is of single thread and not being modified by
other user or process. Specifically, I will give you as example of my
copy-on-write implementation. i have been trying to replicate  a directory
hierarchy from main server to a dummy server. Now if I issue "rm -rf",
it starts replicating file ( untill it is already done so) in
shadow server and subsequently delete it and update state of corresponding
dir in a hash table. Point is that during the process of remove, directory
strcuture is also being changed (as being replicated). Since, OS is
allocating
inodes, almost most of time, remove fails on circular directory structure
as OS has reallocated the inode to newly replicated file object in same
directory hierarchy.
I confirmed this phenomenon ( though not conistently ) through running two
scripts (one creating 1 dir hierachy and other deleting it). I tried
nearly 10 times and it failed 2 times (even though it is completely
different dir).
circular directory hierarchy depends on comparison of inode stored in
previous
change dir (stored with power of two)  and  current inode. I  think remove
should
be modified for concurrent user access to directory.

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

Re: df enhancment for removable media

[Phillip Susi]

This sounds like an autofs problem.  I'm running ubuntu and hal auto 
mounts removable media when it is inserted.  When it is not mounted, df 
will not show a line for it at all, since df only shows mounted points. 
 I think what you are seeing is an autofs mount point being mounted 
there which is why df shows a line for the mount point, but autofs has 
decided to unmount the real fs and return bogus stat values.


I'd suggest not using autofs.  In any case, this isn't a bug with df.

Kevin R. Bulgrien wrote:

Did anything final every come out of this thread.  I've written a
plug-in script for amaroK that a Suse user is complaining about.
I never heard of a system unmounting a disk automagically behind
the user's back when a mount was explicitly requested.

df is reporting USB media to be have 0 bytes free.  The simple
ls /media/USB_DISK >/dev/null; df /media/USB_DISK example is not
sufficient to get df to report something real.

Does anyone feel like giving some idea how this might best be
handled.  I hate to kludge things by creating a file on the USB
device, and it seems silly to over-access the media just to get
a df to output what I want.  I could do a find, because some
other function in my script does that and df reports properly,
but it seems pretty heavy-handed for a simple space check to
run through a USB drive that might be a few GB in size with
hundreds of files.

Is this something that was "fixed" so that a later version of
Suse might have a df that works?  If so, I might just allow the
user to override the space checking in the event he has an
affected system.

Thanks,

Kevin R. Bulgrien

Juergen Weigert wrote:


Hi coreutils people!

On a recent SUSE Linux df became unreliable for e.g. USB-drives.
This is because hald automatically mounts and unmounts such drives
as they are accessed.

Usually I get something like:

$ df /media/USB_DISK
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/sda10 0 0   -  /media/USB_DISK

only if the USB_DISK is being accessed, I get the expected output.

$ ls /media/USB_DISK > /dev/null; df /media/USB_DISK
Filesystem   1K-blocks  Used Available Use% Mounted on
/dev/sda1   252522238718 13804  95% /media/USB_DISK

A simple enhancement for df is to actively access the USB_DISK while
running statfs(). I've added an opendir() call in the attached patch. This
can be suppressed with a new commandline option -n.

Please keep me in CC, I am not subscribed.

thanks,
Jw.


Paul Eggert wrote:


Juergen Weigert <[EMAIL PROTECTED]> writes:


Unless I'm missing something I'd rather not change the default behavor
of df, as that would be a compatibility hassle.  That is, df shouldn't
attempt to mount file systems by default; it should do so only if the
user asks, with a new option.

These hald mounts are different. For almost every aspect such a device
appears to be mounted. So I figured, df should also pretend the
device is mounted.

But lots of programs other than df invoke statfs.  We shouldn't have
to change them all.  Instead, it would be much better to fix statfs to
do the right thing with hald mounts.  statfs should return values that
are consistent with every other system call: it should not return
incorrect values simply for the convenience of some low-level hardware
abstraction layer.

Please also see the message from Ivan Guyrdiev of Cornell archived at
 dated
2005-07-20 in which he says something similar: the statfs
implementation needs to get fixed.



Looks ugly in df.c, right. But in fsusage.c we'd have to place the
new code in multiple implementations. Ugly too.

It would only need to be placed in sections corresponding to
implementations that have the bug.  Currently, that's just one
implementation: GNU/Linux, and only a small subset of these hosts as
well.  Since the workaround issues more system calls, it would be nice
to detect the broken implementations at compile-time somehow, or at
least filter out the obviously non-broken implementations.







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

Re: Bug: "echo -e "\0NNN" doesn't require leading '0'

[Eric Blake]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

According to L. Walsh on 3/19/2006 1:19 PM:
> An incompatibility in echo has crept into the gnu version
> of echo.  In extended processing, the leading "0" is no
> longer required to start an octal sequence.  This is not
> compatible with other extended echo implementations and
> can cause un-anticipated side effects (like echoing "awk"
> replacement args "\1" into an awk input script).

Echo is inherently non-portable.  Implementations are allowed by POSIX to
support octal escapes without leading zeros as an extension to the XSI
required set of backslash sequences (POSIX only requires that portable
applications limit themselves to defined sequences, where the definition
includes the leading 0 for octal escapes).  Consider using printf instead.

- --
Life is short - so eat dessert first!

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

iD8DBQFEINQj84KuGfSFAYARAh+EAJ4/VwGqdORXB660limLrfoZQVUXQQCeOUkZ
EFl783N9j6+XXZLBRcD+oXY=
=nrxB
-END PGP SIGNATURE-


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

Re: df enhancment for removable media

[Kevin R. Bulgrien]

Phillip Susi wrote:

> This sounds like an autofs problem.  I'm running ubuntu and hal auto
> mounts removable media when it is inserted.  When it is not mounted, df
> will not show a line for it at all, since df only shows mounted points.
>   I think what you are seeing is an autofs mount point being mounted
> there which is why df shows a line for the mount point, but autofs has
> decided to unmount the real fs and return bogus stat values.
>
> I'd suggest not using autofs.  In any case, this isn't a bug with df.
 
It's not my system, and as an author of a script used by a lot of
people, I don't have a choice about how the system is configured,
but my script has to work anyway.  In this case I do not think it
is autofs.  The example given was from a previous post.  df does
not report a mounted directory in the case I am thinking of.  This
was unheard of for me because the script specifically mounted the
disk.

I didn't say this was a df bug, but I did ask if anything came of
the discussion about working on statfs so that on Suse systems like
this, the df command would do enough so that hal (or whoever) would
properly mount the media enough to get a valid df reading.  Last I
could see on the thread, nobody was disputing that this would be a
good thing.

> Unless I'm missing something I'd rather not change the default behavor
> of df, as that would be a compatibility hassle.  That is, df shouldn't
> attempt to mount file systems by default; it should do so only if the
> user asks, with a new option.
 These hald mounts are different. For almost every aspect such a device
 appears to be mounted. So I figured, df should also pretend the
 device is mounted.
>>> But lots of programs other than df invoke statfs.  We shouldn't have
>>> to change them all.  Instead, it would be much better to fix statfs to
>>> do the right thing with hald mounts.  statfs should return values that
>>> are consistent with every other system call: it should not return
>>> incorrect values simply for the convenience of some low-level hardware
>>> abstraction layer.

Sorry, but its just plain weird to have a system dismount media that
you explicitly mounted.  All I am looking for is an idea of the most
sane way to script something so I can get what I want from df on a
system that is configured like the Suse systems that spawned the
thread in the first place.  I just have not encountered this type
of situation before.

Kevin R. Bulgrien




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

Re: --preserve (cp is still changing file?)

[Bob Proulx]

The Batterson's wrote:
> The preserve function isn't working properly.

Thank you for your report.  But in order to understand the problem you
are having we need more information.  The preserve function is working
for me and must also be working for many other people otherwise we
would have more bug reports about it.

What version of cp from coreutils are you using?  Use --version to
determine this.

  cp --version

What operating system are you using?  Usually uname -a helps here.

  uname -a

What filesystems are involved?  The 'df -T' command may be useful
here.

  df -T .

> rsync copies over the existing file even though it's the same file.

The default for rsync is that if the file timestamp and size match
then it will assume the files are the same.

> Is cp changing something even though I have --preserve?  It doesn't
> seem to be preserving the time stamp.

If you would look at the file size, timestamp and contents after the
copy and verify that the file either is or is not the same after the
copy that is the information needed.

  ls -ld somefile
  cp -p somefile someotherfile
  ls -ld someotherfile

> Please see the script below.

> # KFI Tech Guy
> ls -t ~/iPodderData/downloads/'KFI Tech Guy' | head -2 | xargs -i cp -v 
> --preserve ~/iPodderData/downloads/'KFI Tech Guy'/{} 
> ~/iPodderData/downloads/temp/{}
> rm ~/iPodderData/downloads/'KFI Tech Guy'/*
> cp -v --preserve ~/iPodderData/downloads/temp/* 
> ~/iPodderData/downloads/'KFI Tech Guy'/
> rsync -a --progress --delete ~/iPodderData/downloads/'KFI Tech Guy'/ 
> /media/usbdisk/Podcasts/'KFI Tech Guy'/
> rm ~/iPodderData/downloads/temp/*

Unfortunately your script does not illustrate any problems to me.  It
is just a series of commands with no results of those commands.

Bob


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

Re: Using SORT on Linux

[Bob Proulx]

Oshea, Richard wrote:
> Not sure if this is a bug or a problem with the way my environment
> it setup - or the way I'm using sort - But...  Given the following
> data in a file, the sort command does not produce the correct
> output.

Are you passing any options to sort?

> I have even tried setting the LC_ALL as suggested in the sort --help
> (set LC_ALL=C)

"set LC_ALL=C"?  What shell are you using?  Try this:

  env LC_ALL=C sort

> AG1
> AG2   3
> AG2   2
> AG3   4
> AG4
> AG3   3
> AG4   5
> AG4   6
> 
> The results are
> 
> AG1
> AG2   2
> AG2   3
> AG3   3
> AG3   4
> AG4
> AG4   5
> AG4   6

Check the whitespace characters.  Are there non-printable characters
there?

> I would expect the output to be more like ...
> 
> AG1
> AG4
> AG2   2
> AG2   3
> AG3   3
> AG3   4
> AG4   5
> AG4   6

That is the result I get on my machine when I test with your input.

What version of sort are you using?  What operating system are you
working on?  What locale are you using?

  sort --version
  uname -a
  locale

Bob


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