RE: Incorrect names for file owners on mapped samba drives

> . Hi Larry, Thanks for the heads up about PCYMTNQREAIYR, I'll configure my Mailer/Client as soon as I can get the IT guys to do it, or figure out how to change my Outlook 2007 preferences. I've established that the differences in the output of -l

Re: Parallel downloading of Cygwin packages

Hi Chris, Chris Cormie schreef: Christopher Faylor wrote: On Fri, Oct 30, 2009 at 01:19:58PM +0100, Ron de Bruijn wrote: I use the latest installer, but it only uses one mirror to download packages from at the same time. I have the impression that the mirror I selected only gives about 30KB/s

Re: SOLVED: Removed 1.5.25 and installed 1.7.0, but still cannot access filenames containing Unicode

On Oct 31 20:33, Andy Koppe wrote: > >> You must not use characters > >> in this range from U+f000 up to U+f0ff.  There's no solution to this > >> except for "don't use these characters in filenames if they are not > >> explicitely written there by either Cygwin or Microsoft's SUA". > > Actually t

Re: mkdir differences between 1.5.25 and 1.7

On Oct 29 14:33, Egerton, Jim wrote: > Test program: > $ cat x.cc > #include > #include > > int main(int argc, char *argv[]) { >mkdir("/tmp/foo", 0777); > } > > $ ls -ld /tmp/foo > ls: cannot access /tmp/foo: No such file or directory > > $ ./x > > $ ls -ld /tmp/foo > drwxr-xr-x 1 root Ad

Re: Incorrect names for file owners on mapped samba drives

On Nov 2 09:21, John Daintree wrote: > I've established that the differences in the output of -ls -l on the > different drives is down to differences in acl/noacl. > > $ mount > //devt/devt on /u type smbfs (binary,notexec,noacl,posix=0,user) > U: on /cygdrive/u type smbfs (binary,posix=0,user,

Re: Binary distribution and DLLs

On Oct 31 15:08, Jon Beniston wrote: > Hi, > > I want to distribute a binary build of some software that I have written, > part of which includes some programs that are linked with cygwin1.dll and > other Cygwin dlls such as cygexpat-1.dll, cyggmp-3.dll, cygintl-8.dll and so > on. Binary distrib

Re: Parallel downloading of Cygwin packages

2009/11/2 Ron de Bruijn: > A single fast mirror is only going to be faster than multiple mirrors for > unrealistic values of "fast". Well, I regularly get 1 MByte/s from nearby mirrors. Call me undemanding, but I think that's a realistic value for "fast". > The reason for me not picking a fast mi

Re: Problem with dlopen()

On Nov 1 20:21, Juan Jose Garcia-Ripoll wrote: > This function does some nonstandard things, but the most annoying one > is imposing that the library to be loaded has to have a file > extension. > > If I invoke dlopen("/path/to/temp/dir/temporary_file", ...) then the > routine fails with an error

Re: "Permission denied" on /usr/bin/sh when running gmake with multiple jobs

On Oct 30 08:55, John Daintree wrote: > Hi Corinna, > > I was using a "gmake" not the cygwin "make", and that was generating the > windows path. I've moved over to the cygwin supplied make and fixed up all > the relevant environment variables. No windows paths anymore but I'm still > getting the p

RE: "Permission denied" on /usr/bin/sh when running gmake with multiple jobs

Corinna, That's very helpful, thank you for taking the time to look through the output. I've talk to my IT guys about how we should proceed. /john -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/doc

Re: Parallel downloading of Cygwin packages

On Mon, Nov 02, 2009 at 02:25:03PM +1100, Chris Cormie wrote: >> There are barriers to implementing rpm in Cygwin, the most frequently >> mentioned being the fact that a cygwin process can't easily replace >> cygwin1.dll or any other running executables. > >If the in-Cygwin package manager can't up

RE: Incorrect names for file owners on mapped samba drives

> -Original Message- > From: Corinna Vinschen > Sent: 02 November 2009 12:31 > To: cygwin@cygwin.com > Subject: Re: Incorrect names for file owners on mapped samba drives > > If you want nice entries in ls -l output, add the users and groups to > your local /etc/passwd and /etc/group file

RE: Binary distribution and DLLs

> -Original Message- > From: Corinna Vinschen > Sent: Monday, November 02, 2009 7:38 > Subject: Re: Binary distribution and DLLs > > On Oct 31 15:08, Jon Beniston wrote: > > Hi, > > > > I want to distribute a binary build of some software that I have > > written, part of which include

Re: Binary distribution and DLLs

On Nov 2 09:46, Jason Pyeron wrote: > > -Original Message- > > From: Corinna Vinschen > > Sent: Monday, November 02, 2009 7:38 > > Subject: Re: Binary distribution and DLLs > > > > On Oct 31 15:08, Jon Beniston wrote: > > > Hi, > > > > > > I want to distribute a binary build of some soft

RE: Binary distribution and DLLs

