Bug 8471 - The file of DBCS file name contains DBCS second byte of x'5C' cause error.
Summary: The file of DBCS file name contains DBCS second byte of x'5C' cause error.
Status: RESOLVED INVALID
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.8
Hardware: x86 Windows 7
: P5 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-20 14:11 UTC by sakai.takeshi
Modified: 2011-09-23 01:29 UTC (History)
0 users

See Also:


Attachments
see description section (270.85 KB, application/zip)
2011-09-20 14:11 UTC, sakai.takeshi
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description sakai.takeshi 2011-09-20 14:11:20 UTC
Created attachment 6918 [details]
see description section

1) calling parameter is;
   rsync -a /cygdrive/d/tst/ /cygdrive/z/tst/
      where; d:\tst\DBCSDBCS.pdf 
             z:\tst\   <= on samba of Fedora 15(latest update by yumex)

2) test bed is;
   Windows 7 Ultimate Japanese version 32 bit.
   rsync is 3.0.8, suppose latest.

3) The error msg is;
   rsync: mkstemp "/cygdrive/z/tst/DBCSDBCS.pdf.JImXNd"  failed: No such file or directory (2)

4) as above mentioned, the problem causes only the case of destination is samba of Linux, Windows destination case, no error happened.

5) The file name of DBCS contains x'5C' or '/' in second byte of DBCS, the error causes only this case.

6) attached file contains;
  a) DBCS files(two files of SBCS file name, dbcs-files.zip).
  b) above two file list(dbcsfile.dir)
  c) hex dump of dbcsfile.txt(hexdump.txt)
  d) test result screen shot.(screen-shot.pdf)
  e) test script(rsytst.bat)
  
Hope find the bug quickly and fix it.

Thank you very much in advance.

Takeshi Sakai from Fujisawa Japan
Comment 1 sakai.takeshi 2011-09-21 02:00:30 UTC
Wayne, I performed further investigation this problem, found following;

1) Windows Copy command for the same file completed successfully, to samba server.  samba info is below;
     [root@localhost monte]# smbclient -U samba -L localhost
     Enter samba's password: 
     Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.5.11-71.fc15]
	Sharename       Type      Comment
	---------       ----      -------
	samba           Disk      share folder of leo server
	monchan         Disk      monchan's smb home
	monte           Disk      
	IPC$            IPC       IPC Service (Samba Server Version 3.5.11-71.fc15)
     Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.5.11-71.fc15]
	Server               Comment
	---------            -------
	LEOSVR               Samba Server Version 3.5.11-71.fc15
	Workgroup            Master
	---------            -------
	WORKGROUP            LEOSVR
     [root@localhost monte]# 

2) From above condition, the problem source may be samba side, if so shall I submit new bug file to samba ? And close this file ? Any how the bug detected on rsync side, so I filed to rsync, is this correct ?

3) Originally I dug this bug with my NAS, sold by buffalo corp., I bought it about 5 years ago, it seems using some linux, not known the kind of linux, version of linux and the version of samba, the NAS name is tera-station(TS-TGLB15), with this NAS, even the file copying by windows command also causes file not found error, where the file is used same with rsync operation. Then I began the investigation with latest rsync and samba. 

I give up for older version correction, though would like to fix on latest version.

That's all my thought at this moment.

Takeshi Sakai
Comment 2 Wayne Davison 2011-09-22 16:51:55 UTC
If a filename contains a 0x5C (/) character, then that character will be treated as a path delimiter.  The error you're seeing looks to be causued by the missing directories in what is taken to be a pathname (though rsync doesn't know to create those directories, since the slashes got returned in a filename).

What character encoding do you use?  Rsync can really only handle ones that are single-character compatible, like UTF-8 (where any multi-byte characters are all high-bit bytes that can't conflict with normal characters).  You may be able to set something in cygwin so that the filesystem calls return UTF-8 data to rsync (at a guess).  If that is possible, rsync should work fine with that.
Comment 3 Wayne Davison 2011-09-22 16:59:01 UTC
Sorry, I should have double-checked your hex vs char statement.  Slash is 0x2F (/), whereas backslash is 0x5C (\).  I'm not sure why the presence of a backslash would cause an issue unless something in the cygwin and/or samba code has an issue with it.

One theory is that the cygwin interaction with samba doesn't have the right character encoding configured, so it is interpreting the backslash as a path delimiter.  If so, you might be able to make use of the --iconv option to change the destination encoding to something like UTF-8 and see if that helps.  You should also check into configuring cygwin to see if there is a way to tell it about the character encoding that you are using.
Comment 4 sakai.takeshi 2011-09-22 22:23:23 UTC
Thanks Wayne for taking time for this matter, I confused NAS and Fedora samba server, surely NAS has problem, but Fedora samba works fine.
In case of target is NAS, even --iconv=UTF-8 is included, same error happens.

So pls close this problem file as latest Rsync does not have any problem against latest version of destination file system.

Again thank you for taking your time.

Takeshi Sakai
Comment 5 Wayne Davison 2011-09-23 01:29:34 UTC
Closing, as requested.