du: cache directory size

2008-07-03 Thread Mildred
Hi,

I noticed that du takes a long time to scan directories and measure
disk usage.

I was thinking that perhaps caching the size of directories could bu
useful. Perhaps, after du computes the size of a directory, it could
write its size in its extended attributes (if the filesystem support
it). Next time, du would only compare the directory atime (or mtime
perhaps) with the time of the scan. That could possibly save some time
during the scan.

Perhaps this is not something to be included in du itself, but I
thought it could be a good idea to give the idea anyway.

Thanks for reading.

Mildred

-- 
Mildred Ki'lya
E-Mail: mildred593(at)online.fr

Site:   http://mildred632.free.fr/
XMPP:   [EMAIL PROTECTED] (GoogleTalk, Jabber)

GPG:197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]


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


finger pinky commands reports improper exit status

2008-07-03 Thread Halesh S
Test 1:
--
$ finger some-user
finger: 1: no such user.
$echo $?
0

Test 2:
--
$pinky some-user
LoginName TTY  Idle   When Where
$echo $?
0

Verified in coreutils-6.9

Patch to fix the issue in pinky(1)

---old.src/pinky.c 2008-07-03 12:48:49.0 +0530
+++ src/pinky.c  2008-07-03 12:48:18.0 +0530
@@ -438,6 +438,7 @@
 scan_entries (size_t n, const STRUCT_UTMP *utmp_buf,
  const int argc_names, char *const argv_names[])
 {
+  int not_found_flg = 1;
   if (hard_locale (LC_TIME))
 {
   time_format = %Y-%m-%d %H:%M;
@@ -464,6 +465,7 @@
if (strncmp (UT_USER (utmp_buf), argv_names[i], UT_USER_SIZE)
== 0)
  {
+  not_found_flg = 0;
print_entry (utmp_buf);
break;
  }
@@ -473,6 +475,12 @@
}
   utmp_buf++;
 }
+   if (not_found_flg)
+ {
+fprintf (stderr, _(no user found.\n),
+ program_name);
+   exit(1);
+ }
 }

 /* Display a list of who is on the system, according to utmp file FILENAME. */
===

After applaying patch

Test 2
-
$pinky some-user
LoginName TTY  Idle   When Where
no user found.
$echo $?
1

Thanks,
Halesh


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


Re: du: cache directory size

2008-07-03 Thread Andreas Schwab
Mildred [EMAIL PROTECTED] writes:

 I was thinking that perhaps caching the size of directories could bu
 useful. Perhaps, after du computes the size of a directory, it could
 write its size in its extended attributes (if the filesystem support
 it). Next time, du would only compare the directory atime (or mtime
 perhaps) with the time of the scan. That could possibly save some time
 during the scan.

Just because a directory is unchanged does not mean that all files and
subdirectories beneath it are unchanged as well.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


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


Re: du: cache directory size

2008-07-03 Thread Philip Rowlands

On Wed, 2 Jul 2008, Mildred wrote:

I was thinking that perhaps caching the size of directories could bu 
useful. Perhaps, after du computes the size of a directory, it could 
write its size in its extended attributes (if the filesystem support 
it). Next time, du would only compare the directory atime (or mtime 
perhaps) with the time of the scan.


Unfortunately neither the atime nor mtime of a directory would 
necessarily show a change to the disk usage of the enclosed files. 
Consider a logfile, for example; the filesize grows continuously, but 
makes no change to the directory.



Cheers,
Phil


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


Re: du: cache directory size

2008-07-03 Thread Pádraig Brady
Mildred wrote:
 Hi,
 
 I noticed that du takes a long time to scan directories and measure
 disk usage.
 
 I was thinking that perhaps caching the size of directories could bu
 useful. Perhaps, after du computes the size of a directory, it could
 write its size in its extended attributes (if the filesystem support
 it). Next time, du would only compare the directory atime (or mtime
 perhaps) with the time of the scan. That could possibly save some time
 during the scan.

Those values would be invalidated though once a change
has been written anywhere in the tree under a directory.

 Perhaps this is not something to be included in du itself, but I
 thought it could be a good idea to give the idea anyway.

The idea might be appropriate on a per file basis.

For example, md5sum which needs to do significant processing
on all of a file's data, could cache the computed value in
an extended attribute. You would need support in the filesystem
though, to invalidate certain extended attributes on write.

Pádraig.


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


wc -m count is wrong

2008-07-03 Thread Hossain, Syed
Hi gurus,

 

I am surprised that I could not found any posting related to this, I was
doing simple character count and here is the output from wc:

 

/home/shossain$ echo 1234 | wc -m

5

/home/shossain$

 

Obviously I was expecting a count of 4 but wc printed out 5. I have
tried different string and the count is always increased by one. I also
did a test using file:

 

/home/shossain$ echo 0123456789  test.wc

/home/shossain$ cat test.wc

0123456789

/home/shossain$ cat test.wc | wc -m

11

/home/shossain$

 

Count should have 10 in this case but wc printed 11

 

Here is the wc version information:

/home/shossain$ which wc

/usr/bin/wc

/home/shossain$ ls -l /usr/bin/wc

-rwxr-xr-x  1 root root 21860 Jun 20  2005 /usr/bin/wc

/home/shossain$ wc --version

wc (coreutils) 5.2.1

Written by Paul Rubin and David MacKenzie.

 

Copyright (C) 2004 Free Software Foundation, Inc.

This is free software; see the source for copying conditions.  There is
NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

/home/shossain$

 

 

Here is the Linux kernel information:

/home/shossain$ uname -a

Linux X.neustar.com 2.6.9-22.ELsmp #1 SMP Mon Sep 19 18:32:14 EDT
2005 i686 i686 i386 GNU/Linux

 

