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 21; then
+if dd iflag=noatime if=$tmp_in of=$tmp_out  /dev/null 21; 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: 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 stdbool.h
 # 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 some other process)
 

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
  nntp://news.gmane.org/gmane.comp.gnu.core-utils.bugs
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:
  http://savannah.gnu.org/patch/?func=detailitemitem_id=4978

 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
http://savannah.gnu.org/patch/download.php?item_id=4978item_file_id=6048

___

Reply to this item at:

  http://savannah.gnu.org/patch/?func=detailitemitem_id=4978

___
  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)
-   goto memory_exhausted;
-
-

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

FYI, bug-coreutils list/archive woes

[Jim Meyering]

FYI, the web (mailman) database has had problems.
  http://lists.gnu.org/archive/html/bug-coreutils/
People have been working on it.  For details and status, see
  http://savannah.gnu.org/

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
 http://www.nsa.gov/selinux/list-archive/0507/thread_body36.cfm 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
 http://www.nsa.gov/selinux/list-archive/0507/thread_body36.cfm 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 (_(  nocttydo not assign controlling terminal from file\n),
 stdout);
  +  if (O_NOFOLLOW)
  +   fputs (_(  nofollow  do not follow symlinks\n), stdout);
  +  if (O_NOLINKS)
  +   fputs (_(  nolinks   fail if multiply-linked\n), stdout);
 if 

remove - bug ???

[Vineet Chadha]

** bug-coreutils@gnu.orgModern 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
http://www.nsa.gov/selinux/list-archive/0507/thread_body36.cfm 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