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?
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?
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?
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?
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?
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/
/dev/mem: permission denied
I just compiled dmidecode[1] with the latest stable version of cygwin. The binary[2] works fine on XP, but on Windows 2003, it throws a permission denied error on accessing /dev/mem. I searched the Cygwin list and found this message[3]: Accessing \device\physicalmemory from privileged user mode processes works only on NT4, W2K and XP. Starting with 2K3, access to physical memory has been restricted to work only in kernel mode. On the other hand, a patched version of dmidecode (not needing Cygwin DLL)[4] works just fine on Windows 2003. Is there a workaround for /dev/mem: permission denied problem in Cygwin? [1] http://www.nongnu.org/dmidecode/ [2] http://wpkg.org/Download [3] http://www.cygwin.com/ml/cygwin/2007-04/msg00458.html [4] http://www.breakoutbox.de/software/software.html -- Tomasz Chmielewski -- 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?
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?
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/
using rsync with Win32/UNC pathnames?
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. However, this doesn't seem to work with rsync. rsync will fail when sing Win32-style paths (it tries to connect via SSH): $ rsync -v C:\1 C:\2 The source and destination cannot be both remote. rsync error: syntax or usage eror (code 1) at /home/lapo/packaging/tmp/rsync-2.6.9/main.c(1068) [receiver=2.6.9] It works fine with cygwin paths: $ rsync -v /cygdrive/c/1 /cygdrive/c/2 1 sent 150 bytes received 42 bytes 384.00 bytes/sec total size is 68 speedup is 0.35 Why does it fail with Win32-paths? Is is possible to use rsync.exe with Win32 and/or UNC paths? -- 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 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?
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/
using Windows backup API?
Traditionally, in UNIX, a root user can access any file in the system without doing anything special. This contrasts with Windows, where even Administrator user can't read files for which he has not access permissions (i.e., a file with all permissions removed)[1]. To access such files in Windows, one needs to use a special Backup API. However, ported UNIX tools, like rsync, are not aware of this API (and I doubt they ever will) - this results in that they can't access certain files, even if the tool is started by the Administrator user: C:\rsyncd\rsync.exe 1.txt copy.txt rsync: send_files failed to open /cygdrive/c/test/1.txt: Permission denied (13) Is it somehow possible to use this Windows Backup API transparently for applications using Cygwin dll? [1] This is something else as files opened exclusively, like Windows registry files, which can be accessed by using shadow copy -- 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 Windows backup API?
Corinna Vinschen schrieb: On Mar 31 11:37, Tomasz Chmielewski wrote: Traditionally, in UNIX, a root user can access any file in the system without doing anything special. This contrasts with Windows, where even Administrator user can't read files for which he has not access permissions (i.e., a file with all permissions removed)[1]. To access such files in Windows, one needs to use a special Backup API. The backup API is not really necessary to access such files. It's enough to enable the SE_BACKUP_NAME privilege and to use the FILE_OPEN_FOR_BACKUP_INTENT flag in file and directory open calls. This is partly already done in the current Cygwin release, but it will only be done consequently in the next major release 1.7.0. No, we don't have a release date yet. Is there a release date yet? ;) Feel free to test the latest Cygwin snapshots from http://cygwin.com/snapshots/ Cool, it works! That's great! When you write it's partly done, are there any bits and pieces still missing in this 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/
cygwin1.dll with UTF8 support
I just wanted to let you guys know that there is a patched, UTF8-aware cygwin1.dll. It can be downloaded from this page: http://www.okisoft.co.jp/esc/utf8-cygwin/download.html The page is in Japanese (anyone can translate?), you will find the links at the top of this page (some sources and a binary dll). I didn't test it much, but it works after a couple of simple tests - I needed UTF8 support in rsync. With a standard cygwin1.dll you will not be able to copy filenames with UTF8 characters from Windows machine to Linux machine with rsync (you will get ??? characters instead). -- Tomasz Chmielewski Software deployment with Samba 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/
UTF8 problem with rsync
I want to use rsync to backup files from a Windows server to a Linux server. rsync is running as a daemon on a Windows side. Copying files work fine, but unfortunately, any filename that contains non-standard characters (like German umlauts - Ü, Ö, Ä etc.) is converted into ?. This is the same as if I mounted a Windows share on a Linux server without specifying iocharset=utf8 option. Is there any solution for this? I saw some reference on the list in a post one year ago, but no solution. -- Tomasz Chmielewski Software deployment with Samba 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/
UTF8 problem with rsync
I want to use rsync to backup files from a Windows server to a Linux server. rsync is running as a daemon on a Windows side. Copying files work fine, but unfortunately, any filename that contains non-standard characters (like German umlauts - Ü, Ö, Ä etc.) is converted into ?. This is the same as if I mounted a Windows share on a Linux server without specifying iocharset=utf8 option. Is there any solution for this? I saw some reference on the list in a post one year ago, but no solution. -- Tomasz Chmielewski Software deployment with Samba 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: encoding scripts (so that user can't see passwords easily)?
Svend Sorensen schrieb: On 12/4/05, nidhog [EMAIL PROTECTED] wrote: On 12/4/05, Christopher Faylor [EMAIL PROTECTED] wrote: On Sun, Dec 04, 2005 at 12:20:57PM +0100, Tomasz Chmielewski wrote: I have a little open-source project, which eases Windows administration a bit. In some of the scripts, I use usernames and passwords (to get to a password-protected network share etc.). Because they are scripts, username and password is in plain. Although the script files are only readable by SYSTEM and Administrators, if a disk is stolen, someone could easily get the passwords by doing simple grep -r password ./*. Do you know some tool which could encode scripts? instead of storing them plaintext, why don't you try encoding them via cryptographic hashes - md5, sha1, tiger and the like. How is the script going to get the plaintext password if all it has is a one way hash? I don't really care, perhaps it won't be any one way hash anyway. It is to be a measure to prevent an accidental viewing of usernames/passwords rather than some military grade tool which takes 100 years to break on a supercomputer. -- Tomek http://wpkg.org WPKG - software deployment and upgrades with Samba -- 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: encoding scripts (so that user can't see passwords easily)?
Wayne Willcox schrieb: On Tue, Dec 06, 2005 at 02:58:15PM -0500, Jim Drash wrote: Don't put the user names or passwords in the script put them in a file only readable by SYSTEM that would not solve the requirement of protecting the passwords if the disk was stolen. The scripts are supposedly already readable by system and admin only. That's exactly what I mean (they are already readable by SYSTEM and admins only). If the disk is stolen, it would add some extra time before the password is compromised. Someone gave a clue here: http://cygwin.com/ml/cygwin/2005-12/msg00181.html instead of storing them plaintext, why don't you try encoding them via cryptographic hashes - md5, sha1, tiger and the like. But I don't really know where to start (which tool should I use for it?) -- Tomek http://wpkg.org WPKG - software deployment and upgrades with Samba -- 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: encoding scripts (so that user can't see passwords easily)?
Jim Drash schrieb: If someone can get physical access to the disk, then there is not a single thing you can do to stop someone who is: 1) Knowledgeable 2) Determined 3) has time 4) is a criminal But I could certainly stop someone who is *not* knowledgeable nor determined, and his criminal cracking gnowledge ends when he presses Enter after typing grep -r password /. Why do you think mail clients, web browsers and other software don't store the passwords in plain? -- Tomek http://wpkg.org WPKG - software deployment and upgrades with Samba -- 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: encoding scripts (so that user can't see passwords easily)?
Christopher Faylor schrieb: On Sun, Dec 04, 2005 at 12:20:57PM +0100, Tomasz Chmielewski wrote: I have a little open-source project, which eases Windows administration a bit. In some of the scripts, I use usernames and passwords (to get to a password-protected network share etc.). Because they are scripts, username and password is in plain. Although the script files are only readable by SYSTEM and Administrators, if a disk is stolen, someone could easily get the passwords by doing simple grep -r password ./*. Do you know some tool which could encode scripts? One of such similar tools is Microsoft Script Encoder, but perhaps it's licensing wouldn't allow me to distribute it along with my files. That's actually how I discovered Cygwin - I had to replace srvany.exe, (which I couldn't distribute), and I found cygrunsrv :) Just to be sure: you do realize that you can't distribute cygrunsrv without also including the sources to cygrunsrv and cygwin1.dll (assuming that you're including that file), right? This is a GPL project. Yeah I know, my project is GPL licensed as well. So, as we know the legal stuff, does anyone have the answer to my question (encoding/encrypting scripts)? -- Tomek http://wpkg.org WPKG - software deployment and upgrades with Samba -- 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/
encoding scripts (so that user can't see passwords easily)?
I have a little open-source project, which eases Windows administration a bit. In some of the scripts, I use usernames and passwords (to get to a password-protected network share etc.). Because they are scripts, username and password is in plain. Although the script files are only readable by SYSTEM and Administrators, if a disk is stolen, someone could easily get the passwords by doing simple grep -r password ./*. Do you know some tool which could encode scripts? One of such similar tools is Microsoft Script Encoder, but perhaps it's licensing wouldn't allow me to distribute it along with my files. That's actually how I discovered Cygwin - I had to replace srvany.exe, (which I couldn't distribute), and I found cygrunsrv :) -- Tomek http://wpkg.org WPKG - software deployment and upgrades with Samba -- 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/
displaying Windows program on Linux via ssh / X?
I couldn't find it on Google and I feel it's a different thing than running Linux X applications (like xterm etc.), which is done by Cygwin/X. Is it possible to display Windows program on Linux via ssh / X? What I mean, normally we do something like that: windows_cygwin$ ssh -l user linuxbox -X linuxbox$ xterm and we start xterm on Linux, but it is displayed by a Windows X server. I want to do something in an opposite direction: start Windows apps on Linux display: linuxbox$ ssh -l user windows_cygwin -X windows_cygwin$ notepad or windows_cygwin$ iexplore.exe And these Windows applications would be displayed on my Linux. Is it possible with Cygwin? -- Tomek -- 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: displaying Windows program on Linux via ssh / X?
Christopher Faylor schrieb: I want to do something in an opposite direction: start Windows apps on Linux display: linuxbox$ ssh -l user windows_cygwin -X windows_cygwin$ notepad or windows_cygwin$ iexplore.exe And these Windows applications would be displayed on my Linux. Is it possible with Cygwin? No. This is not a goal for Cygwin. Too bad, I was hoping to find some alternative to the Terminal Server (or Citrix) - that is, to allow different users to start applications remotely. But it seems I had my head in the clouds :) -- Tomek -- 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: displaying Windows program on Linux via ssh / X?
Michael Uman schrieb:
Hello,
I would recommend looking at VNC server.. If you run VNC server on your
windows box, you can log into it from your Linux VNC client and view
your Windows desktop... This works in both directions {you can run VNC
server on Linux and log into it from Windows}
This is really not an option, as VNC as you said only allows viewing
local desktop, so it's one client only.
I want multi user (much like Terminal Server), without the pockets full
of money for additional connections.
I even did some research, and it is possible to run multi VNC on Windows
(much like on *NIX) - you have to run it from within different Terminal
Sessions (RDP) :))
--
Tomek
--
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: displaying Windows program on Linux via ssh / X?
You are making an assumption that MS Windows was designed as a networked windowing system. It's not. It's not Cygwin's fault nor X windows fault rather it is MS' fault in that their concept of GUI windowed apps is not cleanly divided into the client/server paradigm. No, I don't make any assumption that MS Windows can stream the display in a client/server mode, nor blame Cygwin that it can't do so (if the system doesn't support it). I just hoped there is some way of simulating that behaviour. Terminal Server is not for me, as it incurrs costs for each connection, and VNC is not what I'm looking for, as on Windows it is possible to run it for one user only (unless you run it from within a Terminal Session, which doesn't make sense of course). -- Tomek -- 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/
