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

Linux Questions

968 readers
10 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 5 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 5 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 5 months ago (1 children)

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

[–] [email protected] 1 points 5 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 5 months ago* (last edited 5 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.