mp3tofid version 3 uses the major and minor number of the filesystem, and the inode number as a key in the fid number allocation database. So the only way to prevent this from happening is to copy the filesystem rather than the individual files to another disk. AND you need to make sure the copied filesystem will get the same major and minor number.

To get around these limitations, mp3tofid version 4 only uses the major and minor number if the it is different from the mp3 root, otherwise just the inode number. But what really would help you is its ability to rebuild the database from your current collection of tunes and fids, whatever their major/minor/inode numbers are. If the path itself does not change, no rescanning will be necessary, and rsync will not re-upload your tunes.

Looks I really need to release version 4 ... It has been stable for me for quite a while, but I just never got around writing new documentation, and doing a cygwin port (anyone using that?). I also never was under the impression that much people were using mp3tofid at all, until lately.

Apart from a fix for your problem, version 4 will offer
- player v3 support
- support for wav/wma/ogg/flac tunes
- in- and excluding tunes using regular expressions
- marking tunes as "stereo bleed"
- marking directories as "ignore as child"
- lots of bug fixes
- lots of options to control its behaviour

Pim