Bug 8682 - Skip current transfer keyboard function
Summary: Skip current transfer keyboard function
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.1.0
Hardware: All All
: P5 enhancement (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2011-12-30 01:02 UTC by b1566587
Modified: 2022-03-04 10:34 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 b1566587 2011-12-30 01:02:00 UTC
rsync should stop transferring the active file upon press of a specific key.

There is already extensive file exclusion functionality, but the ability to skip the current file (the one visible when using --progress) would be really quite handy to have.
Comment 1 martin f. krafft 2015-09-18 09:20:03 UTC
A hack is to save the file on the backedu up host, and overwrite the inode, e.g. "echo > file". This will then cause BackupPC to move on and log an error.

But indeed, having the information about

  - which file is being processed
  - some metadata, e.g. size
  - when processing started

available in the web interface would be great. Ideally, this would then be augmented with the ability to cancel/skip this file and optionally to add the file or the containing directory to the global or host exclude list.
Comment 2 martin f. krafft 2015-09-18 09:20:33 UTC
(the hack is courtesy of Ronny Aasen)
Comment 3 roland 2015-09-19 10:42:58 UTC
that would be a quite useful feature.

i`d recommend that this feature should be activated with a commandline option for safety purpose. and skipping should then be repeated while the key is pressed down, so one could skip multiple files at once or an entire directory structure (e.g. when accidentally syncing /proc etc)
Comment 4 Christian Kujau 2018-03-22 01:54:18 UTC
If this ever gets implemented: instead of (interactively) pressing a key to interrupt the current transfer of a particular object, I'd like it to also react to a signal (e.g. SIGUSR1) that can be sent to rsync, even when it's not started interactively.
Comment 5 Wayne Davison 2020-07-26 07:26:24 UTC
There's no good way to implement something like that in the current rsync.
Comment 6 Joachim Wagner 2022-03-04 10:34:39 UTC
The "echo > sourcefile" workaround seems to not trigger an error, at least not straight away and at least on XFS, but instead speeds up the operation and stops writing more data to the target file. Observation (both source and target filesystems are local, 5.7 TB file at 68% at time of intervention):

* Before "echo > sourcefile", rsync -P reported about 200MB/s
* After "echo > sourcefile", rsync -P reports about 650MB/s and the target file's mtime and size no longer change
* At 100%, rsync says "read errors mapping "redacted": No data available (61)
WARNING: redacted failed verification -- update discarded (will try again)." and then syncs the 1-byte file created with `echo`.

Still grateful @martin for sharing the idea. I found this searching for a way to inject an I/O error.

For the source file backup, `cp --reflink=always` is your friend.