On Tue, Sep 24, 2013 at 14:04:55 +0300, Sergey Poznyakoff wrote: > Strand, Jörgen <jorgen.str...@sonymobile.com> ha escrit: > > > When using -remove-files together with -r and -C wrong files will be > > removed. > > Thanks for reporting. I've pushed commit e3d28d84, which fixes this bug, > as well as other issues reported by Nathan.
I took a quick look at this patch, and noticed that there is still an "actual" chdir call left, in names.c:name_next_elt() ... and so it's possible to confuse the new tar_getcwd() function by using two -C options (when in --create/non-incremental mode): $ mkdir foo $ echo foo/file > foo/file $ mkdir bar $ echo bar/file > bar/file $ find . ./foo ./foo/file ./bar ./bar/file $ tar -cvf foo.tar --remove-files -C foo file -C ../bar file file file $ find . ./foo ./bar ./bar/file ./foo.tar If I look at an strace, both unlink calls point to a path that includes the first -C directory: unlinkat(AT_FDCWD, "/home/nathanst/tartest/foo/file", 0) = 0 unlinkat(AT_FDCWD, "/home/nathanst/tartest/foo/file", 0) = -1 ENOENT (No such file or directory) (Basically tar_getcwd() only looks up the "actual" cwd once, but in this code path the "actual" cwd does change over the course of the program run....) Nathan ---------------------------------------------------------------------------- Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko & Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239