Re: cygwin-1.7: mv appends .exe extension to .bat and .com files

[Gerrit Imsieke]

Herb Maeder  maeder.org> writes:

> 
> With a fresh install of cygwin-1.7 on a vanilla Vista system, I see that
> the 'mv' command appends a .exe extension to the destination file for any
> source files that have a .bat or .com extensions.

Had the same problem, cp and mv appending exe to nearly everything. After I
upgraded coreutils from 8.4.1 to 8.4.2 the issue has been resolved.

- Gerrit



--
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: svn: Can't change perms of file Permission denied

[Corinna Vinschen]

On Mar 18 22:10, Steve Bray wrote:
> On 03/18/2010 05:06 PM, Jason Pyeron wrote:
> >It seams that svn needs to be able to write the DAC, and if it cannot then 
> >svn
> >up cannot work. This seems to be not the case in the past (or was there some
> >magic voodoo on my old system?)
> >
> >Any suggestions on where to start?
> >
> >Granting Full on the share and the directory mitigated this issue. I am 
> >unable
> >to keep full control on the share, and previously we had Modify/Change on the
> >share and svn was working.
> >
> This may be the issue that I previously reported
> 
> Cygwin 1.7.1 breaks git on netapp shared drives
> http://www.cygwin.com/ml/cygwin/2010-01/msg01146.html
> 
> A secured share drive has inherited acls without permissions to
> change the permissions.  This will be very common on a Windows
> shared drive but does not occur with POSIX.  In the transition from
> cygwin 1.5 to 1.7 it appears that they try harder to use acls.  If
> they find them they try to use them ... but on these shared drives
> the users do not have permissions to change them.  Any application
> that attempts to change them now fails, git, svn, you name it.  We
> now need to mount the shared drives with the noacls flag so cygwin
> stops trying to change acls even though it does not have permission.
> 
> Perhaps at mount, if the top directory has inherited permissions
> that lack permission to change permissions then it could revert to
> the noacls behavior.

Preparing the ability to use mount points is just loading a table from
the /etc/fstab file.  There isn't checking involved and especially no
checking of the ACL of a directory.

Additionally it's not even possible to do what you want.  The ACL
of the share does not contain any hint about the share permissions,
and the share permissions of a remote share can only be requested
with special permissions.  Normal users get an ACCESS_DENIED when
trying to request this information.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: cannot create files with trailing dots on network share

[Corinna Vinschen]

On Mar 18 19:03, Douglas Seay wrote:
> I?ve had some problems, and it looks like it boils down to handling
> . (dot) characters.  I created a little script to create some files
> with dots in various places.  This script works fine in my $HOME
> directory (C:\cygwin\home\SEAYD).  The name is wrong when the last
> character of the filename is a dot and subdir is on a network share
> (H: in this case).  The rest of the file operations seem to work
> because when I cat them, you can see the file name inside the body
> (yes, I left of the \n).
> 
> Is there a known work around for this?
> 
> >/cygdrive/h/foo> ./fubar
> >mkdir subdir
> >create subdir/none
> >create subdir/in.middle
> >create subdir/.before
> >create subdir/after.
> >create subdir/.every.where.
> >finished successfully
> 
> >/cygdrive/h/foo> ls -al subdir
> >total 5120
> >drwxr-xr-x+ 1    0 2010-03-18 18:31 .
> >drwxrwxrwx  7    0 2010-03-18 18:31 ..
> >-rwxr--r--  1    7 2010-03-18 18:31 .before
> >-rwxr--r--  1    6 2010-03-18 18:31 ARO60A~X
> >-rwxr--r--  1   13 2010-03-18 18:31 _IQDF8~T
> >-rwxr--r--  1    9 2010-03-18 18:31 in.middle
> >-rwxr--r--  1    4 2010-03-18 18:31 none
> 
> >/cygdrive/h/foo> cat subdir/ARO60A~X
> >after./cygdrive/h/foo> cat subdir/_IQDF8~T
> >.every.where./cygdrive/h/foo>

I assume H: is a Samba share?  It's a feature of Samba to massage
filenames which can't be read or created by Win32 clients, and according
to Win32 filename rules, trailing dots and spaces are not allowed in
filenames.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: Cygwin1.dll 1.7.1 causes ActivePerl 5.10 hang on gzip pipe close on Windows Server 2003

[Corinna Vinschen]

On Mar 18 16:16, Matthew Kidd wrote:
> I upgraded to Cygwin 1.7.1 on a (64-bit) Windows Server 2003 and immediately
> ran into trouble. It seems that Perl can no longer shutdown pipes related to
> Cygwin executables. Here is some example code:
> 
> #!/usr/bin/perl
> 
> use strict;
> 
> # my $fname = 'Y:\path\to\ratherbigfile.gz';
> my $fname = '/cygdrive/y/path/to/ratherbigfile.gz';
> 
> open(FH, "gzip -dc $fname |") || die 'open failed.';
> for (1..4) { my $fline = ; print $fline; }
> 
> close(FH);
> print "done\n";
>  
> 
> Before Cygwin 1.7.1 this code ran fine. It printed out four lines, closed
> the pipe, and exited. But now it hangs at the close(FH) statement and the
> child gzip process maxes out a core continuing to uncompress the big file. I
> either have to kill the gzip process or the Perl process. This problem
> happens whether I use a Windows style file path or a Unix style file path.
> It doesn't matter if I use 32-bit or 64-bit Perl.
> 
> If I replace the cygwin1.dll file from the 1.7.1 installation with an older
> version of cygwin1.dll from a different installation (specifically 1.5.25
> cr-0x5f1), the code above works fine (though I imagine mixing and matching
> DLL version is not a good long term solution).

Try the latest developer snapshot from http://cygwin.com/snapshots/
fixes your problem.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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

/cygdrive permissions problem [failing duplicity backup]

[Jan-Aage Frydenbø-Bruvoll]

Dear all,