> -Original Message- > From: Corinna Vinschen > Sent: Monday, November 02, 2009 9:58 > Subject: Re: Binary distribution and DLLs > > On Nov 2 09:46, Jason Pyeron wrote: > > > -Original Message- > > > From: Corinna Vinschen > > > Sent: Monday, November 02, 2009 7:38 > > > Subjec

where to find the logrotate package

where to find the logrotate package, thanks. -- 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: Binary distribution and DLLs

> Binary distribution? You are aware that linking an > application against the Cygwin DLL requires to put your > application under a compatible Open Source license, aren't > you? See http://cygwin.com/license.html Yes, it already is GPLed and the source will be included. However, most users d

RE: mkdir differences between 1.5.25 and 1.7

> > $ ls -ld /tmp/foo > > drwxr-xr-x 1 root Administrators 0 Oct 29 20:27 /tmp/foo > > That's a umask thingy. Your umask is probably set to 0022, and per > POSIX, mkdir(2) has to take the umask into account. If you use > mkdir(1) > from coreutils: > > mkdir -m 777 /tmp/foo > > it should crea

Re: mkdir differences between 1.5.25 and 1.7

On Nov 2 08:22, Egerton, Jim wrote: > > > $ ls -ld /tmp/foo > > > drwxr-xr-x 1 root Administrators 0 Oct 29 20:27 /tmp/foo > > > > That's a umask thingy. Your umask is probably set to 0022, and per > > POSIX, mkdir(2) has to take the umask into account. If you use > > mkdir(1) > > from coreutil

Re: Binary distribution and DLLs

On Nov 2 15:59, Jon Beniston wrote: > > Binary distribution? You are aware that linking an > > application against the Cygwin DLL requires to put your > > application under a compatible Open Source license, aren't > > you? See http://cygwin.com/license.html > > Yes, it already is GPLed and t

Shall dlopen("foo") succeeed if only "foo.dll" exists?

Weird question, right? Here's the problem. Assume you have a file "foo.so" on Linux. If you call dlopen ("./foo.so", RTLD_LAZY); it succeeds, but dlopen ("./foo", RTLD_LAZY); fails because the dlopen function never adds any suffixes like .so automatically. Now assume you have a "foo.dll

Re: Parallel downloading of Cygwin packages

On Mon, Nov 2, 2009 at 06:46, Andy Koppe wrote: > > *splutter*. You obviously haven't seen setup.exe's source code, and > you're forgetting that any such solution also needs to be integrated > into the UI, most interestingly, the progress screen, which is > currently designed for downloading one p

[1.7] Undocumented change in accessing by dos drive letters?

I didn't see any documentation in the What's New/What's Changed document saying that the following no longer works: : For example: $ ls C: ls: cannot access C:: No such file or directory This had worked fine on earlier versions. This has broken several of my shell

Re: Parallel downloading of Cygwin packages

On Mon, Nov 02, 2009 at 11:14:04AM -0600, paul.hermeneu...@gmail.com wrote: >On Mon, Nov 2, 2009 at 06:46, Andy Koppe wrote: >> >> *splutter*. You obviously haven't seen setup.exe's source code, and >> you're forgetting that any such solution also needs to be integrated >> into the UI, most intere

Re: Incorrect names for file owners on mapped samba drives

On 11/02/2009 08:58 AM, John Daintree wrote: Thanks for the examples. I had read the man pages for mkpasswd and mkgroup (honest!), but I must have had my incantations a little wrong. I have most of the users and groups over now. Interestingly the "root" group still displays as "" in the

Re: Binary distribution and DLLs

On 11/02/2009 10:10 AM, Jason Pyeron wrote: Link 1: download with source (250MB) Link 2: download without source (12MB) Installing from link2: Installer asks, would you like to download the source? 'setup.exe' does not have a mechanism for such a question if that's what you're asking. From t

Re: SOLVED: Removed 1.5.25 and installed 1.7.0, but still cannot access filenames containing Unicode

2009/11/2 Corinna Vinschen: >> >> You must not use characters >> >> in this range from U+f000 up to U+f0ff.  There's no solution to this >> >> except for "don't use these characters in filenames if they are not >> >> explicitely written there by either Cygwin or Microsoft's SUA". >> >> Actually the

Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?

On 11/02/2009 11:48 AM, Corinna Vinschen wrote: Weird question, right? Here's the problem. Assume you have a file "foo.so" on Linux. If you call dlopen ("./foo.so", RTLD_LAZY); it succeeds, but dlopen ("./foo", RTLD_LAZY); fails because the dlopen function never adds any suffixes lik

Re: [1.7] Undocumented change in accessing by dos drive letters?

On 11/02/2009 01:29 PM, Jeffrey J. Kosowsky wrote: I didn't see any documentation in the What's New/What's Changed document saying that the following no longer works: : For example: $ ls C: ls: cannot access C:: No such file or directory This had worked fine on

Re: SOLVED: Removed 1.5.25 and installed 1.7.0, but still cannot access filenames containing Unicode

