Bug 5078 - Unable to use Win32 device paths with --files-from
Summary: Unable to use Win32 device paths with --files-from
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 2.6.9
Hardware: x86 Windows XP
: P3 major (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2007-11-12 08:41 UTC by Greg Bolshaw
Modified: 2011-06-04 16:25 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Greg Bolshaw 2007-11-12 08:41:32 UTC
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)

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)
Comment 1 Wayne Davison 2007-12-15 09:30:08 UTC
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.
Comment 2 Wayne Davison 2011-06-04 16:25:30 UTC
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.