Skip to content

[WIP] Fix rsync hanging issue by adding progress output#37

Merged
djeada merged 2 commits intomasterfrom
copilot/fix-rsync-progress-output
Apr 8, 2026
Merged

[WIP] Fix rsync hanging issue by adding progress output#37
djeada merged 2 commits intomasterfrom
copilot/fix-rsync-progress-output

Conversation

Copy link
Copy Markdown
Contributor

Copilot AI commented Apr 8, 2026

  • Add --info=progress2 to rsync call in backup_mode()
  • Add extra --exclude entries (storage/, thumbnails/, datareporting/, healthreport/, storage.sqlite) to backup_mode() rsync
  • Add informational log message before the for loop in backup_mode()
  • Add --info=progress2 to rsync call in restore_mode()
  • Add informational log message before the while loop in restore_mode()
Original prompt

Problem

When running ./src/firefox_profile_usb.sh backup, the script appears to hang with no output for several minutes while rsync copies a large Firefox profile (e.g. default-release) to a USB drive. The user has no way to tell if the script is working or frozen. The user pressed Ctrl+C after 6 minutes, which killed rsync with exit code 20, and the ERR trap then reported a misleading "Script failed" error.

Two distinct issues:

  1. No rsync progress output — silence during large file transfers looks like a hang.
  2. Too much data copied — large regenerable directories (storage/, thumbnails/, datareporting/, healthreport/, storage.sqlite) are not excluded, inflating transfer time significantly.

File to change

src/firefox_profile_usb.sh

Required changes

1. Add --info=progress2 to both rsync calls

In backup_mode() (around line 449), replace:

rsync -aH --delete \

with:

rsync -aH --delete --info=progress2 \

In restore_mode() (around line 598), replace:

rsync -aH --delete "$src_profile_dir/" "$dest_profile_dir/"

with:

rsync -aH --delete --info=progress2 "$src_profile_dir/" "$dest_profile_dir/"

--info=progress2 prints a single updating line showing bytes transferred, percentage, and transfer rate. It works even when stdout is not a tty (unlike --progress), and doesn't flood logs.

2. Add more --exclude entries to backup_mode() rsync call

Append these excludes to the existing list (after --exclude='minidumps/', before the source path):

--exclude='storage/' \
--exclude='thumbnails/' \
--exclude='datareporting/' \
--exclude='healthreport/' \
--exclude='storage.sqlite' \

Rationale:

  • storage/ — IndexedDB and localStorage; can be hundreds of MB, fully regenerated by Firefox on next run.
  • thumbnails/ — tab thumbnails; regenerated automatically.
  • datareporting/ and healthreport/ — telemetry data; not needed for restore.
  • storage.sqlite — stores quota info for storage/; regenerated with storage/.

These directories are not needed for a functional restore (bookmarks, history, passwords, extensions all live elsewhere) and can save 50–500 MB per profile.

3. Update the usage() function comment to mention that large profiles may take several minutes

No change needed to usage() itself, but add a brief log message in backup_mode() just before the rsync loop starts (after discover_profiles is called and before the for loop):

log "Copying profiles to USB (this may take several minutes for large profiles)..."

And similarly in restore_mode() just before the while loop:

log "Restoring profiles from USB (this may take several minutes for large profiles)..."

Summary of all changes

Location Change
backup_mode() rsync call Add --info=progress2 flag
backup_mode() rsync excludes Add storage/, thumbnails/, datareporting/, healthreport/, storage.sqlite
backup_mode() before loop Add informational log message
restore_mode() rsync call Add --info=progress2 flag
restore_mode() before loop Add informational log message

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: it hangs: chmod u+x src/* && ./src/firefox_profile_usb.sh backup
[09:41:16] Starting Firefox backup...
[09:41:16] Firefox profile directory: /home/adam/.mozilla/firefox
[09:41:16] Checking whether Firefox is fully closed...
[09:41:16] Firefox is closed.
[09:41:16] One USB drive found. Auto-selecting: /media/adam/D28D-C3E1
[09:41:16] Discovered 2 Firefox profile(s).
[09:41:16] Profile 'default': no saved-password store detected
[09:41:16] Profile 'default': integrity checks passed.
[09:41:17] Backing up profile 'default' from /home/adam/.mozilla/firefox/5cz2vuis.default
[09:41:17] Profile 'default': no saved-password store detected
[09:41:17] Profile 'default': integrity checks passed.
[09:41:17] Profile 'default-release': password store present, logins count = 34
[09:41:18] WARNING: Skipping non-critical SQLite file that failed quick_check: /home/adam/.mozilla/firefox/5fqo5qcu.default-release/suggest.sqlite
[09:41:18] Profile 'default-release': integrity checks passed.
[09:41:18] Backing up profile 'default-release' from /home/adam/.mozilla/firefox/5fqo5qcu.default-release
^Crsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(716) [sender=3.2.7]
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(519) [generator=3.2.7]
[09:47:35] ERROR: Script failed near line 449 (exit 20)

Assistant: The script isn't actually hanging — it's copying a large Firefox profile to a USB drive, and that's slow. You interrupted it (Ctrl+C) after ~6 minutes while rsync was transferring the default-release profile (the one with 34 saved passwords and likely gigabytes of browser data including cache2/, history, etc.).

Here's...

This pull request was created from Copilot chat.

@djeada djeada marked this pull request as ready for review April 8, 2026 07:58
@djeada djeada merged commit 48259fd into master Apr 8, 2026
Copilot AI requested a review from djeada April 8, 2026 07:59
Copilot stopped work on behalf of djeada due to an error April 8, 2026 07:59
@djeada djeada deleted the copilot/fix-rsync-progress-output branch April 8, 2026 16:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants