Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have several devices (server, tower, notebook, android phone). I want to have my music library in sync on all of them.
So what I thought of was a revision control system that just takes care of CRUD actions (or rather CRD). Maybe it could keep track of the files using their initial name and tracking any renaming or deletion.

All popular software I know (git, svn, cvs, ...) is out of question because they save too much overhead (they diff the binary files).
Streaming doesn't work either for me because I don't always have an internet connection.
Synchronizing the music using tools like unison is very inefficient too because I write metadata to the files so their hashsum, timestamp and size change constantly. If there is a diff or sync tool that ignores minor changes in size and ignores timestamp and permissions and so on, it would maybe be fine but I don't know one.

Any other creative and nifty solutions are welcome.

share|improve this question

You can configure rsync to do things like ignore files that already exist, which will prevent some of the metadata update churn you're worried about. Your concerns about that are probably overblown though. If only a small portion of the file has been changed, only that portion will be updated; the core rsync algorithm will figure out most of it is the same. You'll pay some additional overhead for reading the files along the way, but maybe you could use "--ignore-existing" most of the time, and only do the longer form of sync that tries to sort out all changes less regularly.

I wrote an article called Getting started with rsync, for the paranoid that tries to explain some of the cryptic parts of how it decides what it is going to do. There are a bunch of options here, and the only one you seen to want it doesn't provide is the ability to set a threshold for a large size difference to trigger a different set of rules. That seems to me like it would happen rarely enough that you could just plan one of these longer sync sessions periodically to take care of it.

I also maintain some data like this in git. I'm not sure why you're so concerned about the fact that it stores binary diffs. You should be able to purge old information out of your repo and then compact it periodically if that overhead worries you. git is good at dealing with the renaming problem to keep that from getting too bad: if you just move something from one place to another or change its name, if it's really the same file git will figure that out and not save a new copy of it.

share|improve this answer

Seperate copy,updateing and deleting - use tools that do one thing well - i mean, that is the unix philosophy, right?

I just keep a standardised set of tags and files, and synchronize them with a 'base' set - you could simply use cp -u or other copying tool of your choice - in my case, i have the master file set on a windows system, and just copy the files in place to a USB drive, and use that to sync other copies.

If they go out of date, blow away the original or use rsync or unison only then.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.