Re: Suggested enhancement to du command - show last modified date.
This is nice. One reason I like it, which I think hasn't been mentioned yet, is that it gives a standard interface to a piece of information that might be used by make systems and other programs which need to find out when directory trees have been modified. Working through a standard interface means that if kernel support is ever added for computing this information more quickly (and possibly directory sizes too), e.g. by keeping it around in each directory inode, then userspace recognition of that support only needs to be added in one place, namely the 'du' command. Thus consolidating the interface to such a computation gives others more motivation to optimize it later. Frederik I use the du command to identify directories for potential archiving. Candidate directories are those that are taking a lot of space, and which are not currently being worked on. The du command conveniently identified the first. To find out the latter requires walking the directory tree, and performing a stat on each file (to obtain the last modified date). du already does most of this. Walking a large directory tree twice, once to collect the file sizes, and a second time to collect the last modified date can be time consuming. I therefore suggest that du should have an option to collect the latest last modified date for the files in a directory. I have hacked together a version of du that does this, taking the date formatting code from the date utility. If my modified program is run as (for example) du --last-modified, it produces output such as the following: 368 2004/03/12.19:18./config 1004 2005/06/02.13:53./m4 560 2004/03/12.19:18./old/fileutils 256 2004/03/12.19:18./old/sh-utils 336 2004/03/12.19:18./old/textutils 1156 2004/03/12.19:18./old 14316 2005/06/02.13:53./po 636 2005/06/02.14:12./lib/.deps 6396 2005/06/02.14:12./lib 760 2005/06/02.14:13./src/.deps 19692 2005/06/02.18:47./src 1116 2005/06/02.13:53./doc 824 2005/06/02.13:53./man 522005/06/02.13:53./tests/basename 682005/06/02.13:53./tests/chgrp I chose this default date format so that the sort utility will regard it as one field, and so that alphabetical sorting is the same as date sorting. I can also specify the date format required, using the same syntax as for the date command. For example, using du --last-modified=%e/%b/%Y produces: 368 12/Mar/2004 ./config 1004 2/Jun/2005 ./m4 560 12/Mar/2004 ./old/fileutils 256 12/Mar/2004 ./old/sh-utils 336 12/Mar/2004 ./old/textutils 1156 12/Mar/2004 ./old 14316 2/Jun/2005 ./po 6362/Jun/2005 ./lib/.deps 6396 2/Jun/2005 ./lib 7602/Jun/2005 ./src/.deps 19692 2/Jun/2005 ./src 1116 2/Jun/2005 ./doc 8242/Jun/2005 ./man 52 2/Jun/2005 ./tests/basename 68 2/Jun/2005 ./tests/chgrp Without the --last-modified switch, the modified program functions as previously. If you think my suggestion worthwhile, I would be happy to contribute my modified code back to the GNU project, but I am very much a GNU newbie. I don't know how to generate patch files. Also I have not made any attempt to update the man files or other documentation. Please let me know if you would like me to submit the code, and if so, how I should do so ? Alternately, you could probably produce a better implementation, based upon my description above. Yours sincerely, Bill Brendling. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils -- http://ofb.net/~frederik/ ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Suggested enhancement to du command - show last modified date.
William Brendling [EMAIL PROTECTED] wrote:
The second iteration of my patch to du to show last modified date follows.
...
Thank you for the patch.
I've applied it, albeit with some difficulty due to changes
in leading white space and split lines caused no doubt by your
mail client.
I've made some minor additional changes:
* src/du.c (show_date): Rename local `time_format' so as not to
shadow the file-scoped global by that name.
(show_date): Add a FIXME comment.
* src/du.c: Include hard-locale.h and strftime.h.
(DUINFO_INI, DUINFO_SET, DUINFO_ADD):
Enclose body in `do {...} while (0)', not just `{...}'.
Adjust uses (add semicolons).
Adjust formatting, indentation.
(usage): Tweak formatting to maintain more or less constant indentation.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Suggested enhancement to du command - show last modified date.
Jim Meyering [EMAIL PROTECTED] writes:
Thank you for the patch.
I've applied it
Yes, it's a nice thing to add. Thanks too.
I reviewed the patch and have some more ideas, which I installed as
follows. One more thing (which I didn't do yet) is that there's a
reasonable amount of code duplication between ls, du, and date, and it
should be refactored at some point. I see you've got a FIXME about
that already
2005-06-23 Paul Eggert [EMAIL PROTECTED]
Address the following du issues:
- The option name --last-time=TYPE is different from the ls's option
--time=TYPE with a similar meaning. I assume this wasn't intended.
- --time-style implies --time, but this is not true for ls. It's
better to be consistent.
- Since we don't have POSIX compatibility concerns, there's no need
for the posix- styles, or for support of styles with newlines, or
for the locale style, except for parsing the TIME_STYLE
environment variable.
- It's cleaner (and these days, no less efficient) to use functions
rather than macros when possible.
- struct duinfo doesn't need a 'valid' flag; you can simply use a time
stamp that is less than all valid time stamps.
- The code needs a bit of reformatting to fit the usual GNU style.
* NEWS: du's --last-time option is now --time.
* doc/coreutils.texi (ls invocation): Fix typo: --time=use is
equivalent to --time=atime, not --time=ctime.
(ls invocation, du invocation): Fix typo: --time-style=long-iso
is equivalent to a time style with a leading +.
(du invocation): --last-time is now --time.
--time-style no longer implies --time.
The locale and posix- stuff now works only for TIME_STYLE, not
for --time-style. Give equivalent format for --time-style=iso.
* src/du.c: Do not include hard-locale.h.
(struct duinfo): Remove 'valid' member. All uses changed to use
negative nsec instead.
(DUIINFO_INI, DUINFO_SET, DUINFO_ADD): Remove.
(duinfo_init, duinfo_set, duinfo_add): New functions, taking the
role of the removed macros.
(opt_time): Renamed from opt_last_time. All uses changed.
(TIME_OPTION): Renamed from LAST_TIME_OPTION. All uses changed.
(long_options, usage): Rename --last-time to --time.
(locale_time_style): Remove.
(time_style_args, time_style_types, usage): Remove support for
--time-style=locale.
(show_date): Now returns void, since nobody looked at the result.
Assume FORMAT is not null. An empty FORMAT now outputs an empty time.
Simplify nstrftime invocation.
(main): Put in ls compatibility workarounds only for TIME_STYLE,
not for --time-style. Omit unnecessary space in iso time style.
Index: NEWS
===
RCS file: /fetish/cu/NEWS,v
retrieving revision 1.298
diff -p -u -r1.298 NEWS
--- NEWS23 Jun 2005 14:47:27 - 1.298
+++ NEWS23 Jun 2005 22:24:38 -
@@ -151,7 +151,7 @@ GNU coreutils NEWS
dd has new iflag= and oflag= flags binary and text, which have an
effect only on nonstandard platforms that distinguish text from binary I/O.
- du accepts new options: --last-time[=TYPE] and --time-style=STYLE
+ du accepts new options: --time[=TYPE] and --time-style=STYLE
join now supports a NUL field separator, e.g., join -t '\0'.
join now detects and reports incompatible options, e.g., join -t x -t y,
Index: doc/coreutils.texi
===
RCS file: /fetish/cu/doc/coreutils.texi,v
retrieving revision 1.267
diff -p -u -r1.267 coreutils.texi
--- doc/coreutils.texi 23 Jun 2005 15:00:29 - 1.267
+++ doc/coreutils.texi 23 Jun 2005 22:24:40 -
@@ -5677,7 +5677,6 @@ it outputs. By default, sorting is done
@item -c
@itemx --time=ctime
@itemx --time=status
[EMAIL PROTECTED] --time=use
@opindex -c
@opindex --time
@opindex [EMAIL PROTECTED], printing or sorting by}
@@ -5724,6 +5723,7 @@ Sort by modification time (the @samp{mti
@item -u
@itemx --time=atime
@itemx --time=access
[EMAIL PROTECTED] --time=use
@opindex -u
@opindex --time
@opindex use [EMAIL PROTECTED], printing or sorting files by}
@@ -6009,7 +6009,7 @@ uses the full timestamp to determine whe
List @acronym{ISO} 8601 date and time in minutes, e.g.,
@samp{2002-03-30 23:45}. These timestamps are shorter than
@samp{full-iso} timestamps, and are usually good enough for everyday
-work. This style is equivalent to @samp{%Y-%m-%d %H:%M}.
+work. This style is equivalent to @samp{+%Y-%m-%d %H:%M}.
@item iso
List @acronym{ISO} 8601 dates for non-recent timestamps (e.g.,
@@ -9004,30 +9004,6 @@ Dereference symbolic links (show the dis
or directory that the link points to instead of the space used by
Re: Suggested enhancement to du command - show last modified date.
The following patch is my fist iteration at implementing my suggested
--last-modified option for du. It is a simple port of my original
draft code to the latest CVS source for du.
Doesn't the standard ISO-8601 date format accomplish that, too?
I have changed the default date format to be ISO-8601 (I think).
Writing ChangeLog entries describing your changes is helpful.
It's good to update the --help output and even better to update
the primary documentation in the file doc/coreutils.texi.
I have added ChangeLog entries. I have also had a go at the
coreutils.texi file, but I don't really know what I am doing here.
Guess and hope.
Plans for the next iteration, if I find the time:
It might be nice to have an option that makes it look
at atime rather than mtime.
* Implement Jim Meyering's suggested improvements.
* From a coding point of view, it would be better if the per-directory
level variables (sum_ent, sum_subdir, dmax_ent, dmax_subdir) were in a
structure, requiring only one alloc/realloc, rather than the four
currently used. My excuse is that the original code already had two
alloc/reallocs.
Patch follows:
Index: coreutils/ChangeLog
===
RCS file: /cvsroot/coreutils/coreutils/ChangeLog,v
retrieving revision 1.1314
diff -u -r1.1314 ChangeLog
--- coreutils/ChangeLog 2 Jun 2005 10:04:32 - 1.1314
+++ coreutils/ChangeLog 8 Jun 2005 17:38:45 -
@@ -1,3 +1,7 @@
+2005-06-06 William Brendling [EMAIL PROTECTED]
+
+ * src/du.c: Added --last-modified switch.
+
2005-06-02 Jim Meyering [EMAIL PROTECTED]
* Version 5.3.1.
Index: coreutils/doc/ChangeLog
===
RCS file: /cvsroot/coreutils/coreutils/doc/ChangeLog,v
retrieving revision 1.237
diff -u -r1.237 ChangeLog
--- coreutils/doc/ChangeLog 2 Jun 2005 05:00:50 - 1.237
+++ coreutils/doc/ChangeLog 8 Jun 2005 17:39:54 -
@@ -1,3 +1,7 @@
+2005-06-06 William Brendling [EMAIL PROTECTED]
+
+ * coreutils.texi (du invocation): New flag --last-modified.
+
2005-06-01 Paul Eggert [EMAIL PROTECTED]
Use file name when talking about file names, instead of filename
Index: coreutils/doc/coreutils.texi
===
RCS file: /cvsroot/coreutils/coreutils/doc/coreutils.texi,v
retrieving revision 1.259
diff -u -r1.259 coreutils.texi
--- coreutils/doc/coreutils.texi2 Jun 2005 05:00:24 - 1.259
+++ coreutils/doc/coreutils.texi8 Jun 2005 17:40:13 -
@@ -9006,6 +9006,18 @@
or directory that the link points to instead of the space used by
the link).
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] last modified dates, displaying in @command{du}
+Show the most recent last modified date of any of the files in the
+directory or sub-directories.
+Optionally format header dates using @var{format}, using the same
conventions as
+for the the command @samp{date [EMAIL PROTECTED]; @xref{date invocation}.
+Except for directives, which start with
[EMAIL PROTECTED], characters in @var{format} are printed unchanged. You can
use
+this option to specify an arbitrary string in place of the header date,
+e.g., @option{--date-format=Monday morning}.
+
@item -P
@itemx --no-dereference
@opindex -P
Index: coreutils/src/du.c
===
RCS file: /cvsroot/coreutils/coreutils/src/du.c,v
retrieving revision 1.203
diff -u -r1.203 du.c
--- coreutils/src/du.c 2 Jun 2005 05:17:24 - 1.203
+++ coreutils/src/du.c 8 Jun 2005 17:40:21 -
@@ -29,13 +29,13 @@
#include getopt.h
#include sys/types.h
#include assert.h
-
#include system.h
#include dirname.h /* for strip_trailing_slashes */
#include error.h
#include exclude.h
#include hash.h
#include human.h
+#include inttostr.h
#include quote.h
#include quotearg.h
#include readtokens0.h
@@ -104,14 +104,19 @@
/* Human-readable options for output. */
static int human_output_opts;
+/* If option non-zero, print most recently modified date, using the
specified format */
+static int opt_last_modified = 0;
+static char *format = NULL;
+
/* The units to use when printing sizes. */
static uintmax_t output_block_size;
/* File name patterns to exclude. */
static struct exclude *exclude;
-/* Grand total size of all args, in bytes. */
+/* Grand total size of all args, in bytes. Also latist modified date. */
static uintmax_t tot_size = 0;
+static time_t tot_dmax = 0;
#define IS_DIR_TYPE(Type) \
((Type) == FTS_DP\
@@ -125,7 +130,8 @@
EXCLUDE_OPTION,
FILES0_FROM_OPTION,
HUMAN_SI_OPTION,
- MAX_DEPTH_OPTION
+ MAX_DEPTH_OPTION,
+ LAST_MODIFIED_OPTION
};
static struct option const long_options[] =
@@ -151,6 +157,7 @@
{separate-dirs, no_argument, NULL, 'S'},
{summarize, no_argument, NULL, 's'},
{total,
Re: Suggested enhancement to du command - show last modified date.
Thanks for contributing! Some comments:
Internally, file time stamps should be maintained to nanosecond
resolution, not just 1-second resolution.
As far as the --last-modified option syntax goes, I suggest that
we use a syntax that is more like that of touch --time. E.g.,
du --last-time='modify'
The default operand for --last-time would be 'modify' (or its alias
'mtime'), but the user could aso specify --last-time='access' (or its
alias 'atime' or 'use') or --last-time='change' (or its alias
'ctime').
For consistency the time stamp format option should use the same
option syntax as 'ls'. E.g.,
du --last-time='modify' --time-style='+%Y-%m-%d'
I suggest using the 'long-iso' time style as the default format, e.g.,
2004-10-02 15:30. This would be the default for ls if it weren't
for POSIX requirements; but since we are inventing an extension to
du we can use 'long-iso'. There's no real need to put that ugly T
in the output.
William Brendling [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] last modified dates, displaying in @command{du}
+Show the most recent last modified date of any of the files in the
That language is a bit hard to parse. How about if you change last
modified date to time of last data modification? That's what it
actually is. This might require some rewording I suppose.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Suggested enhancement to du command - show last modified date.
William Brendling [EMAIL PROTECTED] wrote: ... Doesn't the standard ISO-8601 date format accomplish that, too? Quite likely. I will have to find out what the ISO-8601 format is. date already supports it: $ date --iso=s 2005-06-07T08:14:28+0200 ls does, too, via --time-style=STYLE. du's default format needn't include the time zone. It might be nice to have an option that makes it look at atime rather than mtime. Yes, I thought of that, but did not need it myself. Would you suggest a --last-accessed switch as well as --last-modified, or would it be better to have a modifier --use-time=atime|ctime|mtime? Since ls already has related options, it might make sense to do something similar. How about dropping the `use-' part of the option name and making it --time=...? `use time' or `time of last use' is a common description of `atime'. It's good to update the --help output and even better to update the primary documentation in the file doc/coreutils.texi. I have made an addition to the --help output to describe the --last-modified switch, but not the details of the date formats. I have not yet looked at trying to update the other documentation. You don't have to write much. Just say du's date format string is interpreted just like that of the `date' command. Writing ChangeLog entries describing your changes is helpful. OK. It may take me a while to do all this. No problem. Paperwork usually takes at least a couple weeks. Yes, please send me the forms. No promises. Coming right up. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Suggested enhancement to du command - show last modified date.
First, get a copy of the latest sources from CVS by following the instructions here: Apply your changes there, then run e.g., and mail the contents of DIFF to the mailing list. OK. My current version is based upon the 5.2.1 release code. I will try and port it over to the CVS code. Doesn't the standard ISO-8601 date format accomplish that, too? Quite likely. I will have to find out what the ISO-8601 format is. It might be nice to have an option that makes it look at atime rather than mtime. Yes, I thought of that, but did not need it myself. Would you suggest a --last-accessed switch as well as --last-modified, or would it be better to have a modifier --use-time=atime|ctime|mtime? It's good to update the --help output and even better to update the primary documentation in the file doc/coreutils.texi. I have made an addition to the --help output to describe the --last-modified switch, but not the details of the date formats. I have not yet looked at trying to update the other documentation. Writing ChangeLog entries describing your changes is helpful. OK. It may take me a while to do all this. Contributions are welcome, but when they are not small, they must be accompanied by paperwork assigning copyright to the FSF. You may also need to obtain a disclaimer from your employer. If you're still interested, let me know and I'll send you the forms. Yes, please send me the forms. No promises. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Suggested enhancement to du command - show last modified date.
I use the du command to identify directories for potential archiving. Candidate directories are those that are taking a lot of space, and which are not currently being worked on. The du command conveniently identified the first. To find out the latter requires walking the directory tree, and performing a stat on each file (to obtain the last modified date). du already does most of this. Walking a large directory tree twice, once to collect the file sizes, and a second time to collect the last modified date can be time consuming. I therefore suggest that du should have an option to collect the latest last modified date for the files in a directory. I have hacked together a version of du that does this, taking the date formatting code from the date utility. If my modified program is run as (for example) du --last-modified, it produces output such as the following: 368 2004/03/12.19:18./config 10042005/06/02.13:53./m4 560 2004/03/12.19:18./old/fileutils 256 2004/03/12.19:18./old/sh-utils 336 2004/03/12.19:18./old/textutils 11562004/03/12.19:18./old 14316 2005/06/02.13:53./po 636 2005/06/02.14:12./lib/.deps 63962005/06/02.14:12./lib 760 2005/06/02.14:13./src/.deps 19692 2005/06/02.18:47./src 11162005/06/02.13:53./doc 824 2005/06/02.13:53./man 52 2005/06/02.13:53./tests/basename 68 2005/06/02.13:53./tests/chgrp I chose this default date format so that the sort utility will regard it as one field, and so that alphabetical sorting is the same as date sorting. I can also specify the date format required, using the same syntax as for the date command. For example, using du --last-modified=%e/%b/%Y produces: 368 12/Mar/2004 ./config 1004 2/Jun/2005 ./m4 560 12/Mar/2004 ./old/fileutils 256 12/Mar/2004 ./old/sh-utils 336 12/Mar/2004 ./old/textutils 115612/Mar/2004 ./old 143162/Jun/2005 ./po 636 2/Jun/2005 ./lib/.deps 6396 2/Jun/2005 ./lib 760 2/Jun/2005 ./src/.deps 196922/Jun/2005 ./src 1116 2/Jun/2005 ./doc 824 2/Jun/2005 ./man 52 2/Jun/2005 ./tests/basename 68 2/Jun/2005 ./tests/chgrp Without the --last-modified switch, the modified program functions as previously. If you think my suggestion worthwhile, I would be happy to contribute my modified code back to the GNU project, but I am very much a GNU newbie. I don't know how to generate patch files. Also I have not made any attempt to update the man files or other documentation. Please let me know if you would like me to submit the code, and if so, how I should do so ? Alternately, you could probably produce a better implementation, based upon my description above. Yours sincerely, Bill Brendling. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