I am trying to get duplicity (backup) working, and everything seems ok 
apart from the fact that duplicity seems not to be able to see anything 
underneath /cygdrive.


Looking at the permissions on /cygdrive, things seem a little bit odd:

Fri Mar 19 10:29:56 j...@aeolus:/
$ ls -ld /cygdrive/
d--x--x--x 5 jan Administrators 0 2006-12-01 00:00 /cygdrive/

My theory is that if duplicity actually obeys those rights, it would not 
be able to list the contents of the directory and hence none of the 
subfolders either.


However, I have no problems accessing the files underneath /cygdrive 
myself, and getfacl seems to disagree:


Fri Mar 19 10:30:03 j...@aeolus:/
$ getfacl.exe  /cygdrive
# file: /cygdrive
# owner: jan
# group: Administrators
user::rwx
group::r-x
other:r-x
mask:rwx

cygcheck and other Cygwin and Windows tools report of no problems that I 
can see. I cannot remember experiencing any other problems that I would 
attribute to any permissions issues on /cygdrive.


I have been googling high and low to no avail - I hope I haven't 
accidentally overlooked the solution to this problem. If so, if you 
could be so kind as to point me in the right direction, that would be 
highly appreciated.


Thank you in advance for your kind assistance.

Best regards
Jan Frydenbo-Bruvoll


--
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: /cygdrive permissions problem [failing duplicity backup]

[Dave Korn]

On 19/03/2010 10:35, Jan-Aage Frydenbø-Bruvoll wrote:
> Dear all,
> 
> I am trying to get duplicity (backup) working, and everything seems ok
> apart from the fact that duplicity seems not to be able to see anything
> underneath /cygdrive.

  WAG: You aren't using the --exclude-other-filesystems option on your
command-line, by any chance?

cheers,
  DaveK

--
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: cygwin-1.7: mv appends .exe extension to .bat and .com files

[Ilya Beylin]

> Had the same problem, cp and mv appending exe to nearly everything.
> After I upgraded coreutils from 8.4.1 to 8.4.2 the issue has been resolved.

I have coreutils 7.0-2 and "mv" seems to work correctly for me,
however I see that both rsync and rdiff-backup add the .exe suffix
when copying an executable file to a FAT filesystem (for instance,
when backing up on my USB drive).

This is not a big deal for most cygwin programs (except "diff -r" and
"cygpath -d"), they all usually accept "bla.exe" as equivalent of
"bla", but win32 clients would definitely have problems.

-- Ilya

--
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: incomplete/corrupted setup.exe

[G.W. Haywood]

Hi there,

On Thu, 18 Mar 2010 Steven Monai wrote:
>
> On 2010/03/17 6:54 PM, Christopher Faylor wrote:
>
> > Oh.  Are we still talking about this?  I drifted off.
> > Somebody please wake me when all of this tempest in a bikeshed is over.
>
> I don't understand the reason for the dismissive attitude.

You either have to get used to dealing with the attitude, or, in this
case I'm afraid, find a different list.  If you find one, let me know. :)

For the record, the point about this bikeshed discussion is which
particular bike we choose to take out of it.

The point it not whether somebody fiddled with the brakes before we
got our hands on it, and not whether the handlebars will go through
the door.  Those issues are either already dealt with, or secondary.

--

73,
Ged.

--
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: /cygdrive permissions problem [failing duplicity backup]

[Jan-Aage Frydenbø-Bruvoll]

Dave,

On 19/03/2010 11:22, Dave Korn wrote:

WAG: You aren't using the --exclude-other-filesystems option on your
command-line, by any chance?
   


Thanks for the suggestion, but no. What I could have done, though, is 
supply the relevant output from duplicity...


CL:  /usr/bin/duplicity incremental -v 8 --include-globbing-filelist 
includes / 'file:///cygdrive/c/My Dropbox/Backup'


Contents of 'includes':
--
/cygdrive/c/Projects
- **
--

Output:
...
Using temporary directory 
/cygdrive/d/Docume~1/jan/.cache/duplicity/a0ecac5d71c334f7141c2806cd273846/duplicity-bGZegg-tempdir

AsyncScheduler: instantiating at concurrency 0
Error accessing possibly locked file /cygdrive
Cleanup of temporary file 
/cygdrive/d/Docume~1/jan/.cache/duplicity/a0ecac5d71c334f7141c2806cd273846/duplicity-dTYDWQ-tempdir/mktemp-KpH2si-1 
failed

...

Now, what is really odd is that duplicity seems to have no problems 
writing to the backup -destination- file, however finding those files 
underneath /cygdrive/c for whatever reason does not work.


Best regards
Jan


--
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: /cygdrive permissions problem [failing duplicity backup]

[Corinna Vinschen]

On Mar 19 10:35, Jan-Aage Frydenb?-Bruvoll wrote:
> Dear all,
> 
> I am trying to get duplicity (backup) working, and everything seems
> ok apart from the fact that duplicity seems not to be able to see
> anything underneath /cygdrive.
> 
> Looking at the permissions on /cygdrive, things seem a little bit odd:
> 
> Fri Mar 19 10:29:56 j...@aeolus:/
> $ ls -ld /cygdrive/
> d--x--x--x 5 jan Administrators 0 2006-12-01 00:00 /cygdrive/

Thanks for the hint.  I fixed that in CVS so that the permissions
are r-xr-xr-x (0555).  Cygwin 1.5 had these permissions right and
it looks like an oversight when changing the cygdrive fstat method.

> However, I have no problems accessing the files underneath /cygdrive
> myself, and getfacl seems to disagree:

The permissions of the underlying directory are not reflected in
the fstat API.  We're pretending the cygdrive directory has fixed
0555 permissions because it's a virtual directory.  You could
remove the actual directory and cygdrive would still exist.