On Nov 2 19:16, Andy Koppe wrote: > 2009/11/2 Corinna Vinschen: > >> >> You must not use characters > >> >> in this range from U+f000 up to U+f0ff.  There's no solution to this > >> >> except for "don't use these characters in filenames if they are not > >> >> explicitely written there by either C

Re: [1.7] Undocumented change in accessing by dos drive letters?

On Nov 2 14:22, Larry Hall (Cygwin) wrote: > On 11/02/2009 01:29 PM, Jeffrey J. Kosowsky wrote: > >I didn't see any documentation in the What's New/What's Changed > >document saying that the following no longer works: > > : > >For example: > > $ ls C: > > ls: cannot access C:

Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?

On Nov 2 14:17, Larry Hall (Cygwin) wrote: > On 11/02/2009 11:48 AM, Corinna Vinschen wrote: > >For 1.7 our choice is to keep dlopen() checking for the .dll suffix to > >be more Windows-like, or to be more Linux-like by dropping the check for > >the .dll suffix so that dlopen() fails if the filena

Re: [1.7] Undocumented change in accessing by dos drive letters?

On Nov 2 21:27, Corinna Vinschen wrote: > On Nov 2 14:22, Larry Hall (Cygwin) wrote: > > On 11/02/2009 01:29 PM, Jeffrey J. Kosowsky wrote: > > >I didn't see any documentation in the What's New/What's Changed > > >document saying that the following no longer works: > > > : > > >For ex

Re: [1.7] Undocumented change in accessing by dos drive letters?

2009/11/2 Larry Hall (Cygwin): > On 11/02/2009 01:29 PM, Jeffrey J. Kosowsky wrote: >> >> I didn't see any documentation in the What's New/What's Changed >> document saying that the following no longer works: >>                  : >> For example: >>        $ ls C: >>        ls: cannot access C:: No

Re: [1.7] Undocumented change in accessing by dos drive letters?

On Mon, Nov 02, 2009 at 08:58:02PM +, Andy Koppe wrote: >2009/11/2 Larry Hall (Cygwin): >> On 11/02/2009 01:29 PM, Jeffrey J. Kosowsky wrote: >>> I didn't see any documentation in the What's New/What's Changed >>> document saying that the following no longer works: >>> : >>> For example: >>> $

Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?

On Mon, Nov 02, 2009 at 09:33:49PM +0100, Corinna Vinschen wrote: >On Nov 2 14:17, Larry Hall (Cygwin) wrote: >> On 11/02/2009 11:48 AM, Corinna Vinschen wrote: >> >For 1.7 our choice is to keep dlopen() checking for the .dll suffix to >> >be more Windows-like, or to be more Linux-like by dropping

Limit for bash variable ?

Hello, I need to store some long strings in a bash variable, I'd like to know if there's a limit in length (last version of bash/cygwin 1.5). At the moment the string is 3.185 chars long. It's a temporary situation until I figure something better out. Regards, Nicolas -- Ce message a ete

Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?

On 11/02/2009 03:33 PM, Corinna Vinschen wrote: On Nov 2 14:17, Larry Hall (Cygwin) wrote: On 11/02/2009 11:48 AM, Corinna Vinschen wrote: For 1.7 our choice is to keep dlopen() checking for the .dll suffix to be more Windows-like, or to be more Linux-like by dropping the check for the .dll su

RE: Shall dlopen("foo") succeeed if only "foo.dll" exists?

<20091102203348.gc6...@calimero.vinschen.de> <4aef5b7c.90...@cygwin.com> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 > Date: Mon=2C 2 Nov 2009 17:21:48 -0500 > From: Larry Hall > Subject: Re: Shall dlopen("foo") succeeed if

Re: Limit for bash variable ?

On Mon, Nov 2, 2009 at 4:51 PM, cuicui wrote: > Hello, > > I need to store some long strings in a bash variable, I'd like to know if > there's a limit in length (last version of bash/cygwin 1.5). > > At the moment the string is 3.185 chars long. It's a temporary situation > until I figure somethi

Re: Shall dlopen("foo") succeeed if only "foo.dll" exists?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Corinna Vinschen on 11/2/2009 9:48 AM: > Weird question, right? > > Here's the problem. > > Assume you have a file "foo.so" on Linux. If you call > > dlopen ("./foo.so", RTLD_LAZY); > > it succeeds, but > > dlopen ("./foo", RTLD_

Re: Parallel downloading of Cygwin packages

Christopher Faylor wrote: On Mon, Nov 02, 2009 at 02:25:03PM +1100, Chris Cormie wrote: There are barriers to implementing rpm in Cygwin, the most frequently mentioned being the fact that a cygwin process can't easily replace cygwin1.dll or any other running executables. If the in-Cygwin package

Accessing GLOBALROOT paths - a potential compromise???

I know that there have been multiple threads about the pros/cons of being able to access XP/Vista style \\?\GLOBALROOT paths. However, not being able to access them limits one's abilities to use things like shadow copies since they create shadow devices that are only accessible by such a path. For