Description of problem: If you view (ls) file with a '%' in its name (.gconf subdirectories have lots of these) on a shared folder in VMware (hgfs), the '%' gets replaced by '%25'. This breaks the operation of "rsync". This appears to be similar to URL encoding. The host was Fedora 11 (x86_64), and the guest was Fedora 7 (i386). Version-Release number of selected component (if applicable): VMWare 6.5.2 How reproducible: Perfectly. Steps to Reproduce: 1. Setup a shared folder in your guest computer. 2. Create a file in the guest called '%test'. 3. cp '%test' /mnt/hgfs/yourfolder 4. ls -l /mnt/hgfs/yourfolder 5. rsync -av --delete . /mnt/hgfs/yourfolder Actual results: At step 4, you can see the name as '%25test' instead of '%test'. At step 5, rsync doesn't think the file is there, so it deletes it and then copies it again. Expected results: File names should not be mangled. Additional info:
Uhmm why would this be an rsync bug ?
Hi, It might not be. However, it seems both 'ls' and 'rsync' are getting confused about the file name. As a result, rsync is believing the file does not exist, when, in fact, it does exist. Here's another test to be more convincing... $ mkdir x [russellr@cabsav ~]$ cd x [russellr@cabsav x]$ > '%test' [russellr@cabsav x]$ cp '%test' /mnt/hgfs/Temp [russellr@cabsav x]$ ls -l /mnt/hgfs/Temp total 0 -rw-rw-r-- 1 russellr russellr 0 2009-07-04 17:08 %25test # copied OK but ls reports incorrect file name [russellr@cabsav x]$ cp -i '%test' /mnt/hgfs/Temp cp: overwrite `/mnt/hgfs/Temp/%test'? y # cp knows the correct name [russellr@cabsav x]$ rsync -av --delete . /mnt/hgfs/Temp building file list ... done deleting %25test ./ %test # if rsync knew the correct name it wouldn't be trying to delete it first Hope that helps.
This is clearly a hgfs bug, contact your vendor.
Hi, Can you explain why "cp" doesn't have a problem but "rsync" does? If it was a generic problem in hgfs, surely every program would be affected.
cp copies files. it doesn't do a synchronization. If a filesystem changes the name of files it is basically broken from the point of view of rsync. Rsync has no way to know %test is the same as %25test. Finally rsync deletes the file because you passed the --delete option and no file name %25test exists in the original folder. Please don't reopen this bug.