Bug 11269 - "newer" option doesn't work for tar
"newer" option doesn't work for tar
Product: Red Hat Linux
Classification: Retired
Component: tar (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bernhard Rosenkraenzer
Depends On:
  Show dependency treegraph
Reported: 2000-05-06 19:42 EDT by Stephen Rasku
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2000-05-09 02:49:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen Rasku 2000-05-06 19:42:13 EDT
I created a directory with 3 files all with different times:

[stephen@granite stephen/test] 1024 $ ls -l --full-time tartest
total 0
-rw-r--r--    1 stephen  develop         0 Sat May 06 16:38:04 2000 x
-rw-r--r--    1 stephen  develop         0 Sat May 06 16:38:28 2000 y
-rw-r--r--    1 stephen  develop         0 Sat May 06 16:38:31 2000 z

I then tried to tar it up using the time for y as the parameter to -N.
This should only tar up the z file since it is the only one newer than that
time but it tars up all three files:

[stephen@granite stephen/test] 1026 $ tar -N "Sat May 06 16:38:28 2000"
-cvf test.tar tartest
Comment 1 Stephen Rasku 2000-05-09 02:49:59 EDT
The problem was occuring because -N uses the "status change time" rather than
the "modify time" to do this.  (Use ls -lc to see the change time.)  From the
info file, it is obvious that it was designed to work this way.  Whether this is
a good decisision is debatable mostly because the default time shown in ls is
not the time used for the -N option.  However, changing how the options work is
a decision that should not be taken lightly and a mis-use of these options fails
in a conservative way (i.e. it backs up more files not less).  In any case, I
include a patch for a change to the man page to be more descriptive about these
options.  (Is there a better way to attach patches rather than including it in
the comments?)  I will let the owner close this bug so that they can look at the

--- tar113.1    Mon May  8 23:13:46 2000
+++ tar.1       Mon May  8 23:31:50 2000
@@ -69,7 +69,10 @@
 .B -M, --multi-volume
-.B -N, --after-date DATE, --newer DATE
+.B -N DATE, --after-date DATE, --newer DATE
+.B --newer-mtime DATE
 .B -o, --old-archive, --portability
@@ -262,8 +265,12 @@
 .B -M, --multi-volume
 create/list/extract multi-volume archive
-.B -N, --after-date DATE, --newer DATE
-only store files newer than DATE
+.B -N DATE, --after-date DATE, --newer DATE
+only store files whose status has changed since DATE
+.B --newer-mtime DATE
+only store files whose contents have changed since date.  This is the default
+date output from 'ls'.
 .B -o, --old-archive, --portability
 write a V7 format archive, rather than ANSI format
Comment 2 Bernhard Rosenkraenzer 2000-06-17 14:53:55 EDT
Thanks, done.
(Btw: Yes, there is a better way to attach a patch - use the "Create a new
attachment" link).
Comment 3 Stephen Rasku 2000-06-17 15:13:51 EDT
I realized that after I submitted the patch.  I was having the cookie/login
problem, so the option to add a patch was not visible.

Note You need to log in before you can comment on or make changes to this bug.