Rsync seems to be broken ... occasionally inserting an extra level in the target location path

[pchmt]

I have looked at this thread already ... but I can't find anything else. Is this a bug or am I doing something wrong? I know replication is the recommended way to sync two freeNAS servers, but for reasons which are not relevant that is not applicable to this particular case - at least not initially ...

I have a old freeNAS 9.10.2-U6 system which I am moving to a fresh 11.2-U7 build. When I try to sync the new server to the old server I sometimes get the correct file placements, but I sometimes don't.

For example, if I set the rsync module and push task for
/mnt/old-pool/sourceDirectory

and the target rsync pull module and task as
/mnt/new-pool/NewsourceDirectory

The new install might get it to the correct location, but it is just as likely to end up in (additional path level added in red)
/mnt/new-pool/NewsourceDirectory/NewsourceDirectory
instead of
/mnt/new-pool/NewsourceDirectory

It is also not consistent. It can do it correctly once, then again, then suddenly add the additional path level, but it always and additional name related to the original target path root directory. This occurs whether the sourceDirectory and NewsourceDirectory names are the same or different.

Is this a known bug? Should I go and install U6? Is it a problem syncing from 9.10-U6 (I don't think so as I regularly call an rsync from a WSL script to a local windows drive to back up without any problems)? Am I missing something?

Thank you for any comments or guidance, however small ...

 

[Matt_G]

Are you sure it isn't an occasional trailing backslash getting you?
For instance, when I was using rsync to copy data from FreeNAS to an unRAID box, if I did NOT add a trailing slash at the end of the SOURCE path, it would copy the source directory and it's contents to the unRAID box.
If I just want to copy changed contents to unRAID, I have to make sure there is a trailing slash at the end of the source path.
May not be your issue but it is something to be aware of and watch out for.

 

[pchmt]

That was my first thought, but the problem is not consistent. If I take a specific example ...
Lets assume a specific target path of say /mnt/pool1/BAKups for example set up as a pull/push pair on the source and backup freeNAS installs. Once set up, if it was just a stray config error, the additional inserted path to /mnt/pool1/BAKups/BAKups would be consistent - but its not. I have very carefully checked the paths and they are all exactly of the form I originally noted. The result is that sometimes it introduces the additional level, sometimes it doesn't.

What I have noticed since the original post is that the first run through nearly always delivers the correct target location. Subsequent runs of the same rsync module/task mostly (but not always) insert the additional level, so I end up with the same thing twice at different levels. If I delete the whole BACKup tree back and run it again it sometimes goes to the correct target, sometimes inserts the additional level. Remember, I am talking about the exact same rsync task untouched run multiple times, so it is not a simple stray missing / or some such.

 

[anmnz]

It really does sound like normal rsync behaviour. If you are trying to sync one directory to another, and you leave the trailing slash off both the source and destination directory names, then you'll see apparently "inconsistent" behaviour just like you describe, depending on whether the target directory already exists or not.

The usual answer to this is to put a trailing slash on the end of directory names so that rsync can tell unambiguously what you are asking it to do.

 

[pchmt]

Thanks, I'll try that again, but it didn't seem to want to accept a trailing / before when I tried it. Probably finger trouble. I'll come back if I have further trouble. The advice is much appreciated. Thank you both.

UPDATE: It worked! I also realised why it didn't take the trailing /, I forgot to scroll down to the OK button and just closed the screen ... so it was never 'applied'. Stupid error really. Thanks you again so much.

Now I just need to work out why the new console will only show the 'primary' ethernet interface (em0) and not the one being used (em1). Might just have to swap the two around.