1

I have a tool that I use during development for syncing the code I am writing on my laptop with my test environment on a remote host. This allows me to quickly test changes without having to git-commit/push/pull/build etc. It is implemented with fswatch and rsync, so it will automatically stream changes I make locally to my remote environment. However, I have a problem because sometimes I forget to turn this tool on and then I waste more time than I should figuring out why my code is not working.

  1. Is there a programatic way on my remote host to detect that any files have recently (say, in the last minute) been rsync'd to it?
  2. Furthermore, is it possible to tell that my tool is the one doing the rsync-ing? It is unlikely that any other hosts would be syncing to my remote since I own it, but the more robust the better :)

My end goal is to make a small daemon on the remote host that would do something innocuous like change the prompt color when my file syncing is working.

  • Sidebar but related comment: I'm assuming your fswatch and rsync based tool is run on your local workstation. perhaps you can set your CLI prompt to indicate wether your tool is running or not. You can set your prompt to ps -elf | grep your_tool_name_here and set an indicator if the tool is running. I do something similar with my bash prompt to let me know which chef environment I'm working in. I use the git_prompt framework. – Michael J Jan 30 '17 at 23:56

3 Answers3

0

One solution could be to have your tool echo the current date/time to a file on the remote machine after it's finished rsync'ing the data. Then on the remote machine, all that needs to be done is to check the file to determine the last time data was synced to it.

If you're using linux you can detect filesystem changes with the inotify api that's built into the kernel. With inotify you can detect which files have been written to and take an action based on whatever event occurred. (open, close, read, write, delete, move, etc.)

Hydranix
  • 211
  • This is a good idea. The tool is owned by a friend of mine so I would have to fork it, but this solution has the benefit of being specific to my code and not the entire remote computer. – SegFaults McGee Jan 30 '17 at 23:56
0

You could put a watch on the remote system (with fswatch, inotify, loggedfs or whatever interface you prefer) and have it detect writes to the test directory. That would at least let you know of recent modifications. Not all of these mechanisms can identify which process caused them, for example loggedfs can but inotify can't.

There's still the issue of remembering to turn on the watch. You can make this moot by making your start-testing-now script turn on the watch, and do a sync first if the watch hadn't been started yet.

But it seems to me that the simplest solution in this scenario would be to not synchronize at all. Instead, mount your local tree to the test machine with SSHFS.

See How can I configure a reverse SSH connection to the connecting computer? for how to initiate SSH connections from the remote machine back to your local machine.

  • Thanks for the response. I've thought about using a remote filesystem but this is mostly just a personal project. Somehow I thought of using fswatch on my local machine but not on my remote machine, I might just take that suggestion and run with it – SegFaults McGee Jan 30 '17 at 23:54
0

I have come up with a solution that works. The solution is to measure the size of the file periodically and copy the file to itself if it has changed. I have a bash script that proves the concept but it needs to be expanded to measure the whole folder and subs and if the folder size has changed find the files that have changed and copy those individual files into themselves. Hopefully have a top level .ignore file too. If you improve on this please share it. We need a complete script. Here is my simple script:

while [ 1 ]; do
    x=$(du -b .)
    sleep 3
    y=$(du -b .)
    if [ ! "$x" = "$y" ]; then
        cp App.js x
        cp x App.js
    fi
done
terdon
  • 242,166