Bug 509463 - vmware hgfs changes some file names and breaks rsync
vmware hgfs changes some file names and breaks rsync
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rsync (Show other bugs)
11
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Simo Sorce
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-02 19:19 EDT by Russell Robinson
Modified: 2009-07-05 22:27 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-05 22:27:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Russell Robinson 2009-07-02 19:19:04 EDT
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:
Comment 1 Simo Sorce 2009-07-02 19:25:03 EDT
Uhmm why would this be an rsync bug ?
Comment 2 Russell Robinson 2009-07-04 03:10:33 EDT
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.
Comment 3 Simo Sorce 2009-07-04 15:54:50 EDT
This is clearly a hgfs bug, contact your vendor.
Comment 4 Russell Robinson 2009-07-05 19:33:01 EDT
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.
Comment 5 Simo Sorce 2009-07-05 22:27:46 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.