this post was submitted on 13 Mar 2024
8 points (100.0% liked)

Linux Questions

1149 readers
3 users here now

Linux questions Rules (in addition of the Lemmy.zip rules)

Tips for giving and receiving help

Any rule violations will result in disciplinary actions

founded 1 year ago
MODERATORS
 

I want to sync retroarch save files across devices on my local network using a bash script. Plan is to run the script as a cronjob to keep all machines synced.

This does the trick as a one-off in the terminal: rsync -a /home/localuser/.config/retroarch/states/ [email protected]:/home/remoteuser/.config/retroarch/states/

  • Copies new save files to remote location
  • Updates any save files which were modified

But when I put the same line in a bash script rsync's behavior changes. My bash script looks like this:

#!/usr/bin/env bash
rsync -a /home/localuser/.config/retroarch/states/ [email protected]:/home/remoteuser/.config/retroarch/states/

I call it with bash sync_saves.sh

  • Copies new save files to remote location
  • ~~Updates any save files which were modified~~

Strangely, rsync doesn't update modified files when run as a script. But it's not failing altogether, because it transfers new files OK. What am I missing?

Update: if I do the rsync in the reverse order (remote machine -> local machine) then the bash script works as expected. So my issue exists only when rsync goes local machine -> remote machine. Why would this matter?


Update 2 (Solution): I changed the command to rsync -razu /home/localuser/.config/retroarch/states/ [email protected]:/home/remoteuser/.config/retroarch/states/, but I'm not sure that made any impact. The issue was how I was doing my testing. I was doing touch testfile.txt to change the modification date on a file & then I'd try to transfer it with the bash script & watch the modification date on the downstream machine as confirmation that it moved correctly. Problem is that rsync must be smart & doesn't transfer a file if only the modification date changes. It requires the contents to also change. Whenever I tested this way I would never see the file transfer, but when I changed my testing method to change the contents of the file instead (not just the modification timestamp) then all worked fine!

I feel like a dummy for initially mixing testing methods & coming to the wrong conclusion about what was happening, but happy it's working now & maybe I learned a lesson!

top 5 comments
sorted by: hot top controversial new old
[–] [email protected] 3 points 8 months ago (1 children)

It's a long shot, but I would compare the output of 'which rsync' on the shell and within the script.

If you're running the exact same command, there's a good chance this is due to some difference between your live shell profile and the shell profile the script runs under.

One possible difference is that the shell is finding a substantially different version of Rsync, on the path.

[–] [email protected] 2 points 8 months ago

Thanks for the idea! I tried this but both versions of which rsync pointed to the same location.

I think I've figured out my issue. I'll put the solution in the original post.

[–] [email protected] 2 points 8 months ago (1 children)

If you change to -av you might get a clue from the script output.

[–] [email protected] 1 points 8 months ago (1 children)

This gives you output in the terminal when running bash rsynccommand.sh:
rsync -avu --progress --stats ~/source/ ~/dest/ || exit 1

the u means that the file that is newest will be kept. Could be useful if you don't want to accidently overwrite a newer save.

[–] [email protected] 2 points 8 months ago* (last edited 8 months ago)

Thanks! I made a change similar to that and it might have helped. In any case, I think my issue is fixed. I'll post the fix in the original post.