Bug 3465 - Option to delete unlisted files with --files-from
Summary: Option to delete unlisted files with --files-from
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: Other AIX
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
: 7350 (view as bug list)
Depends on:
Reported: 2006-01-30 15:15 UTC by Michael Grenier (mail address dead)
Modified: 2020-07-28 00:16 UTC (History)
2 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Michael Grenier (mail address dead) 2006-01-30 15:15:52 UTC
If a file is on the destination box but not specified in the file given to --files-from option, shouldn't the file be deleted?

Actual command:
rsync -vrptgz --delete -l -P -e rsh --stats --bwlimit=120  --timeout=1600 --files-from=files.txt /src somebox:/src

I want the files and directories under somebox:/src that are not listed in files.txt to be deleted. 
This is on AIX 5. (Perhaps this is a feature request?)
Comment 1 Wayne Davison 2006-01-30 15:22:39 UTC
Nope, that's not how these options work.

It might be interesting to add an option that would tell rsync to transform the piecemeal set of files and implied directories into a hierarchy of normal directories, but that can't be the default or it would break the more traditional uses of --files-from.
Comment 2 Michael Grenier (mail address dead) 2006-01-31 09:13:56 UTC
Another work around might be to allow a --max-size of zero combined with a --delete. --maxsize of zero is not supported in rsync. While it wouldn't completely solve the original problem, it will at least delete files on the receiver that are not in the senders directory without transferring anything. Thus one would do the original transfer first:
rsync -vrptgz --delete -l -P -e rsh --stats --bwlimit=120  --timeout=1600
--files-from=files.txt /src somebox:/src

followed by something like:
rsync -rv --delete --max-size=0 -e rsh /src somebox:/src
to get rid of extra files. Of course, files could still exist on the receiving side that in the senders directory tree that were not part of the --files-from list. But its a start. I supposed I could try to exclude everything (but then I'd need to learn about patterns :-). 

Comment 3 Wayne Davison 2006-01-31 11:13:05 UTC
(In reply to comment #2)
> Another work around might be to allow a --max-size of zero combined with a
> --delete.

The recommended way to ask rsync to only delete files is to use the combination of --existing and --ignore-existing together so that rsync is skipping all file transfers and directory/symlink/device creations.

There's also the script I just mentioned on the mailing list that turns a list of files into a set of includes & excludes that can be used in place of the --files-from option.  The version from CVS is available here:

Comment 4 Matt McCutchen 2006-08-01 20:34:27 UTC
It would be nice to have an option --delete-unlisted that causes the receiving rsync to delete extraneous files even from destination directories whose "contents" were not part of the transfer.  The option would be as simple to implement as marking all directories with FLAG_DEL_HERE.  Then Michael could use --delete-unlisted to "make --files-from delete".
Comment 5 Matt McCutchen 2010-02-08 12:47:40 UTC
Clarifying summary and bumping version (this feature still hasn't been added in 3.1.0dev).
Comment 6 Matt McCutchen 2010-04-12 07:06:16 UTC
*** Bug 7350 has been marked as a duplicate of this bug. ***
Comment 7 Jeff Siddall 2011-02-01 20:35:27 UTC
Any progress on this?  An option to delete everything in DEST that isn't included in the transfer via something like a --delete-non-included option would make my life _so_ much easier.  Since the workarounds are all varying degrees of ugly this is more than just a nice-to-have.

I am trying to do:

rsync -a --delete /a/b/ /c/d/e/ /f

In /f I only want the contents of directories b and e and nothing else -- even if something else is already there.

Also, the OS and hardware could probably be set to all since this is something that applies to all platforms.
Comment 8 Wayne Davison 2020-07-28 00:16:00 UTC
Jeff: the command you mention already works fine, since --files-from is not involved.