The windows filesystems, NTFS in particular, do not support filenames with the following characters:
\/:*?"|
Unfortuantely some unix programs DO use these characters. In my case, it is vpopmail which means the rsync fails with a rename error because of files like ".1109341722.21837.computername,S=2944:2,S.006340". If you try and create this file on windows it won't work because of the colon (:).
It seems like this problem could be solved by escaping the problem characters. of course, is the a cygwin problem or a cwrsync problem?
Hi,
Rsync v2.5.1pre1 is recently released. One of the improvements is about handling filenames with unprintable characters :
---------------
Non-printable chars in filenames are now output using backslash-escaped characters rather than '?'s. Any non-printable character is output using 3 digits of octal (e.g. "\n" -> "\012"), and a backslash
is now output as "\\". Rsync also uses your locale setting, which can make it treat fewer high-bit characters as non-printable.
---------------
I am not sure about it will help to solve your problem, since it is about non-printable characters. I will build up a new cwrsync release when the new version is officially released.
Since cygwin is a linux emulation layer on windows, it should handle this naming problem.
Rgrds Tev
Any information about this problem?I'm trying to rsync Maildir files to windows, but because the files contain the following sequence ":2," they are not valid under windows!
I have the same issue as Carl. I'm trying to back up my Qmail environment to a Windows server using the current version of cwRsync, and it's unable to handle any files with the unsupported characters. Unfortunately, there are quite a few files that meet that criteria.
Any time estimate on an updated version of cwRsync that will resolve this issue?
In the meantime, are there *any* other workarounds possible at this time?
Thank you!
AFAIK, no solution exists yet. If possible, you can make archives containing files with unacceptable chars in their names.
AFAIK, there is no need for additional instructions as the patch is made to work at the receiver side automatically.
I took a test and it seems that transliteration is not available as a daemon option. It can only be used as a client option at the sender side.