Please let me know if any other information I need to provide for this
bug. Thanks.

 

Syed

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


Makefile.am issue (and patch)

2008-07-03 Thread Brian Silverman


I'm having a small issue with make install of coreutils.  I've included 
below a patch that solves my problem.


I am using coreutils-6.12, and building it under cygwin, and I'm 
cross-compiling it to a PPC-440.


Here's my build steps:
   ./configure  --host=powerpc-440-linux-gnu --prefix=`pwd`/__images
   make
   make install

configure and make work fine.  But make install fails with:
   ./ginstall: ./ginstall: cannot execute binary file

To fix this, I'm using the patch below.  Note that the change in my 
patch applies to code from a very recent checkin:
   
http://git.savannah.gnu.org/gitweb/?p=coreutils.git;a=commitdiff;h=9d595099372e2eabbecce2f303058743e93f0748


Perhaps my issue is only related to cross-compiling?  Or is there a 
better fix I should use?


Here's my patch:

diff -urN coreutils-6.12/src/Makefile.am coreutils-6.12.new/src/Makefile.am
--- coreutils-6.12/src/Makefile.am2008-05-31 14:15:33.0 -0400
+++ coreutils-6.12.new/src/Makefile.am2008-07-03 12:46:25.260074200 
-0400

@@ -434,7 +434,7 @@
install-exec-am:
@case '$(program_transform_name):$(EXEEXT)' in\
  's,x,x,:') cu=cu-;; *) cu= ;; esac;\
-$(MAKE) $(AM_MAKEFLAGS) binPROGRAMS_INSTALL=./ginstall\
+$(MAKE) $(AM_MAKEFLAGS) \
  $${cu}install-binPROGRAMS
@$(NORMAL_INSTALL)
$(MAKE) $(AM_MAKEFLAGS) install-exec-hook

--
Brian Silverman
Concept X, LLC



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


Re: du: cache directory size

2008-07-03 Thread Mildred

Le Thu 03/07/2008 à 14:29 Philip Rowlands à écrit:

 Unfortunately neither the atime nor mtime of a directory would 
 necessarily show a change to the disk usage of the enclosed files. 
 Consider a logfile, for example; the filesize grows continuously, but 
 makes no change to the directory.


You're probably right. I thought a modification on a file would change
directories times but the test I made must have been incorrect.

Thanks everyone

Mildred


-- 
Mildred Ki'lya
E-Mail: mildred593(at)online.fr

Site:   http://mildred632.free.fr/
XMPP:   [EMAIL PROTECTED] (GoogleTalk, Jabber)

GPG:197C A7E6 645B 4299 6D37 684B 6F9D A8D6 [9A7D 2E2B]


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


Re: wc -m count is wrong

2008-07-03 Thread Bob Proulx
Hossain, Syed wrote:
 I am surprised that I could not found any posting related to this,

Here is a recent one.  :-)

  http://lists.gnu.org/archive/html/bug-coreutils/2008-04/msg00238.html

 /home/shossain$ echo 1234 | wc -m
 5
 Obviously I was expecting a count of 4 but wc printed out 5. I have
 tried different string and the count is always increased by one.

The newline on the end of the line is a character.  You can see this
by using od to dump the values.

  echo 1234 | od -tx1 -c
  000 31 32 33 34 0a
1   2   3   4  \n

Of course wc is behaving correctly here.

Bob


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


Re: tee logs no output if stdout is closed

2008-07-03 Thread Phillip Susi

Andreas Schwab wrote:

It would match the behaviour as defined by ASYNCHRONOUS EVENTS in 1.11
Utility Description Defaults.


Could you quote that section or give me a url to somewhere I can see it 
myself?  I have no idea what it says nor where to look it up.


Also what about the issue where tee will try to write() to the now 
broken fd and fail?



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


(no subject)

2008-07-03 Thread Craig Naumann
hello, i cant use the ls command in cygwin, it says command not found.


  



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


Re: finger pinky commands reports improper exit status

2008-07-03 Thread Halesh S
The last patch has missied for no-args.
The attached patch will fix the issue.

Thanks,
Halesh

n 7/3/08, Halesh S [EMAIL PROTECTED] wrote:
 Test 1:
  --
  $ finger some-user
  finger: 1: no such user.
  $echo $?
  0

  Test 2:
  --
  $pinky some-user
  LoginName TTY  Idle   When Where
  $echo $?
  0

  Verified in coreutils-6.9

  Patch to fix the issue in pinky(1)
  
  ---old.src/pinky.c 2008-07-03 12:48:49.0 +0530
  +++ src/pinky.c  2008-07-03 12:48:18.0 +0530
  @@ -438,6 +438,7 @@
   scan_entries (size_t n, const STRUCT_UTMP *utmp_buf,
   const int argc_names, char *const argv_names[])
   {
  +  int not_found_flg = 1;
if (hard_locale (LC_TIME))
  {
time_format = %Y-%m-%d %H:%M;
  @@ -464,6 +465,7 @@
 if (strncmp (UT_USER (utmp_buf), argv_names[i], UT_USER_SIZE)
 == 0)
   {
  +  not_found_flg = 0;
 print_entry (utmp_buf);
 break;
   }
  @@ -473,6 +475,12 @@
 }
utmp_buf++;
  }
  +   if (not_found_flg)
  + {
  +fprintf (stderr, _(no user found.\n),
  + program_name);
  +   exit(1);
  + }
   }

   /* Display a list of who is on the system, according to utmp file FILENAME. 
 */
  ===

  After applaying patch

  Test 2
  -
  $pinky some-user
  LoginName TTY  Idle   When Where
  no user found.
  $echo $?
  1

  Thanks,

 Halesh



pinky.c.patch
Description: Binary data
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils