Bug 11269 - "newer" option doesn't work for tar
Summary: "newer" option doesn't work for tar
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: tar
Version: 6.2
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-05-06 23:42 UTC by Stephen Rasku
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2000-05-09 06:49:39 UTC
Embargoed:


Attachments (Terms of Use)

Description Stephen Rasku 2000-05-06 23:42:13 UTC
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
tartest/
tartest/x
tartest/y
tartest/z

Comment 1 Stephen Rasku 2000-05-09 06:49:59 UTC
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
patch:

--- 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
 .TP
-.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
+.TP
+.B --newer-mtime DATE
+only store files whose contents have changed since date.  This is the default
+date output from 'ls'.
 .TP
 .B -o, --old-archive, --portability
 write a V7 format archive, rather than ANSI format

Comment 2 Bernhard Rosenkraenzer 2000-06-17 18:53:55 UTC
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 19:13:51 UTC
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.