> Fri Mar 19 10:30:03 j...@aeolus:/
> $ getfacl.exe  /cygdrive
> # file: /cygdrive
> # owner: jan
> # group: Administrators
> user::rwx
> group::r-x
> other:r-x
> mask:rwx

Huh?  How did you do that?  The normal way how the ACL is printed is by
noticing that the virtual cygdrive directory does not support ACLs, so
fstat is called to fill the aclbuf_t structure.  Consequentially, if I
do the above I see (using the unfixed DLL):

  $ getfacl.exe  /cygdrive
  # file: /cygdrive
  # owner: corinna
  # group: vinschen
  user::--x
  group::--x
  other:--x
  mask:rwx

So the ACL is usually faked, just like the fstat permissions.  The
only way to get your above result is to rename the cygdrive prefix
and *then* to call `getfacl /cygdrive'.

> cygcheck and other Cygwin and Windows tools report of no problems
> that I can see. I cannot remember experiencing any other problems
> that I would attribute to any permissions issues on /cygdrive.
> 
> I have been googling high and low to no avail - I hope I haven't
> accidentally overlooked the solution to this problem. If so, if you
> could be so kind as to point me in the right direction, that would
> be highly appreciated.

That could happen if a tool checks for permissions and refuses to call
a function based on the permission settings.  Most of the time it's
easier to call the function and just choke if it returns an error.
Anyway, the simple patch to return read permissions on /cygdrive
might fix this for you.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: /cygdrive permissions problem [failing duplicity backup]

[Dave Korn]

On 19/03/2010 11:22, Corinna Vinschen wrote:
> On Mar 19 10:35, Jan-Aage Frydenb?-Bruvoll wrote:
>>
>
> The permissions of the underlying directory are not reflected in
> the fstat API.  We're pretending the cygdrive directory has fixed
> 0555 permissions because it's a virtual directory.  You could
> remove the actual directory and cygdrive would still exist.
>
>> Fri Mar 19 10:30:03 j...@aeolus:/
>> $ getfacl.exe  /cygdrive
>> # file: /cygdrive
>> # owner: jan
>> # group: Administrators
>> user::rwx
>> group::r-x
>> other:r-x
>> mask:rwx
> 
> Huh?  How did you do that?

  Perhaps Jan has a real physical /cygdrive directory shadowing the virtual
one and there's some inconsistency about when and whether the virtual dir's
perms or the real dir's ACLs get used?  And in that case, perhaps deleting the
physical directory would make duplicity work...

cheers,
  DaveK

--
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: /cygdrive permissions problem [failing duplicity backup]

[Jan-Aage Frydenbø-Bruvoll]

Dave, Corinna,

On 19/03/2010 11:52, Dave Korn wrote:

On 19/03/2010 11:22, Corinna Vinschen wrote:
   


Thanks for the thorough explanation.


On Mar 19 10:35, Jan-Aage Frydenb?-Bruvoll wrote:
 
   

The permissions of the underlying directory are not reflected in
the fstat API.  We're pretending the cygdrive directory has fixed
0555 permissions because it's a virtual directory.  You could
remove the actual directory and cygdrive would still exist.

 

Fri Mar 19 10:30:03 j...@aeolus:/
$ getfacl.exe  /cygdrive
# file: /cygdrive
# owner: jan
# group: Administrators
user::rwx
group::r-x
other:r-x
mask:rwx
   

Huh?  How did you do that?
 

   Perhaps Jan has a real physical /cygdrive directory shadowing the virtual
one and there's some inconsistency about when and whether the virtual dir's
perms or the real dir's ACLs get used?  And in that case, perhaps deleting the
physical directory would make duplicity work...
   


Hm - doesn't seem like that's the case.

Fri Mar 19 11:36:22 j...@aeolus:/
$ rmdir.exe cygdrive

Fri Mar 19 11:36:24 j...@aeolus:/
$ ls -ld cygdrive
d--x--x--x 5 jan Administrators 0 2006-12-01 00:00 cygdrive

Fri Mar 19 11:36:30 j...@aeolus:/
$ getfacl.exe  /cygdrive
# file: /cygdrive
# owner: jan
# group: Administrators
user::rwx
group::r-x
other:r-x
mask:rwx


Best regards
Jan


--
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: /cygdrive permissions problem [failing duplicity backup]

[Corinna Vinschen]

On Mar 19 11:52, Dave Korn wrote:
> On 19/03/2010 11:22, Corinna Vinschen wrote:
> > On Mar 19 10:35, Jan-Aage Frydenb?-Bruvoll wrote:
> >>
> >
> > The permissions of the underlying directory are not reflected in
> > the fstat API.  We're pretending the cygdrive directory has fixed
> > 0555 permissions because it's a virtual directory.  You could
> > remove the actual directory and cygdrive would still exist.
> >
> >> Fri Mar 19 10:30:03 j...@aeolus:/
> >> $ getfacl.exe  /cygdrive
> >> # file: /cygdrive
> >> # owner: jan
> >> # group: Administrators
> >> user::rwx
> >> group::r-x
> >> other:r-x
> >> mask:rwx
> > 
> > Huh?  How did you do that?
> 
>   Perhaps Jan has a real physical /cygdrive directory shadowing the virtual
> one and there's some inconsistency about when and whether the virtual dir's

If so, it would be really weird.  I have a physical cygdrive as well and
I can't reproduce his observation, except I use a DOS path or a cygdrive
path, like, say

  getfacl C:/cygwin/cygdrive
  getfacl /cygdrive/c/cygwin/cygdrive


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: /cygdrive permissions problem [failing duplicity backup]

[Corinna Vinschen]

On Mar 19 11:37, Jan-Aage Frydenb?-Bruvoll wrote:
> Fri Mar 19 11:36:22 j...@aeolus:/
> $ rmdir.exe cygdrive
> 
> Fri Mar 19 11:36:24 j...@aeolus:/
> $ ls -ld cygdrive
> d--x--x--x 5 jan Administrators 0 2006-12-01 00:00 cygdrive
> 
> Fri Mar 19 11:36:30 j...@aeolus:/
> $ getfacl.exe  /cygdrive
> # file: /cygdrive
> # owner: jan
> # group: Administrators
> user::rwx
> group::r-x
> other:r-x
> mask:rwx

This looks suspicious.  Looks like you have more than one Cygwin DLL
in your path and your cygdrive is not the one the other DLL sees or
something like that.
Please attach the output of cygcheck -svr to a mail, and also please
call

  strace -o getfacl.trace getfacl.exe /cygdrive

and attach the getfacl.trace file to your mail as well.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: Updated [experimental]: coreutils-8.4-1

[Nellis, Kenneth]

> From: Eric Blake
> Sent: Thursday, March 18, 2010 16:24
> To: The Cygwin Mailing List
> Subject: Re: Updated [experimental]: coreutils-8.4-1
> 

> 
> Is no one else testing this?  I'm thinking I introduced a bug, because
> 'mv a b' creates 'b.exe', even if 'a' did not have an implicit .exe,
> and
> am looking into building 8.4-2 to fix it.
> 
> --
> Eric Blake   ebl...@redhat.com+1-801-349-2682
> Libvirt virtualization library http://libvirt.org
> volunteer cygwin coreutils maintainer

Associating this thread with a related thread...
http://cygwin.com/ml/cygwin/2010-03/msg00418.html
... it's not clear to me what the correct results are,
so I wouldn't know whether I'm looking at a bug or not.
As I indicated in this other thread, there appears to
be little explanation as to how it should work, so 
how can we judge if it is working correctly?

--Ken Nellis

Installation problem with 1.71.

[Mehmet Salgar]

Hi everybody,

I had a happy 1.5 installation and I need a new package...

Without paying attention update warnings, I installed the 1.7 over my 1.5 
installation and then after nothing works correctly

Bash prompt is there but I the commands like ls, less, etc... nothing is 
there...

I can only execute basic commands like pwd, dirs and that it

After the first try, I deleted everything from the hard disk and I re-installed 
but that didn't help also...

Any ideas?

Thx in advance
-- 
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser

--
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: Installation problem with 1.71.

[Larry Hall (Cygwin)]

On 3/19/2010 9:24 AM, Mehmet Salgar wrote:

Hi everybody,

I had a happy 1.5 installation and I need a new package...

Without paying attention update warnings,





I installed the 1.7 over my 1.5 > installation and then after nothing
works correctly

Bash prompt is there but I the commands like ls, less, etc... nothing is
there...

I can only execute basic commands like pwd, dirs and that it

After the first try, I deleted everything from the hard disk and I
re-installed but that didn't help also...

Any ideas?


Perhaps.  But we need help from you first:



--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
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

cygwin.com website

[Brent Kerr]

Hey,

I've whipped up a web template for cygwin.com if you'd like to use it
- http://cygwin.codecamel.com/ - (it's what I do). Only the homepage
and community page are up there at the moment, but let me know if you
want the rest and I'll put it together.

Cheers,
Brent

--
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: /cygdrive permissions problem [failing duplicity backup]

[Dave Korn]

On 19/03/2010 13:25, Jan-Aage Frydenbø-Bruvoll wrote:

> Please see the attached two files as requested.

> Logitech Process Monitor service

  Stop and disable that service in the service control console.  It's known to
break Cygwin apps.  (It may or may not have anything to do with this precise
problem.)

  Zone Alarm is generally only a problem when it's the full, paid-for version
with all the advanced features, the free firewall-only version isn't so bad.
You might try temporarily uninstalling it if getting rid of the Logitech
Process Monitor doesn't solve it.

  For more information, see the Big List of Dodgy Apps in the FAQ: shortcut
http://tinyurl.com/bloda

cheers,
  DaveK


--
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: Updated [experimental]: coreutils-8.4-1

[Eric Blake]

On 03/19/2010 06:56 AM, Nellis, Kenneth wrote:
> ... it's not clear to me what the correct results are,
> so I wouldn't know whether I'm looking at a bug or not.
> As I indicated in this other thread, there appears to
> be little explanation as to how it should work, so 
> how can we judge if it is working correctly?

That's the whole point of the experimental release - user feedback, on
whether the current behavior matches your particular needs, and if not,
what you think would be better behavior.  It works correctly, for at
least your definition of correct, if it doesn't cause you any grief in
your normal usage patterns.

-- 
Eric Blake   ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org



signature.asc
Description: OpenPGP digital signature

Re: bash exits when test or [ ] is used in Windows Server 2008

[Dick]

I can't reproduce this issue on a fresh install of Windows 2008 in a virtual 
machine using terminal server, I supppose it should just work but it doesn't.

When I start test or [ ] a stackdump is created with the following information:
Exception: STATUS_ACCESS_VIOLATION at eip=775D9832

Please note everything seems to work except [ ] and test in bash (the internal 
version! not /usr/bin/[ or /usr/bin/test)

I've also disable DEP for applications which doesn't help either.

cygcheck -srv doesn't find duplicate cygwin1.dll libraries, but it does find
HKEY_LOCAL_MACHINE\SOFTWARE\Cygwin entries which aren't visible in regedit.exe.
I suppose this is caused by virtual registry.

strace bash -c '[ ]' gives the following output:
 6022  380278 [main] bash 4524 sig_send: sendsig 0x128, pid 4524, 
signal -34, its_me 1
  479  380757 [main] bash 4524 sig_send: wakeup 0x22C
  485  381242 [main] bash 4524 sig_send: Waiting for pack.wakeup 0x22C
9  381251 [sig] bash 4524 wait_sig: signalling pack.wakeup 0x22C
  864  382115 [main] bash 4524 sig_send: returning 0x0 from sending 
signal -34
  406  382521 [main] bash 4524 sigaction_worker: signal 20, 
newact 0x27CB24 (handler 0x41E390), oa 0x0
 7408  389929 [main] bash 4524 sig_send: sendsig 0x128, pid 4524, 
signal -34, its_me 1
  737  390666 [main] bash 4524 sig_send: wakeup 0x230
  519  391185 [main] bash 4524 sig_send: Waiting for pack.wakeup 0x230
9  391194 [sig] bash 4524 wait_sig: signalling pack.wakeup 0x230
 1048  392242 [main] bash 4524 sig_send: 
returning 0x0 from sending signal -34
  479  392721 [main] bash 4524 __set_errno: 
fhandler_socket* get(int):82 val 108
  469  393190 [main] bash 4524 cygwin_getpeername: -1 = getpeername (0) -1
 4975  398165 [main] bash 4524 set_signal_mask: oldmask 0x0, 
newmask 0x0, mask_bits 0x0
 2539  400704 [main] bash 4524 set_signal_mask: not calling 
sig_dispatch_pending
--- Process 4524, exception C005 at 753CA923
  835  401539 [main] bash 4524 _cygtls::handle_exceptions: 
In cygwin_except_handler exc 0xC005 at 0x775DAD42 sp 0x27
42D0
  853  402392 [main] bash 4524 _cygtls::handle_exceptions: 
In cygwin_except_handler sig 11 at 0x775DAD42
  886  403278 [main] bash 4524 _cygtls::handle_exceptions: 
In cygwin_except_handler calling 0x0
 403949 [main] bash 4524 _cygtls::handle_exceptions: 
Exception: STATUS_ACCESS_VIOLATION
  671  403949 [main] bash 4524 _cygtls::handle_exceptions: 
Exception: STATUS_ACCESS_VIOLATION
 1367  405316 [main] bash 4524 try_to_debug: debugger_command ''
 406131 [main] bash 4524 open_stackdumpfile: 
Dumping stack trace to bash.exe.stackdump


--
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: Cygwin 1.7: Concurrency Issue with Shared State Initialization

[Schmidt, Oliver]

Hi Christopher,

> How about today's snapshot?  Corinna has YA told me what I did wrong with the
> latest round of spinlock changes and today's snapshot reflects her obvious
> fix.

Good news for the weekend! I've been running my original scenario with
20100318 repeatedly all day long. I couldn't reproduce any issue so far :-)

>From my perspective you can consider the issue solved. However I'll continue
to run tests next week. If anything goes wrong I'll post another follow-up
here...

Thanks for your very active support in solving this issue with our far from
mainstream scenario!

Regards, Oliver

P.S.: I presume the fix will show up in the next Cygwin release.

--
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: Updated [experimental]: coreutils-8.4-1

[Corinna Vinschen]

On Mar 19 10:01, Eric Blake wrote:
> On 03/19/2010 06:56 AM, Nellis, Kenneth wrote:
> > ... it's not clear to me what the correct results are,
> > so I wouldn't know whether I'm looking at a bug or not.
> > As I indicated in this other thread, there appears to
> > be little explanation as to how it should work, so 
> > how can we judge if it is working correctly?
> 
> That's the whole point of the experimental release - user feedback, on
> whether the current behavior matches your particular needs, and if not,
> what you think would be better behavior.  It works correctly, for at
> least your definition of correct, if it doesn't cause you any grief in
> your normal usage patterns.

My tests with mv from 8.4-2 show the results I expect according to our
discussion on the developer's list.


Thanks,
Corinna



-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: /cygdrive permissions problem [failing duplicity backup]

[Corinna Vinschen]

On Mar 19 13:25, Jan-Aage Frydenb?-Bruvoll wrote:
>   126   56084 [main] getfacl 4280 mount_info::conv_to_win32_path: src_path 
> /cygdrive, dst D:\cygwin\cygdrive, flags 0x3000A, rc 0

That's what puzzles me a lot.  The cygdrive prefix should never have been
converted to a valid Win32 path.  Not according to your mount 


>   113   56197 [main] getfacl 4280 build_fh_pc: fh 0x6120DF7C
>   111   56308 [main] getfacl 4280 stat_worker: (\??\D:\cygwin\cygdrive, 
> 0x22CCC8, 0x6120DF7C), file_attributes 17
>91   56399 [main] getfacl 4280 fhandler_base::fstat: here
>  4717   61116 [main] getfacl 4280 stat_worker: 0 = (\??\D:\cygwin\cygdrive, 
> 0x22CCC8)
>   120   61236 [main] getfacl 4280 normalize_posix_path: src /cygdrive/
>85   61321 [main] getfacl 4280 normalize_posix_path: /cygdrive/ = 
> normalize_posix_path (/cygdrive/)
>84   61405 [main] getfacl 4280 mount_info::conv_to_win32_path: 
> conv_to_win32_path (/cygdrive)
>84   61489 [main] getfacl 4280 set_flags: flags: binary (0x2)
>83   61572 [main] getfacl 4280 mount_info::conv_to_win32_path: src_path 
> /cygdrive, dst D:\cygwin\cygdrive, flags 0x3000A, rc 0
>86   61658 [main] getfacl 4280 build_fh_pc: fh 0x6120DF7C

At this point something goes wrong, but unfortunately it's not clear
from the strace output what that is.  The created file handler is one
for disk-based files, rather than a cygdrive handler.

>   529   62187 [main] getfacl 4280 fhandler_base::set_flags: flags 0x11, 
> supplied_bin 0x0
>99   62286 [main] getfacl 4280 fhandler_base::set_flags: O_TEXT/O_BINARY 
> set in flags 0x1
>98   62384 [main] getfacl 4280 fhandler_base::set_flags: filemode set to 
> binary
>95   62479 [main] getfacl 4280 fhandler_base::fstat_by_handle: 0xC008 
> = NtQueryInformationFile(\??\D:\cygwin\cygdrive, FileBasicInformation)

This is bad as well.  If your directory D:\cygwin\cygdrive really exists,
you shouldn't see such an error (STATUS_INVALID_HANDLE).  Very strange.

> c:  hd  NTFS118950Mb  78% CP CS UN PA FC Data
> d:  hd  NTFS 71782Mb  82% CP CS UN PA FC 
> e:  cd N/AN/A
> f:  cd N/AN/A
> g:  fd  FAT   1914Mb   9% CPUN   Memory card
> 
> D:\cygwin/  system  binary,auto
> D:\cygwin\bin/usr/bin   system  binary,auto
> D:\cygwin\lib/usr/lib   system  binary,auto
> cygdrive prefix  /cygdrive  userbinary,auto

This looks insuspicious.
> 
> Potential app conflicts:
> 
> Logitech Process Monitor service
> Detected: HKLM Registry Key, Named process.

This might be the problem, but I have no own experience with the potential
problems arising from using these tools.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: /cygdrive permissions problem [failing duplicity backup]

[Corinna Vinschen]

On Mar 19 18:39, Corinna Vinschen wrote:
> On Mar 19 13:25, Jan-Aage Frydenb?-Bruvoll wrote:
> >   126   56084 [main] getfacl 4280 mount_info::conv_to_win32_path: src_path 
> > /cygdrive, dst D:\cygwin\cygdrive, flags 0x3000A, rc 0
> 
> That's what puzzles me a lot.  The cygdrive prefix should never have been
> converted to a valid Win32 path.  Not according to your mount 

I ask the jury to ignore this sentence.  It's nonsense.

Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader  cygwin AT cygwin DOT com
Red Hat

--
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: /cygdrive permissions problem [failing duplicity backup]

[Jan-Aage Frydenbø-Bruvoll]

Hi,

On 19/03/2010 17:39, Corinna Vinschen wrote:



   529   62187 [main] getfacl 4280 fhandler_base::set_flags: flags 0x11, 
supplied_bin 0x0
99   62286 [main] getfacl 4280 fhandler_base::set_flags: O_TEXT/O_BINARY 
set in flags 0x1
98   62384 [main] getfacl 4280 fhandler_base::set_flags: filemode set to 
binary
95   62479 [main] getfacl 4280 fhandler_base::fstat_by_handle: 0xC008 = 
NtQueryInformationFile(\??\D:\cygwin\cygdrive, FileBasicInformation)
 

This is bad as well.  If your directory D:\cygwin\cygdrive really exists,
you shouldn't see such an error (STATUS_INVALID_HANDLE).  Very strange.
   


The "real" directory underneath had already been removed, though. Or at 
least I tried doing so, and I didn't get any error messages.





Potential app conflicts:

Logitech Process Monitor service
Detected: HKLM Registry Key, Named process.
 

This might be the problem, but I have no own experience with the potential
problems arising from using these tools.

   


Tried removing the process and corresponding registry key - still same 
behaviour.


Best regards
Jan


--
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: /cygdrive permissions problem [failing duplicity backup]

[Dave Korn]

On 19/03/2010 18:04, Jan-Aage Frydenbø-Bruvoll wrote:

> Tried removing the process and corresponding registry key - still same
> behaviour.

  I would strongly suggest nobody ever follow this reckless approach to
eliminating BLODAs.

  Always use the service control manager and/or the add/remove programs
control panel, according to whether you're trying to temporarily disable or
completely uninstall a suspect package.

  Don't go manually killing processes or hand-editing the registry, or you
will be left holding the pieces when it all breaks.

cheers,
  DaveK

--
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: Cygwin 1.7: Concurrency Issue with Shared State Initialization

[Christopher Faylor]

On Fri, Mar 19, 2010 at 05:59:40PM +0100, Schmidt, Oliver wrote:
>Thanks for your very active support in solving this issue with our far from
>mainstream scenario!

You're welcome.  It really was a pretty serious problem so I'm glad that
it surfaced and that we were theoretically able to fix it.

>P.S.: I presume the fix will show up in the next Cygwin release.

Nope.  It's just for you.  No one else is privileged enough to get the
fix.  :-)

cgf

--
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: Cygwin 1.7: Concurrency Issue with Shared State Initialization

[Larry Hall (Cygwin)]

On 3/19/2010 2:27 PM, Christopher Faylor wrote:

On Fri, Mar 19, 2010 at 05:59:40PM +0100, Schmidt, Oliver wrote:

Thanks for your very active support in solving this issue with our far from
mainstream scenario!


You're welcome.  It really was a pretty serious problem so I'm glad that
it surfaced and that we were theoretically able to fix it.


P.S.: I presume the fix will show up in the next Cygwin release.


Nope.  It's just for you.  No one else is privileged enough to get the
fix.  :-)


I object!  My mother always told me I was special.  Doesn't that make
me privileged too?

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
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: Cygwin 1.7: Concurrency Issue with Shared State Initialization

[Christopher Faylor]

On Fri, Mar 19, 2010 at 02:30:32PM -0400, Larry Hall (Cygwin) wrote:
>On 3/19/2010 2:27 PM, Christopher Faylor wrote:
>>On Fri, Mar 19, 2010 at 05:59:40PM +0100, Schmidt, Oliver wrote:
>>>Thanks for your very active support in solving this issue with our far
>>>from mainstream scenario!
>>
>>You're welcome.  It really was a pretty serious problem so I'm glad
>>that it surfaced and that we were theoretically able to fix it.
>>
>>>P.S.: I presume the fix will show up in the next Cygwin release.
>>
>>Nope.  It's just for you.  No one else is privileged enough to get the
>>fix.  :-)
>
>I object! My mother always told me I was special.  Doesn't that make me
>privileged too?

Ok, ok.  We'll make it available to you too.  But that's it!

cgf

--
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: Cygwin 1.7: Concurrency Issue with Shared State Initialization

[Larry Hall (Cygwin)]

On 3/19/2010 2:32 PM, Christopher Faylor wrote:

On Fri, Mar 19, 2010 at 02:30:32PM -0400, Larry Hall (Cygwin) wrote:

On 3/19/2010 2:27 PM, Christopher Faylor wrote:

On Fri, Mar 19, 2010 at 05:59:40PM +0100, Schmidt, Oliver wrote:

Thanks for your very active support in solving this issue with our far

>from mainstream scenario!

You're welcome.  It really was a pretty serious problem so I'm glad
that it surfaced and that we were theoretically able to fix it.


P.S.: I presume the fix will show up in the next Cygwin release.


Nope.  It's just for you.  No one else is privileged enough to get the
fix.  :-)


I object! My mother always told me I was special.  Doesn't that make me
privileged too?


Ok, ok.  We'll make it available to you too.  But that's it!


Chris is nice.

--
Larry Hall  http://www.rfk.com
RFK Partners, Inc.  (508) 893-9779 - RFK Office
216 Dalton Rd.  (508) 893-9889 - FAX
Holliston, MA 01746

_

A: Yes.

Q: Are you sure?

A: Because it reverses the logical flow of conversation.

Q: Why is top posting annoying in email?


--
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: /cygdrive permissions problem [failing duplicity backup]

[Jan-Aage Frydenbø-Bruvoll]

On 19/03/2010 18:39, Dave Korn wrote:

I would strongly suggest nobody ever follow this reckless approach to
eliminating BLODAs.

   Always use the service control manager and/or the add/remove programs
control panel, according to whether you're trying to temporarily disable or
completely uninstall a suspect package.

   Don't go manually killing processes or hand-editing the registry, or you
will be left holding the pieces when it all breaks.
   


Thanks for the warning, but I feel pretty much on my own on whether 
Windows works at all anyway, so I'm happy with that risk. ;-)


Best regards
Jan


--
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: Odd behavior of mintty with screen

[Gary Johnson]

On 2010-03-04, Andy Koppe wrote:
> Gary Johnson
> > When I execute screen, however, the mintty
> > window immediately shrinks from 157x49 to 80x49.  This shrinking
> > does not occur if I maximize the mintty window before executing
> > screen.
> 
> I've had a quick look, and with TERM=xterm-256color I find that screen
> sends the DECCOLM sequence '\e[?3l' for putting a terminal into
> 80-column mode. For some reason, this doesn't happen with TERM=xterm,
> so there's one workaround. Another would be to find the relevant
> setting in the screen terminal.
> 
> But there is an incompatibility with xterm here. Xterm ignores the
> DECCOLM sequence by default and provides a separate control sequence
> for allowing DECCOLM. I'll implement that for mintty 0.6.

I just installed mintty-0.6-beta4-cygwin15.  No more screen problem.
Thank you.  I'll install mintty-0.6-beta4-cygwin17 at home this
weekend.

Regards,
Gary


--
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

Rsync w/o socketpair does NOT fix hang

[Marco Moreno]

I too am experiencing rsync 3.0.7-1 hanging with ssh on 1.7.1-1.
 
I tried building rsync without socketpair as others suggested, but it did not 
make a difference.  (I presume I built it correctly since --version reports "no 
socketpairs".)  It appears to hang only on large files and consistently failing 
on the same ones.  Thousands of smaller files sync just fine.  Using --progress 
shows that it usually hangs at about the same percent (i.e. 3% complete).  Once 
it hangs, it consumes my cpu.  It then ignores interrupts (^C), requiring a 
kill -9.  I also installed the sans-socketpair build on the remote to no avail.

I'm running windows server 2008 on the client and 2003 on the remote (both 32 
bit).

I'm not a C developer and the extent of my abilities is little more than 
configure/make, but I'm willing to help diagnose this problem since others are 
having trouble reproducing it.  What can I try?

Marco


--
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: Cygwin1.dll 1.7.1 causes ActivePerl 5.10 hang on gzip pipe close on Windows Server 2003

[Matthew Kidd]

>> I upgraded to Cygwin 1.7.1 on a (64-bit) Windows Server 2003 and
>> immediately ran into trouble. It seems that Perl can no longer
shutdown
>> pipes related to Cygwin executables. Here is some example code:
>> 
>> #!/usr/bin/perl
>> 
>> use strict;
>> 
>> # my $fname = 'Y:\path\to\ratherbigfile.gz';
>> my $fname = '/cygdrive/y/path/to/ratherbigfile.gz';
>> 
>> open(FH, "gzip -dc $fname |") || die 'open failed.';
>> for (1..4) { my $fline = ; print $fline; }
>> 
>> close(FH);
>> print "done\n";
>>  
>> 
>> Before Cygwin 1.7.1 this code ran fine. It printed out four lines,
closed
>> the pipe, and exited. But now it hangs at the close(FH) statement and
the
>> child gzip process maxes out a core continuing to uncompress the big
>> file. I either have to kill the gzip process or the Perl process.
This
>> problem happens whether I use a Windows style file path or a Unix
style
>> file path. It doesn't matter if I use 32-bit or 64-bit Perl.
>> 
>> If I replace the cygwin1.dll file from the 1.7.1 installation with an
>> older version of cygwin1.dll from a different installation
(specifically
>> 1.5.25 cr-0x5f1), the code above works fine (though I imagine mixing
and
>> matching DLL version is not a good long term solution).

> Try the latest developer snapshot from http://cygwin.com/snapshots/
> fixes your problem.
>
> Corinna
>
> -- 
> Corinna Vinschen  Please, send mails regarding Cygwin
to
> Cygwin Project Co-Leader  cygwin AT cygwin DOT com
> Red Hat

I had no luck with the 1.7.2 cygwin1.dll from the developer snapshot.
Since the 1.7.1 Cygwin package does not show this problem on a 32-bit
Windows 7 box I think it is a 64-bit architecture issue.

There is a subtle difference between the 32-bit and 64-bit Windows
architectures that might be the cause of the problem. Under 32-bit
Windows, the code above spawns a single gzip.exe child process. But on
64-bit Windows it spawns a gzip process which in turn spawns a gzip
process where the lowest level process is the one that seems to be doing
the work, i.e. is burning CPU. This behavior does not seem unique to the
Cygwin environment but rather has something to do with how Windows
handles legacy 32-bit applications in a 64-bit environment.

  - Matthew Kidd


--
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: difficulties building graphviz 2.20.2

[Dave Abrahams]

Dave Korn  artimi.com> writes:

> 
> I think I worked around it by
> running the "iffe" command manually to generate the FEATURE/vmalloc file and
> then restarting the make.

Didn't work for me :(




--
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

Cygwin vs Via C3: nothing happens, no output

[scott]

Peoples,

I'm attempting to install on a Via EPIA-5000 (533Mhz C3/Samuel 2)
without success... is this platform not supported?

post-install, no Cygwin commands produce any output (not bad command or
filename, just nothing at all), except cygcheck which will only print
the help, any other option/filename results in nothing on screen and
nothing on disk.

Cygwin is installed with all default options/packages, Windows's DEP
feature is on its lowest setting and the CPU doesn't support it,
everything is done as Admin, there are no BSODs or other troubles with
Windows, there are no messages in the event log, the problem persists
across multiple clean reinstalls of Windows and at multiple patch
levels, I've tried multiple Cygwin repositories, redownloading
setup.exe, using the previous version of the main DLL (as selected from
the installer), and rerunning the post-install scripts by hand had no
effect.

I tried the "rebase" thing (thread:
http://www.mail-archive.com/cygwin@cygwin.com/msg103855.html) but that
also has no effect (DLL remains unchanged, nothing printed on screen),
just like all other commands.

Using the same Windows discs/patches, options and Cygwin
setup.exe/repositories on a spare Duron machine works flawlessly.  Linux
had been running on the Via C3 box without problems for many years, so
it doesn't appear to be a hardware fault, though perhaps a C3 is missing
something present in equivalent-class processors?


setup.log from Cygwin v1.7 on W2K3, W2K3 R2, W2K3 R2 SP2, W2K3 R2 SP2 +
all updates:

2010/03/20 11:04:06 Starting cygwin install, version 2.686
2010/03/20 11:04:06 io_stream_cygfile: fopen(/etc/setup/setup.rc) failed
2 No such file or directory
2010/03/20 11:04:06 io_stream_cygfile: fopen(/etc/setup/last-cache)
failed 2 No such file or directory
2010/03/20 11:04:06 io_stream_cygfile: fopen(/etc/setup/last-action)
failed 2 No such file or directory
2010/03/20 11:04:06 io_stream_cygfile: fopen(/etc/setup/net-method)
failed 2 No such file or directory
2010/03/20 11:04:06 io_stream_cygfile: fopen(/etc/setup/net-proxy-host)
failed 2 No such file or directory
2010/03/20 11:04:06 io_stream_cygfile: fopen(/etc/setup/net-proxy-port)
failed 2 No such file or directory
2010/03/20 11:04:06 io_stream_cygfile: fopen(/etc/setup/last-mirror)
failed 2 No such file or directory
2010/03/20 11:04:06 io_stream_cygfile: fopen(/etc/setup/extrakeys)
failed 2 No such file or directory
2010/03/20 11:04:06 io_stream_cygfile:
fopen(/etc/setup/chooser_window_settings) failed 2 No such file or directory
2010/03/20 11:04:06 Current Directory: E:\install\Cygwin
2010/03/20 11:04:06 User has backup/restore rights
2010/03/20 11:04:06 Changing gid to Administrators
2010/03/20 11:04:06 Could not open service McShield for query, start and
stop. McAfee may not be installed, or we don't have access.
2010/03/20 11:04:12 source: network install
2010/03/20 11:04:13 root: C:\cygwin binary system
2010/03/20 11:04:13 io_stream_cygfile: fopen(/etc/setup/installed.db)
failed 2 No such file or directory
2010/03/20 11:04:14 Selected local directory: E:\install\Cygwin
2010/03/20 11:04:25 net: Direct
2010/03/20 11:04:25 io_stream_cygfile: fopen(/etc/setup/mirrors-lst)
failed 2 No such file or directory
2010/03/20 11:04:47 site: http://mirrors.kernel.org/sourceware/cygwin/
2010/03/20 11:06:50 io_stream_cygfile: fopen(/etc/setup/timestamp)
failed 2 No such file or directory
2010/03/20 11:07:56 io_stream_cygfile:
fopen(/etc/setup/new-cygwin-version) failed 2 No such file or directory
[snip "downloaded/extracting" list with no errors]
2010/03/20 11:17:53 Changing gid back to original
2010/03/20 11:17:56 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/000-cygwin-post-install.sh
2010/03/20 11:17:57 abnormal exit: exit code=128
2010/03/20 11:17:57 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/passwd-grp.sh
2010/03/20 11:17:57 abnormal exit: exit code=128
2010/03/20 11:17:57 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/terminfo0.sh
2010/03/20 11:17:57 abnormal exit: exit code=128
2010/03/20 11:17:57 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/update-info-dir.sh
2010/03/20 11:17:57 abnormal exit: exit code=128
2010/03/20 11:17:57 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/coreutils.sh
2010/03/20 11:17:57 abnormal exit: exit code=128
2010/03/20 11:17:57 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/terminfo.sh
2010/03/20 11:17:57 abnormal exit: exit code=128
2010/03/20 11:17:57 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/bash.sh
2010/03/20 11:17:57 abnormal exit: exit code=128
2010/03/20 11:17:57 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/base-files-profile.sh
2010/03/20 11:17:57 abnormal exit: exit code=128
2010/03/20 11:17:57 running: C:\cygwin\bin\bash.exe --norc --noprofile
/etc/postinstall/base-files-mketc.sh
2010/03/20 11:17:57 abnormal exit: exit code=128
201