Re: using rsync with Win32/UNC pathnames?
I am using a software called *Long Path Tool* for such errors and it is working like charm, i have no problems in copying, Win32/UNC pathnames or extracting anything anywhere. -- View this message in context: http://cygwin.1069669.n5.nabble.com/using-rsync-with-Win32-UNC-pathnames-tp34501p121625.html Sent from the Cygwin list mailing list archive at Nabble.com. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: using rsync with Win32/UNC pathnames?
On Apr 12 13:15, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: What's the wchar hex code value of that character? Hmm, I don't know. Is there some obvious way to get it? You could write a small application which does nothing but calling FindFirstFileW/FindNextFileW and print the found file names as hex values. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On Apr 14 11:30, Tomasz Chmielewski wrote:
Corinna Vinschen schrieb:
On Apr 12 13:15, Tomasz Chmielewski wrote:
Corinna Vinschen schrieb:
What's the wchar hex code value of that character?
Hmm, I don't know.
Is there some obvious way to get it?
You could write a small application which does nothing but calling
FindFirstFileW/FindNextFileW and print the found file names as hex
values.
...which sounds much more complicated than just copying the file to another
machine.
I don't do remote debugging. If you want this fixed, find a method to
provide the file as zip attachment to this mailing list. Or, cd to the
directory in which the file is stored and run the below application. It
builds OOTB if you have gcc installed. Just call `gcc -o foo foo.c'.
foo.c ==
#include windows.h
#include stdio.h
int
main()
{
WIN32_FIND_DATAW data;
HANDLE h = FindFirstFileW (L.\\*, data);
if (h != INVALID_HANDLE_VALUE)
do
{
char buf[512];
BOOL used;
PWCHAR w;
int ret = WideCharToMultiByte (GetACP (), 0, data.cFileName, -1,
buf, 512, NULL, used);
if (!ret)
printf (not converted: );
else
printf (%s (%d): , buf, used);
for (w = data.cFileName; *w; ++w)
printf (%04x , *w);
puts ();
}
while (FindNextFileW (h, data));
return 0;
}
foo.c ==
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: On Apr 12 13:15, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: What's the wchar hex code value of that character? Hmm, I don't know. Is there some obvious way to get it? You could write a small application which does nothing but calling FindFirstFileW/FindNextFileW and print the found file names as hex values. ...which sounds much more complicated than just copying the file to another machine. Well. But I'm just an occasional Cygwin user, not a Cygwin programmer, so my perspective is perhaps different. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: On Apr 14 11:30, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: On Apr 12 13:15, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: What's the wchar hex code value of that character? Hmm, I don't know. Is there some obvious way to get it? You could write a small application which does nothing but calling FindFirstFileW/FindNextFileW and print the found file names as hex values. ...which sounds much more complicated than just copying the file to another machine. I don't do remote debugging. If you want this fixed, find a method to provide the file as zip attachment to this mailing list. Or, cd to the directory in which the file is stored and run the below application. It builds OOTB if you have gcc installed. Just call `gcc -o foo foo.c'. foo.c == It says (where ? substitutes this strange character): 1?.doc (1): 0031 f021 002e 0064 006f 0063 So that character is f021. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On Apr 14 13:15, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: On Apr 14 11:30, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: On Apr 12 13:15, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: What's the wchar hex code value of that character? Hmm, I don't know. Is there some obvious way to get it? You could write a small application which does nothing but calling FindFirstFileW/FindNextFileW and print the found file names as hex values. ...which sounds much more complicated than just copying the file to another machine. I don't do remote debugging. If you want this fixed, find a method to provide the file as zip attachment to this mailing list. Or, cd to the directory in which the file is stored and run the below application. It builds OOTB if you have gcc installed. Just call `gcc -o foo foo.c'. foo.c == It says (where ? substitutes this strange character): 1?.doc (1): 0031 f021 002e 0064 006f 0063 So that character is f021. I should have thought about that from the beginning. Well, there's no workaround and there will be no patch for this. The problem is that this character value is within the 0xf000-0xf0ff range. This range is part of the UNICODE block 95, Private Use Area. There is by definition no valid UNICODE character assigned within this area and Cygwin reserves the right to use this 0xf000-0xf0ff for its own purposes. Besides, I have a hard time to imagine how a user could create a filename with this value except wantonly. The range from 0xf000-0xf0ff is used by Cygwin 1.7.0 to map special characters which are disallowed in DOS filenames. You can use every other UNICODE character in Cygwin, except for these values. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: (...) So that character is f021. I should have thought about that from the beginning. Well, there's no workaround and there will be no patch for this. The problem is that this character value is within the 0xf000-0xf0ff range. This range is part of the UNICODE block 95, Private Use Area. There is by definition no valid UNICODE character assigned within this area and Cygwin reserves the right to use this 0xf000-0xf0ff for its own purposes. Besides, I have a hard time to imagine how a user could create a filename with this value except wantonly. The range from 0xf000-0xf0ff is used by Cygwin 1.7.0 to map special characters which are disallowed in DOS filenames. You can use every other UNICODE character in Cygwin, except for these values. I see. Thanks a lot for your support. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On Apr 11 19:06, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: On Apr 11 18:04, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: utf-8 is supposed to be able to convert all wide chars to a multibyte sequence. If it's *not* the above server-side problem, we would need a simple, self-contained, reproducible testcase, preferrably in plain C. Is a file in an archive enough? It looks like it looses the special character in tar or zip, but 7zip can store it just fine. What 7zip? Native or Cygwin? I used native 7zip to store the file and copy it to another machine. It is also possible to copy such a file to another machine using Windows Neighbourhood. Given that a Cygwin 7zip would probably change the results, could you please provide the file in a format which doesn't force me to download another piece of software? Like, for instance, zip? Better: Create a shell script which creates the file which makes trouble and send the script. I've no idea how to create a file with such name. I'm doing backups with rsync (sort of) and I was checking which files are not copied - this was one of user files. Shortcut: Tell me what the actual filename is. I can switch to the german keyboard layout if necessary. And what's the actual filename? As a start and as long as there's only one file in the test dir, you could also send the strace output of `ls test' as attachment to this list. This might help already. I didn't even think of debugging this. You can find a ls -l strace on http://wpkg.org/ls.strace.txt I asked for an attachment but, well... The strace doesn't help, unfortunately. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On Apr 11 20:47, Charles Wilson wrote: Tomasz Chmielewski wrote: If you want, download http://wpkg.org/test.7z You will need 7zip to extract it (or something compatible). Such as the cygwin p7zip program, or the native programs distributed by the upstream 7zip project (google...) However, be warning: 7zip -- and the 7zip format -- contain NO provisions for storing unix style permissions, unix style ACLs, nor Windows/NTFS style ACLs. Therefore, if Corinna 'unpacks' you test file, she will NOT necessarily be testing your exact scenario. So, you need to use a tool that cares for such things (the exact tool will depend on the OS (and cygwin, if OS=win) for your server, and for your client. I point this out, because it may not be a UTF filename encoding problem at all. You just might not have the appropriate permissions to access the (remote, local) files. If he's running under and admin account, that would not be a problem because of the backup privilege mystery :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Charles Wilson schrieb: Tomasz Chmielewski wrote: If you want, download http://wpkg.org/test.7z You will need 7zip to extract it (or something compatible). Such as the cygwin p7zip program, or the native programs distributed by the upstream 7zip project (google...) However, be warning: 7zip -- and the 7zip format -- contain NO provisions for storing unix style permissions, unix style ACLs, nor Windows/NTFS style ACLs. Therefore, if Corinna 'unpacks' you test file, she will NOT necessarily be testing your exact scenario. So, you need to use a tool that cares for such things (the exact tool will depend on the OS (and cygwin, if OS=win) for your server, and for your client. As I've already written, I used 7zip to archive it and copy it to another machine and the name was intact - Cygwin programs on that another machine had the same problems accessing the file. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: On Apr 11 19:06, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: On Apr 11 18:04, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: utf-8 is supposed to be able to convert all wide chars to a multibyte sequence. If it's *not* the above server-side problem, we would need a simple, self-contained, reproducible testcase, preferrably in plain C. Is a file in an archive enough? It looks like it looses the special character in tar or zip, but 7zip can store it just fine. What 7zip? Native or Cygwin? I used native 7zip to store the file and copy it to another machine. It is also possible to copy such a file to another machine using Windows Neighbourhood. Given that a Cygwin 7zip would probably change the results, could you please provide the file in a format which doesn't force me to download another piece of software? Like, for instance, zip? As I said, zip doesn't want to store this file (at least the version I have installed). And tar changes the strange character into _. Cygwin's p7zip will probably not restore this file as well as all Cygwin's programs have problems reading such a file - so Iguess they will have problems to create it as well. If you know a program which is able to store the file properly - fine, I can use it. I just don't know what program would that be. Better: Create a shell script which creates the file which makes trouble and send the script. I've no idea how to create a file with such name. I'm doing backups with rsync (sort of) and I was checking which files are not copied - this was one of user files. Shortcut: Tell me what the actual filename is. I can switch to the german keyboard layout if necessary. And what's the actual filename? The actual filename is: 1some_strange_character.doc But I guess it doesn't help much. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On Apr 12 12:02, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: And what's the actual filename? The actual filename is: 1some_strange_character.doc But I guess it doesn't help much. What's the wchar hex code value of that character? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: On Apr 12 12:02, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: And what's the actual filename? The actual filename is: 1some_strange_character.doc But I guess it doesn't help much. What's the wchar hex code value of that character? Hmm, I don't know. Is there some obvious way to get it? Alternatively, it is possible to copy the file using Network Neighbourhood (\\machine\share) - at least it works for me. So if you want, I can set up a remote share over internet for you? -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: On Apr 3 13:10, Brian Dessent wrote: Tomasz Chmielewski wrote: So once Cygwin learns how to speak UTF-8, I will finally be able to backup all Windows files... :) Set CYGWIN=codepage:utf8 to enable UTF-8 support. ...and set LC_CTYPE=C-UTF-8, otherwise multibyte/wide char aware application don't convert UTF-8 strings correctly from multibyte to wide char and vice versa. Although it helped greatly, I'm still unable to open some files with Cygwin apps. Windows tools have no problems accessing them. Some Windows tools say for example this directory contains file names from a different code page (i.e., Total Commander will say this when entering a directory which contains such a file). Is there a setting which will enable Cygwin apps to open all files, irrespective of their name encoding? -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On Apr 11 14:26, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: On Apr 3 13:10, Brian Dessent wrote: Tomasz Chmielewski wrote: So once Cygwin learns how to speak UTF-8, I will finally be able to backup all Windows files... :) Set CYGWIN=codepage:utf8 to enable UTF-8 support. ...and set LC_CTYPE=C-UTF-8, otherwise multibyte/wide char aware application don't convert UTF-8 strings correctly from multibyte to wide char and vice versa. Although it helped greatly, I'm still unable to open some files with Cygwin apps. One reason could be that you're accessing a remote samba share which has filenames with characters which are invalid utf-8 chars. In this case there's nothing Cygwin can do. You will have to fix that on the server side. Windows tools have no problems accessing them. Some Windows tools say for example this directory contains file names from a different code page (i.e., Total Commander will say this when entering a directory which contains such a file). Is there a setting which will enable Cygwin apps to open all files, irrespective of their name encoding? utf-8 is supposed to be able to convert all wide chars to a multibyte sequence. If it's *not* the above server-side problem, we would need a simple, self-contained, reproducible testcase, preferrably in plain C. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: On Apr 11 14:26, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: On Apr 3 13:10, Brian Dessent wrote: Tomasz Chmielewski wrote: So once Cygwin learns how to speak UTF-8, I will finally be able to backup all Windows files... :) Set CYGWIN=codepage:utf8 to enable UTF-8 support. ...and set LC_CTYPE=C-UTF-8, otherwise multibyte/wide char aware application don't convert UTF-8 strings correctly from multibyte to wide char and vice versa. Although it helped greatly, I'm still unable to open some files with Cygwin apps. One reason could be that you're accessing a remote samba share which has filenames with characters which are invalid utf-8 chars. In this case there's nothing Cygwin can do. You will have to fix that on the server side. I'm accessing the file locally. Windows tools have no problems accessing them. Some Windows tools say for example this directory contains file names from a different code page (i.e., Total Commander will say this when entering a directory which contains such a file). Is there a setting which will enable Cygwin apps to open all files, irrespective of their name encoding? utf-8 is supposed to be able to convert all wide chars to a multibyte sequence. If it's *not* the above server-side problem, we would need a simple, self-contained, reproducible testcase, preferrably in plain C. Is a file in an archive enough? It looks like it looses the special character in tar or zip, but 7zip can store it just fine. If you want, download http://wpkg.org/test.7z You will need 7zip to extract it (or something compatible). The archive contains a test directory and an empty file in it. That filename contains a strange character. Then, try to access this file with any Cygwin program - it won't work. Mind that I use a German language Windows version - if the above doesn't work for you, I can give you remote access if you want. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On Apr 11 18:04, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: utf-8 is supposed to be able to convert all wide chars to a multibyte sequence. If it's *not* the above server-side problem, we would need a simple, self-contained, reproducible testcase, preferrably in plain C. Is a file in an archive enough? It looks like it looses the special character in tar or zip, but 7zip can store it just fine. What 7zip? Native or Cygwin? Better: Create a shell script which creates the file which makes trouble and send the script. Shortcut: Tell me what the actual filename is. I can switch to the german keyboard layout if necessary. Mind that I use a German language Windows version - if the above doesn't work for you, I can give you remote access if you want. Sorry, but, no. I will very certainly not do remote debugging. Btw., why don't you debug this? Strace, gdb, and the sysinternal tools are all free as in beer. As a start and as long as there's only one file in the test dir, you could also send the strace output of `ls test' as attachment to this list. This might help already. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: On Apr 11 18:04, Tomasz Chmielewski wrote: Corinna Vinschen schrieb: utf-8 is supposed to be able to convert all wide chars to a multibyte sequence. If it's *not* the above server-side problem, we would need a simple, self-contained, reproducible testcase, preferrably in plain C. Is a file in an archive enough? It looks like it looses the special character in tar or zip, but 7zip can store it just fine. What 7zip? Native or Cygwin? I used native 7zip to store the file and copy it to another machine. It is also possible to copy such a file to another machine using Windows Neighbourhood. Better: Create a shell script which creates the file which makes trouble and send the script. Shortcut: Tell me what the actual filename is. I can switch to the german keyboard layout if necessary. I've no idea how to create a file with such name. I'm doing backups with rsync (sort of) and I was checking which files are not copied - this was one of user files. Mind that I use a German language Windows version - if the above doesn't work for you, I can give you remote access if you want. Sorry, but, no. I will very certainly not do remote debugging. Btw., why don't you debug this? Strace, gdb, and the sysinternal tools are all free as in beer. As a start and as long as there's only one file in the test dir, you could also send the strace output of `ls test' as attachment to this list. This might help already. I didn't even think of debugging this. You can find a ls -l strace on http://wpkg.org/ls.strace.txt stderr said: ls: cannot access 1!.doc: No such file or directory -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Tomasz Chmielewski wrote: If you want, download http://wpkg.org/test.7z You will need 7zip to extract it (or something compatible). Such as the cygwin p7zip program, or the native programs distributed by the upstream 7zip project (google...) However, be warning: 7zip -- and the 7zip format -- contain NO provisions for storing unix style permissions, unix style ACLs, nor Windows/NTFS style ACLs. Therefore, if Corinna 'unpacks' you test file, she will NOT necessarily be testing your exact scenario. So, you need to use a tool that cares for such things (the exact tool will depend on the OS (and cygwin, if OS=win) for your server, and for your client. I point this out, because it may not be a UTF filename encoding problem at all. You just might not have the appropriate permissions to access the (remote, local) files. So: It looks like it looses the special character in tar or zip, but 7zip can store it just fine. So: use 7zip and keep the encoding -- but lose the permissions. Use tar/zip, and keep the permissions but lose the encodings. Maybe you should post the output, on your (remote?) system, of getfacl -f emptydir getfacl -f file-in-empty-dir -- Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: On Apr 3 13:10, Brian Dessent wrote: Tomasz Chmielewski wrote: So once Cygwin learns how to speak UTF-8, I will finally be able to backup all Windows files... :) Set CYGWIN=codepage:utf8 to enable UTF-8 support. ...and set LC_CTYPE=C-UTF-8, otherwise multibyte/wide char aware application don't convert UTF-8 strings correctly from multibyte to wide char and vice versa. It works, but again, only locally. Is there a way to tell these variables to a cygwin service (i.e., rsyncd started with cygrunsrv?). I tried to set them as a global variable (System - Advanced - Environment variables), started new console, restarted rsyncd service with cygrunsrv, but it doesn't have any effect on rsyncd service - files with UTF-8 characters still fail to transfer (file has vanished). This time, I used rsync 3.0.0 binary on a Linux server, so it's not a problem with an old protocol etc. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Tomasz Chmielewski schrieb: Corinna Vinschen schrieb: On Apr 3 13:10, Brian Dessent wrote: Tomasz Chmielewski wrote: So once Cygwin learns how to speak UTF-8, I will finally be able to backup all Windows files... :) Set CYGWIN=codepage:utf8 to enable UTF-8 support. ...and set LC_CTYPE=C-UTF-8, otherwise multibyte/wide char aware application don't convert UTF-8 strings correctly from multibyte to wide char and vice versa. It works, but again, only locally. Is there a way to tell these variables to a cygwin service (i.e., rsyncd started with cygrunsrv?). I tried to set them as a global variable (System - Advanced - Environment variables), started new console, restarted rsyncd service with cygrunsrv, but it doesn't have any effect on rsyncd service - files with UTF-8 characters still fail to transfer (file has vanished). This time, I used rsync 3.0.0 binary on a Linux server, so it's not a problem with an old protocol etc. Probably the whole Windows machine needs to be restarted if we add new system variables? Even if the service is restarted, it doesn't see new variables. So all services depend on some other process which is already running, it seems. Hm. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On Apr 4 14:13, Tomasz Chmielewski wrote: Tomasz Chmielewski schrieb: Corinna Vinschen schrieb: On Apr 3 13:10, Brian Dessent wrote: Tomasz Chmielewski wrote: So once Cygwin learns how to speak UTF-8, I will finally be able to backup all Windows files... :) Set CYGWIN=codepage:utf8 to enable UTF-8 support. ...and set LC_CTYPE=C-UTF-8, otherwise multibyte/wide char aware application don't convert UTF-8 strings correctly from multibyte to wide char and vice versa. It works, but again, only locally. Is there a way to tell these variables to a cygwin service (i.e., rsyncd started with cygrunsrv?). I tried to set them as a global variable (System - Advanced - Environment variables), started new console, restarted rsyncd service with cygrunsrv, but it doesn't have any effect on rsyncd service - files with UTF-8 characters still fail to transfer (file has vanished). This time, I used rsync 3.0.0 binary on a Linux server, so it's not a problem with an old protocol etc. Probably the whole Windows machine needs to be restarted if we add new system variables? If you change system variables, you have to reboot, because services inherit their variables from the SCM, which only gets restarted when you reboot. However, there is no need for that. Did you try `cygrunsrv --help', or better, read /usr/share/doc/Cygwin/cygrunsrv.README lately? Look for the -e option. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: (...) If you change system variables, you have to reboot, because services inherit their variables from the SCM, which only gets restarted when you reboot. However, there is no need for that. Did you try `cygrunsrv --help', or better, read /usr/share/doc/Cygwin/cygrunsrv.README lately? Look for the -e option. Works perfectly. Thanks a lot! -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
James Abley schrieb: (...) I've just tried the current snapshot and most (all?) of my problems with long path names have gone away, whereas the main release was failing at the start of the month. Previously: 2008/03/07 20:47:05 [13024] rsync: readlink /AppData/Local/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/A pplication Data/Application Data/Application Data/Adobe/Acrobat/8.0/Cache/Search80/08695a9e61055471bbeac6c64c29faa3.idx (in jabley) failed: File name too long (91) But using the current snapshot, rsync (2.6.9) has been fine with the long path names. There are some issues (hey, it's a snapshot!) which I'll report separately, but I'm pretty happy! Hmm, I'm not happy any more. For me, rsync.exe 2.6.9-2 from Cygwin can't read long path names with the latest cygwin1.dll snapshot. cwRsync (3.0.0) however, can read long filenames with the latest cygwin1.dll snapshot. And there is more to it: neither rsync.exe 2.6.9-2 from Cygwin nor cwRsync (3.0.0) can read long path names when rsync is started as a Windows service (cygrunsrv 1.34-1). Ideas why? -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Tomasz Chmielewski schrieb: James Abley schrieb: (...) I've just tried the current snapshot and most (all?) of my problems with long path names have gone away, whereas the main release was failing at the start of the month. Previously: 2008/03/07 20:47:05 [13024] rsync: readlink /AppData/Local/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/A pplication Data/Application Data/Application Data/Adobe/Acrobat/8.0/Cache/Search80/08695a9e61055471bbeac6c64c29faa3.idx (in jabley) failed: File name too long (91) But using the current snapshot, rsync (2.6.9) has been fine with the long path names. There are some issues (hey, it's a snapshot!) which I'll report separately, but I'm pretty happy! Hmm, I'm not happy any more. For me, rsync.exe 2.6.9-2 from Cygwin can't read long path names with the latest cygwin1.dll snapshot. cwRsync (3.0.0) however, can read long filenames with the latest cygwin1.dll snapshot. And there is more to it: neither rsync.exe 2.6.9-2 from Cygwin nor cwRsync (3.0.0) can read long path names when rsync is started as a Windows service (cygrunsrv 1.34-1). False alarm... It will fail i.e. with --protocol=28 (used by BackupPC). It will not fail if protocol is omitted - rsync 3.0.0 uses protocol 30. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Tomasz Chmielewski wrote: So once Cygwin learns how to speak UTF-8, I will finally be able to backup all Windows files... :) Set CYGWIN=codepage:utf8 to enable UTF-8 support. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On Apr 3 13:10, Brian Dessent wrote: Tomasz Chmielewski wrote: So once Cygwin learns how to speak UTF-8, I will finally be able to backup all Windows files... :) Set CYGWIN=codepage:utf8 to enable UTF-8 support. ...and set LC_CTYPE=C-UTF-8, otherwise multibyte/wide char aware application don't convert UTF-8 strings correctly from multibyte to wide char and vice versa. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
James Abley schrieb: (...) I see. Probably a reason why it fails for me. I've just tried the current snapshot and most (all?) of my problems with long path names have gone away, whereas the main release was failing at the start of the month. Previously: 2008/03/07 20:47:05 [13024] rsync: readlink /AppData/Local/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/A pplication Data/Application Data/Application Data/Adobe/Acrobat/8.0/Cache/Search80/08695a9e61055471bbeac6c64c29faa3.idx (in jabley) failed: File name too long (91) But using the current snapshot, rsync (2.6.9) has been fine with the long path names. There are some issues (hey, it's a snapshot!) which I'll report separately, but I'm pretty happy! Indeed - it works just fine if I use rsync.exe from cwRsync (and probably from cygwin, but I didn't try). Previously, I had rsync.exe distributed with BackupPC, and it was failing for long names. Too old perhaps. So once Cygwin learns how to speak UTF-8, I will finally be able to backup all Windows files... :) But at least I'm able to open long path names and files with problematic ACLs, that's a major improvement. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tomasz Chmielewski on 4/1/2008 5:59 AM: | According to http://www.cygwin.com/cygwin-ug-net/using.html: | | Cygwin supports both Win32- and POSIX-style paths, where directory | delimiters may be either forward or back slashes. UNC pathnames | (starting with two slashes and a network name) are also supported. Cygwin1.dll does. But that doesn't mean all cygwin apps do. | It works fine with cygwin paths: | | $ rsync -v /cygdrive/c/1 /cygdrive/c/2 Then use that. POSIX paths are the preferred way to specify files, and if a backslash-path doesn't work, we aren't going to bend over backwards to make it work. | | Why does it fail with Win32-paths? In the case of rsync (and also tar), the program has a special and documented syntax of remote-name:file, so you are asking to find the remote machine named C and the file \1 on that machine, rather than the file 1 on the local drive c. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfyJXIACgkQ84KuGfSFAYDXLgCgzaDfXm0HF/ei/UW6kk9geQoT G6kAnit7zmC9pYZBTJxoAASBx4e29+u8 =bnbG -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Eric Blake schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tomasz Chmielewski on 4/1/2008 5:59 AM: | According to http://www.cygwin.com/cygwin-ug-net/using.html: | | Cygwin supports both Win32- and POSIX-style paths, where directory | delimiters may be either forward or back slashes. UNC pathnames | (starting with two slashes and a network name) are also supported. Cygwin1.dll does. But that doesn't mean all cygwin apps do. | It works fine with cygwin paths: | | $ rsync -v /cygdrive/c/1 /cygdrive/c/2 Then use that. POSIX paths are the preferred way to specify files, and if a backslash-path doesn't work, we aren't going to bend over backwards to make it work. I'd love to, but there are murky places in the Windows world where no one is able to read or write, unless UNC paths are used [1]. In Windows, path can have only up to 260 characters. Generally, it is not possible to create longer pathnames. Why generally? Because sometimes, it is possible to create longer pathnames (i.e., when accessing local files from a remote mount). In this case, a local process won't be able to access a file called: C:\path\longer\than\260\characters For such cases, one has to use UNC pathnames: \\?\C:\path\longer\than\260\characters And this is why I can't use /cygdrive/c/path/longer/than/260/characters, because it expands to Win32-style path (which has a 260 character limitation) rather than to UNC-style path. In other words: rsync will be unable to backup certain user files. | | Why does it fail with Win32-paths? In the case of rsync (and also tar), the program has a special and documented syntax of remote-name:file, so you are asking to find the remote machine named C and the file \1 on that machine, rather than the file 1 on the local drive c. That's really bad. Any ideas how to work this around? [1] http://msdn2.microsoft.com/en-us/library/aa365247.aspx -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tomasz Chmielewski on 4/1/2008 6:15 AM: | In Windows, path can have only up to 260 characters. In Windows, the ASCII functions can only handle up to 260 characters. But the Unicode functions handle more. You may be interested in trying a snapshot, where longer filenames are (mostly) supported, and in particular, your use case of rsync with names longer than 260 characters should work using POSIX-style paths. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfyKb0ACgkQ84KuGfSFAYAqswCcCTw+FcYwZxe8mmOuo4ZRu/C6 +bUAn3/2uDynItPLi39I2zxkkm3f+tqF =I1tW -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tomasz Chmielewski on 4/1/2008 6:34 AM: | Nope, they are not supported in snapshots; drive snapshots are nothing | different than a normal drive (I assume you're talking about VSS / | shadow copy snapshots for the whole drive, i.e. snapshot C:, it appears | as read-only V:?). Nope. I'm talking about cygwin snapshots: http://cygwin.com/snapshots/ http://cygwin.com/faq/faq-nochunks.html#faq.setup.snapshots - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkfyLfUACgkQ84KuGfSFAYBjcQCgyEppiQ+aczj4t4hiKOJ1ZIO8 VW0An0wEaCdHLN9sXc74Ayp6xNUv7bOU =cEjI -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On Apr 1 06:43, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tomasz Chmielewski on 4/1/2008 6:34 AM: | Nope, they are not supported in snapshots; drive snapshots are nothing | different than a normal drive (I assume you're talking about VSS / | shadow copy snapshots for the whole drive, i.e. snapshot C:, it appears | as read-only V:?). Nope. I'm talking about cygwin snapshots: http://cygwin.com/snapshots/ http://cygwin.com/faq/faq-nochunks.html#faq.setup.snapshots That's right, but. generic advice The problem is that long path names are supported by the snapshot Cygwin DLLs, but not necessarily by the applications using it. Since the applications in the Cygwin net distro are still compiled under Cygwin 1.5.x, there's some (hopefully low) probability that applications are using static buffers of size PATH_MAX, which is defined as 260 in 1.5.x. So, right now, there's no guarantee that applications will be able to deal with long path names, unless they have been compiled under a Cygwin snapshot with all new header files installed. /generic advice Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Eric Blake schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tomasz Chmielewski on 4/1/2008 6:34 AM: | Nope, they are not supported in snapshots; drive snapshots are nothing | different than a normal drive (I assume you're talking about VSS / | shadow copy snapshots for the whole drive, i.e. snapshot C:, it appears | as read-only V:?). Nope. I'm talking about cygwin snapshots: http://cygwin.com/snapshots/ http://cygwin.com/faq/faq-nochunks.html#faq.setup.snapshots OK, the development snapshot, not drive snapshot ;) No, it's not different - I'm using it already (cygwin1-20080327.dll - as it allows Administrator users to access files for which they have no permissions - nice feature). -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Corinna Vinschen schrieb: On Apr 1 06:43, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tomasz Chmielewski on 4/1/2008 6:34 AM: | Nope, they are not supported in snapshots; drive snapshots are nothing | different than a normal drive (I assume you're talking about VSS / | shadow copy snapshots for the whole drive, i.e. snapshot C:, it appears | as read-only V:?). Nope. I'm talking about cygwin snapshots: http://cygwin.com/snapshots/ http://cygwin.com/faq/faq-nochunks.html#faq.setup.snapshots That's right, but. generic advice The problem is that long path names are supported by the snapshot Cygwin DLLs, but not necessarily by the applications using it. Since the applications in the Cygwin net distro are still compiled under Cygwin 1.5.x, there's some (hopefully low) probability that applications are using static buffers of size PATH_MAX, which is defined as 260 in 1.5.x. So, right now, there's no guarantee that applications will be able to deal with long path names, unless they have been compiled under a Cygwin snapshot with all new header files installed. /generic advice I see. Probably a reason why it fails for me. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
Eric Blake schrieb: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Tomasz Chmielewski on 4/1/2008 6:15 AM: | In Windows, path can have only up to 260 characters. In Windows, the ASCII functions can only handle up to 260 characters. But the Unicode functions handle more. You may be interested in trying a snapshot, where longer filenames are (mostly) supported, Nope, they are not supported in snapshots; drive snapshots are nothing different than a normal drive (I assume you're talking about VSS / shadow copy snapshots for the whole drive, i.e. snapshot C:, it appears as read-only V:?). and in particular, your use case of rsync with names longer than 260 characters should work using POSIX-style paths. Like /cygdrive/v/some/longish/path/...? Nope, it doesn't work, rsync skips these files and says skipping overly long name. So Cygwin-expanded paths have Win32-limitations; not UNC ones, where longer names are allowed. BTW, what a mess is Windows: several incompatible ways of specifying paths etc. -- Tomasz Chmielewski http://wpkg.org -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: using rsync with Win32/UNC pathnames?
On 01/04/2008, Tomasz Chmielewski [EMAIL PROTECTED] wrote: Corinna Vinschen schrieb: On Apr 1 06:43, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 That's right, but. generic advice The problem is that long path names are supported by the snapshot Cygwin DLLs, but not necessarily by the applications using it. Since the applications in the Cygwin net distro are still compiled under Cygwin 1.5.x, there's some (hopefully low) probability that applications are using static buffers of size PATH_MAX, which is defined as 260 in 1.5.x. So, right now, there's no guarantee that applications will be able to deal with long path names, unless they have been compiled under a Cygwin snapshot with all new header files installed. /generic advice I see. Probably a reason why it fails for me. I've just tried the current snapshot and most (all?) of my problems with long path names have gone away, whereas the main release was failing at the start of the month. Previously: 2008/03/07 20:47:05 [13024] rsync: readlink /AppData/Local/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/Application Data/A pplication Data/Application Data/Application Data/Adobe/Acrobat/8.0/Cache/Search80/08695a9e61055471bbeac6c64c29faa3.idx (in jabley) failed: File name too long (91) But using the current snapshot, rsync (2.6.9) has been fine with the long path names. There are some issues (hey, it's a snapshot!) which I'll report separately, but I'm pretty happy! Cheers, James -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
