I am using vshadow.exe to create a volume shadow copy of c: which is made available at //?/GLOBALROOT/Device/HarddiskVolumeShadowCopy1. I can then run the following rsync command succesfully: rsync -ae ssh //?/GLOBALROOT/Device/HarddiskVolumeShadowCopy1/SomeFolder/ user@remote.server:Backup Next, I try to implement the same but using --files-from, as follows: rsync -ae ssh --files-from=files.txt //?/GLOBALROOT/Device/HarddiskVolumeShadowCopy1/ user@remote.server:Backup (files.txt contains SomeFolder/) However, this fails with the following error: rsync: push_dir "//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy1/" failed: Not a directory (20) rsync error: errors selecting input/output files, dirs (code 3) at flist.c(1082) [sender=2.6.9] I have also tried without the trailing slash after HarddiskVolumeShadowCopy1 and get a different error: rsync: push_dir "//?/GLOBALROOT/Device/HarddiskVolumeShadowCopy1" failed: Invalid argument (22) rsync error: errors selecting input/output files, dirs (code 3) at flist.c(1082) [sender=2.6.9]
It would appear that the first chdir() to the shadow-copy directory is failing. In the first successful copy, rsync did a chdir() to a subdir of the shadow-copy area, which may be a significant difference to the OS. In any regard, rsync doesn't currently ascribe special meaning to multiple slashes in paths. There are places in the code that will reduce them to a single slash, and that behavior may cause you problems. If that bites you, try to map the shadow-copy directory to a normal path or drive letter some where (one that can be specified using a normal, single-consecutive-slash pathname. I will consider modifying rsync to leave two consecutive slashes at the start of a path that specifies them.
Is this fixed in 3.0.8? There was a bug fix in the chdir code that should have stopped rsync from erroneously trying t chdir to the path with an extra slash at the start.