Re: GCC-4.7.2-2: Go/No-go?

[Mark Geisert]

d.henman writes:
>
[...]

Please keep that conversation on the cygwin-apps list.  The audience there
is more appropriate for what Dave K was asking.

..mark





--
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: GCC-4.7.2-2: Go/No-go?

[d.henman]

I agree that it should be released.  The sooner the better.
It might help me and others with some building problems I've runn into, that 
didn't exist before. At the very least, it would reduce the number of variables 
that might be the cause of unsuccessful builds.

Dave Korn wrote:
> Hi all,
> 
>   I have a release of 4.7.2-2 ready to upload.  It fixes the dependencies back
> to the 4.5.3-3 curr: version dependencies, makes TLS vars exported from DLLs
> work and restores java and libffi.  I've also been running the testsuite over
> the last few days and the results look quite reasonable.
> 
>   Yaakov thinks (http://cygwin.com/ml/cygwin-apps/2013-04/msg00032.html) that
> I shouldn't release it until I've integrated all his patches.
> 
>   I think (http://cygwin.com/ml/cygwin-apps/2013-04/msg00057.html) that it's
> worth uploading as a stop-gap to address the mentioned problems and
> integrating Yaakov's patches for the next release.
> 
>   Could the list please help us make a decision?
> 
> 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: bash-completion load times

[Gary Johnson]

On 2013-03-27, Adam Dinwoodie wrote:
> Having bash-completion installed significantly slows down starting a new 
> Cygwin
> Bash login shell.  It's a problem I've noticed, and I've seen other users
> report it on this list and elsewhere, too.  I've done a bit of digging into
> what the problem is, and what can be done about it-suggestions are at the
> bottom of this email.
> 
> The slow-down from using bash-completion is due to loading the contents of the
> /etc/bash_completion.d/ directory.  By adding `time` statements at various
> ponits in /etc/bash_completion, I can see it's adding a fairly consistent 
> 6-6.5
> seconds to the shell startup time for me, which more-or-less matches my
> subjective experience (starting Bash without bash-completion installed is
> near-instant).
> 
> Drilling down, there are 187 different scripts in my /etc/bash_completion.d
> (which, until today, should have been untouched by anything other than Cygwin
> setup.exe).  Average load times for me vary from less than a millisecond to
> over 600 milliseconds.  I've attached my analysis as a CSV; times are as
> reported by Bash's `time` builtin for the time for /etc/bash_completion to dot
> in that script.
> 
> A lot of the scripts are for things I don't have installed.  The top four
> scripts in terms of time taken (mailman, shadow, dsniff, e2fsprogs) do nothing
> on my system, but between them alone add 1.5 seconds to the average Bash load
> time.  The top 4 seconds includes only two scripts I'm interested in (git and
> gdb).
> 
> On my PC, I've renamed the majority of the scripts in /etc/bash_completion.d 
> to
> have a .bak extension, which prevents bash-completion from loading them.  I've
> kept 37 hand-selected scripts which I either do use or could forsee me using.
> I'm now seeing Bash take less than a second to load, with picking up all the
> scripts taking about 0.3 seconds.
> 
> To avoid others suffering in the same way, I can think of a few different
> options, none of which are ideal:
> 
> -   Add something to the Cygwin FAQ detailing a solution similar to the above.
> Requires users to actively look for a solution, but requires minimal
> effort.  If people think this would be useful, I'm happy to draft 
> something
> up.
> 
> -   Customize Cygwin's bash-completion package, removing scripts for functions
> that don't exist in Cygwin.  This is obviously additional work for the
> package maintainer (although I'd be glad to help).  This won't help for
> packages that could be installed but aren't, however, but it's at least a
> step.
> 
> -   Split out the bash-completion script into separate packages that users can
> install as needed.  I suspect this is far more effort than it's worth,
> however, both for users and maintainers.
> 
> -   Something else yet to be suggested.

Cygwin's bash-completion package is version 1.3.  Versions 1.9 and
later use dynamic loading of completions that is supposed to
improve the loading times.  I think your best bet is to wait for the
Cygwin package to be updated to the latest 2.1 version and see how
that improves performance.  Or just download and install it from
source yourself.

That said, I'm surprised by the variation in load times of the files
in /etc/bash_completion.d that you observed.  Those files all start
with a call to the have() function which should abort further
processing of the file if the corresponding program is not
installed.

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

Re: 'ssh -1 -L < named_pipe' freezes

[Christopher Faylor]

On Tue, Apr 09, 2013 at 08:04:29PM +0400, Ilya Basin wrote:
>Here's my script that works on linux:
>
>cmd="ssh -T -N -g -1 -L 10001:anotherhost:22"
>fifo=`mktemp -u`
>mkfifo "$fifo"
>$cmd <"$fifo" &
>exec 3>"$fifo"
># message: Pseudo-terminal will not be allocated because stdin is not a 
> terminal.
># netstat shows that port 10001 is LISTENING
># from another terminal: ssh -p 10001 localhost
>#printf '\0' >&3 # unfreeze on Cygwin
>wait
>
>-N is ignored for protocol version 1, so as a workaround I redirect
>input from an eternal pipe.
>I want to save processes, so I'm using a named pipe instead of
>something like:
>sleep | ssh
>
>On Cygwin when I try to use the forwarded port, the new client freezes
>until I write something to the pipe.
>
>This happens only with named pipes. Normal pipes work well.

Named pipes are not completely functional in Cygwin.  Sorry.

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

Fwd: winProductName for Windows 2012 - CSIH

[BGINFO4X]

> Should be fixed in 0.9.7.

Yes, it is fixed. The information reported now is:

OS Name:   Microsoft Windows Server 2012
OS Version:64 bits (Build 9200).

Thanks a lot for your time.

Regards.

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

'ssh -1 -L < named_pipe' freezes

[Ilya Basin]

Here's my script that works on linux:

cmd="ssh -T -N -g -1 -L 10001:anotherhost:22"
fifo=`mktemp -u`
mkfifo "$fifo"
$cmd <"$fifo" &
exec 3>"$fifo"
# message: Pseudo-terminal will not be allocated because stdin is not a 
terminal.
# netstat shows that port 10001 is LISTENING
# from another terminal: ssh -p 10001 localhost
#printf '\0' >&3 # unfreeze on Cygwin
wait

-N is ignored for protocol version 1, so as a workaround I redirect
input from an eternal pipe.
I want to save processes, so I'm using a named pipe instead of
something like:
sleep | ssh

On Cygwin when I try to use the forwarded port, the new client freezes
until I write something to the pipe.

This happens only with named pipes. Normal pipes work well.


--
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: Problem with symbolic links and Mercurial's "update" command

[Larry Hall (Cygwin)]

On 4/9/2013 11:19 AM, Dr. Rainer Woitok wrote:

Greetings,

the problem  I'm having seems to  be either Mercurial or Cygwin related.
I'm currently using Mercurial 2.4.2 and Cygwin 1.7.17, which I'm running
with the "winsymlinks" option in the "CYGWIN" environment variable:

@echo off

set CYGWIN=glob:noignorecase proc_retry:10 nodosfilewarning winsymlinks
set PATH=c:\cygwin\bin

C:
chdir C:\cygwin\bin

sh --login -i

Even though  the problem surfaced in a  rather large repository, I could
reproduce it in an almost empty one, like this:

$ hg --version
Mercurial Distributed SCM (version 2.4.2)
(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2012 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ uname -a
CYGWIN_NT-6.0 tablet 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin
$ mkdir Test
$ cd Test
$ hg init
$ touch a
$ ln -s a la
$ ls -l
total 1
-rw--- 1 Rainer none 0 Apr  9 15:37 a
lrwxrwxrwx 1 Rainer none 1 Apr  9 15:37 la -> a
$ hg add *
$ hg status
A a
A la
$ hg commit -m test.
$ rm *
$ hg status
! a
! la
$ hg update -C
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ ls -l
total 1
-rw--- 1 Rainer none 0 Apr  9 15:40 a
-rw--- 1 Rainer none 1 Apr  9 15:40 la
$ cat la
a$

Mind that while the first "ls" command shows "la" to be a symbolic link,
the second  "ls"  and the "cat" commands show  "la"  to be a  plain file
containing  the single  character file name  (without  trailing  newline
character) the symbolic link was originally pointing to.

Since I cannot  reproduce this link  killing behaviour under OpenSolaris
using Mercurial 1.7.3  (a bit  outdated, yes, but  this is not  under my
control :-),  I  suspect  this could  be Cygwin  rather  than  Mercurial
related.

Any help would be appreciated,  and please also  reply to me personally,
as I am not subscribed to this list.


Does mecurial 2.5.2 help?  Does removing setting "nowinsymlinks" help?

Presumably, mercurial either isn't restoring the read-only attribute or
is munging the LNK suffix.  You might check these possibilities.


--
Larry

_

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

Problem with symbolic links and Mercurial's "update" command

[Dr. Rainer Woitok]

Greetings,

the problem  I'm having seems to  be either Mercurial or Cygwin related.
I'm currently using Mercurial 2.4.2 and Cygwin 1.7.17, which I'm running
with the "winsymlinks" option in the "CYGWIN" environment variable:

@echo off

set CYGWIN=glob:noignorecase proc_retry:10 nodosfilewarning winsymlinks
set PATH=c:\cygwin\bin

C:
chdir C:\cygwin\bin

sh --login -i

Even though  the problem surfaced in a  rather large repository, I could
reproduce it in an almost empty one, like this:

$ hg --version
Mercurial Distributed SCM (version 2.4.2)
(see http://mercurial.selenic.com for more information)

Copyright (C) 2005-2012 Matt Mackall and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ uname -a
CYGWIN_NT-6.0 tablet 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin
$ mkdir Test
$ cd Test
$ hg init
$ touch a
$ ln -s a la
$ ls -l
total 1
-rw--- 1 Rainer none 0 Apr  9 15:37 a
lrwxrwxrwx 1 Rainer none 1 Apr  9 15:37 la -> a
$ hg add *
$ hg status
A a
A la
$ hg commit -m test.
$ rm *
$ hg status
! a
! la
$ hg update -C
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ ls -l
total 1
-rw--- 1 Rainer none 0 Apr  9 15:40 a
-rw--- 1 Rainer none 1 Apr  9 15:40 la
$ cat la 
a$

Mind that while the first "ls" command shows "la" to be a symbolic link,
the second  "ls"  and the "cat" commands show  "la"  to be a  plain file
containing  the single  character file name  (without  trailing  newline
character) the symbolic link was originally pointing to.

Since I cannot  reproduce this link  killing behaviour under OpenSolaris
using Mercurial 1.7.3  (a bit  outdated, yes, but  this is not  under my
control :-),  I  suspect  this could  be Cygwin  rather  than  Mercurial
related.

Any help would be appreciated,  and please also  reply to me personally,
as I am not subscribed to this list.

Sincerely
 Rainer

 --
| Rainer M Woitok| Phone : (+49 60 93) 487 95 95   |
| Kolpingstraße 3| Mobile: (+49 172) 813 6 831 |
| D-63846 Laufach| Mail  : woi...@rrze.uni-erlangen.de |
| Germany| |
 --

--
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: cp "skipping file ..., as it was replaced while being copied

[Charles Wilson]

On 4/9/2013 3:50 AM, Corinna Vinschen wrote:

On Apr  8 17:01, Charles Wilson wrote:

user@machine /k/path $ cp bob fred
cp: skipping file `bob', as it was replaced while being copied


cp checks the inode numbers before and after, and it seems the inode
numbers on this drive are not persistent.


[...]
user@machine /k/path $ /usr/lib/csih/getVolInfo.exe /k
Device Type: 7
Characteristics: 10
Volume Name: 
Serial Number  : 2684354574
Max Filenamelength : 255
Filesystemname : 
Flags  : 4004e
   FILE_CASE_SENSITIVE_SEARCH  : FALSE
   FILE_CASE_PRESERVED_NAMES   : TRUE
   FILE_UNICODE_ON_DISK: TRUE
   FILE_PERSISTENT_ACLS: TRUE
   FILE_FILE_COMPRESSION   : FALSE
   FILE_VOLUME_QUOTAS  : FALSE
   FILE_SUPPORTS_SPARSE_FILES  : TRUE
   FILE_SUPPORTS_REPARSE_POINTS: FALSE
   FILE_SUPPORTS_REMOTE_STORAGE: FALSE
   FILE_VOLUME_IS_COMPRESSED   : FALSE
   FILE_SUPPORTS_OBJECT_IDS: FALSE
   FILE_SUPPORTS_ENCRYPTION: FALSE
   FILE_NAMED_STREAMS  : TRUE
   FILE_READ_ONLY_VOLUME   : FALSE
   FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
   FILE_SUPPORTS_TRANSACTIONS  : FALSE

user@machine /k/path $ mount -m
C: /c ntfs binary,posix=0 0 0
F: /f netapp binary,posix=0 0 0
H: /h netapp binary,posix=0,user 0 0
K: /k cifs binary,exec,posix=0,user 0 0

 
Drive K: is not recognized.  It's *some* drive, claiming to be NTFS, but
not being NTFS, and the rules to recognize Samba drive don't match either.
What kind of drive is that?


It's a netapp Distributed File System.  "K:" is mounted from a specific 
(fairly deep) subdirectory, which -- IIUC -- is a specific volume 
assigned to my project team, but it's under the umbrella of the overall 
DFS manager.


It's actually mounted directly by my fstab.d/$user file as:
K:/ /k netapp  binary,posix=0,exec 0 0

This is odd, because my "S:" drive is mounted to the top of the entire 
DFS structure, in my /etc/fstab file:

S:/ /s netapp  binary,posix=0 0 0

Stranger still, my "F:" drive is mounted to a direct child of the DFS 
structure:

F:/ /f netapp  binary,posix=0 0 0

So, summarizing:

 Windows mount definitions: 
S: = \\dfs.server\data
F: = \\dfs.server\data\Apps
K: = \\dfs.server\DATA\General\MyProject
(no, I don't know why the case difference)

 cygwin fstab definitions: 
S:/ /s netapp  binary,posix=0 0 0
F:/ /f netapp  binary,posix=0 0 0
K:/ /k netapp  binary,posix=0,exec 0 0

 cygwin mount -m report: 
S: /s ntfs binary,posix=0 0 0
F: /f netapp binary,posix=0 0 0
K: /k cifs binary,exec,posix=0,user 0 0


(I don't have write permission in the F: area, so I can only test S: and K:)

= S: =

user@machine /s/Programs/public/user $ ls -l bob
-rw-rw-r--+ 1 user group 21 Apr  9 10:06 bob

user@machine /s/Programs/public/user $ getfacl bob
# file: bob
# owner: user
# group: group
user::rw-
group::rw-
group:root:rwx
mask:rwx
other:r--

user@machine /s/Programs/public/user $ cp bob fred


= K: =

user@machine /k/Users/user $ ls -l bob
-rw-rw-r--+ 1 user group 21 Apr  9 10:11 bob

user@machine /k/Users/user $ getfacl bob
# file: bob
# owner: user
# group: group
user::rw-
group::rw-
group:root:rwx
group:SYSTEM:rwx
mask:rwx
other:r--

user@machine /k/Users/user $ cp bob fred
cp: skipping file `bob', as it was replaced while being copied


Apart from that, try to mount the drive with the ihash mount option.
Does that help?


$ mount -m
...
K: /k cifs binary,exec,ihash,posix=0,user 0 0

user@machine /k/Users/user$ cp bob fred


Appears to help.  Still confused as to why various subelements of our 
netapp DFS hierarchy map to different fs types in the mount -m output, 
even though the fstab entries for all of them say netapp...but I can 
live with that.


--
Chuck


--
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: Bug in ddk headers when used from cygwin

[Corinna Vinschen]

On Apr  9 09:19, Charles Wilson wrote:
> On 4/9/2013 5:16 AM, Corinna Vinschen wrote:
> >On Apr  8 13:54, Charles Wilson wrote:
> >>But doesn't this mean that the cygwin's w32api package should
> >>exclude all of the ddk headers; it's not simply a case that you
> >>"shouldn't" use ddk/*.h, but that you actually cannot, because
> >>compilation will fail.
> >
> >The absence of intrin.h was a bug, but otherwise you could still use
> >the ddk headers for what they are supposed to be:  Writing device
> >drives and other kernel stuff.  The difference is just that the ddk
> >headers from mingw-w64 cannot be used together with the user space
> >headers like windows.h, but that's not different from "upstream".
> 
> ...but is it reasonable to create a *cygwin* device driver or kernel
> mode item?  If you're using the cygwin compiler, then you're linking
> against the cygwin dll -- which makes a bunch of usermode w32 calls
> under the hood.  If it's bad juju to mix ddk/ kernel mode stuff with
> w32api/ user mode stuff, then any "cygwin" device driver is, by
> definition, bad juju.
> 
> If I'm correct, then the *cygwin* w32api-headers package (and
> cygwin64-w32api-headers) should exclude ddk/ from their deliverable
> footprint, even if intrin.h is added back to the toplevel w32api/
> include directory for other reasons.

Well, actually I don't really care one way or the other.  You may want
to discuss this with JonY.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: Bug in ddk headers when used from cygwin

[Charles Wilson]

On 4/9/2013 5:16 AM, Corinna Vinschen wrote:

On Apr  8 13:54, Charles Wilson wrote:

But doesn't this mean that the cygwin's w32api package should
exclude all of the ddk headers; it's not simply a case that you
"shouldn't" use ddk/*.h, but that you actually cannot, because
compilation will fail.


The absence of intrin.h was a bug, but otherwise you could still use
the ddk headers for what they are supposed to be:  Writing device
drives and other kernel stuff.  The difference is just that the ddk
headers from mingw-w64 cannot be used together with the user space
headers like windows.h, but that's not different from "upstream".


...but is it reasonable to create a *cygwin* device driver or kernel 
mode item?  If you're using the cygwin compiler, then you're linking 
against the cygwin dll -- which makes a bunch of usermode w32 calls 
under the hood.  If it's bad juju to mix ddk/ kernel mode stuff with 
w32api/ user mode stuff, then any "cygwin" device driver is, by 
definition, bad juju.


If I'm correct, then the *cygwin* w32api-headers package (and 
cygwin64-w32api-headers) should exclude ddk/ from their deliverable 
footprint, even if intrin.h is added back to the toplevel w32api/ 
include directory for other reasons. Of course mingw64-x86_64-headers 
and mingw64-i686-headers need to retain the ddk/ headers, for precisely 
the reason you indicate, and those two already provide the toplevel 
intrin.h file.


--
Chuck



--
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: cygwin64 build recipe (was: Re: cygwin64 process substitution: known bug?)

[Gregory M. Turner]

On Tue, Apr 9, 2013 at 2:23 AM, Corinna Vinschen wrote:


   No, not really.  You can do that, and I still use the Linux cross
   compiler to build Cygwin, but we don't really *have* to bootstrap
   anymore.



   $ cygport cygwin.cygport download prep compile install package

   or

  $ cygport cygwin.cygport download allmostall

   That should do it.


Before I got this reply I tried native 64->64 ./configure && make && 
make install (roughly speaking) out-of-tree against cvs and... it worked 
like a champ!  One quirk -- by default it builds as 
x86_64-unknown-cygwin, whereas iirc the 32-bit equivalent builds as 
*-pc-cygwin... after supplying host/build/target configure arguments and 
/usr prefix, everything seemed fully cooked at a glance.


Doing it the cygport way sounds even better, though, since then I get 
setup64.exe-based deployment, autorebase, and whatever postinstall 
magic, avoiding the old make install / crash / make install ritual.


< party-hat / confetti emoticon >

-gmt

hoping against hope he managed to post this successfully exactly one time


--
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: /dev/sdb permission denied

[Andrey Repin]

Greetings, andrei!

> result of 'ls /dev/sd*':

> I should have /dev/shm and /dev/mqueue and possibly other directories in the
> /dev directory? 

If you list files matching /dev/sd* pattern, you're unlikely to see anything
other, than what you're looking for.
I hope, that was a simple oversight on your part, and you'll find what you
looking for.

> $ cat /proc/partitions
> major minor  #blocks  name

> 8 0 312571224 sda
> 8 1 301684603 sda1
> 8 2  10884037 sda2
> 816   1000944 sdb
> 832 0 sdc
> 848 0 sdd
> 864 0 sde

> the above shows the 1gig CF card is detected and has 'sdb' assingend to it.

> so it looks like the problem is that I'm missing /dev/shm and /dev/mqueue - 
> is this correct? what can be done to solve


--
WBR,
Andrey Repin (anrdae...@freemail.ru) 09.04.2013, <16:01>

Sorry for my terrible english...


--
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: /dev/sdb permission denied

[Corinna Vinschen]

On Apr  9 10:41, andrei wrote:
> Larry Hall (Cygwin  cygwin.com> writes:
> > What's the result of 'ls /dev/sd*'?
> 
> Hello Larry,
> 
> result of 'ls /dev/sd*':
> 
> $ ls /dev/sd*
> /dev/sda   /dev/sda2  /dev/sdb1  /dev/sdc1  /dev/sdd1  /dev/sde1
> /dev/sda1  /dev/sdb   /dev/sdc   /dev/sdd   /dev/sde
> 
> according to  specialnames.html#pathnames-posixdevices> I should have /dev/shm and 
> /dev/mqueue and possibly other directories in the /dev directory?

Yes, but obviously they are not shown if you filter the ls output
as above.  A plain `ls' should show them.

> $ cat /proc/partitions
> major minor  #blocks  name
> 
> 8 0 312571224 sda
> 8 1 301684603 sda1
> 8 2  10884037 sda2
> 816   1000944 sdb
> 832 0 sdc
> 848 0 sdd
> 864 0 sde
> 
> the above shows the 1gig CF card is detected and has 'sdb' assingend to it.
> 
> so it looks like the problem is that I'm missing /dev/shm and /dev/mqueue - 
> is this correct? what can be done to solve

This has nothing at all to do with it.  But the above output from
/proc/partitions is strange.  Where's sdb1?  Anyway, typically you read
from sdb1 on CF cards and their siblings.  Only as admin you can read
from sdb.  I just tested this again with a CF card in an USB reader
attached to a W7 64 bit machine running Cygwin 1.7.17.  Are you *sure*
you tried it with admin rights?  Did you start your Cygwin shell with
`Run as administrator'?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: perl-Text-CSV and perl-Text-CSV_XS [ATTN: Yaakov]

[Yaakov (Cygwin/X)]

On 2013-04-07 15:38, David Stacey wrote:

I would like to adopt perl-Text-CSV and perl-Text-CSV_XS. At the moment,
both of these are present in Cygwin Ports, and previously Yaakov asked
for first refusal when it comes to adopting packages that are already
present in Ports.

Yaakov: If you are happy for me to adopt these packages then I will send
an [ITA] e-mail to the apps mailing list in the next day or so.


Thanks for the heads-up.  Please feel free to proceed.


Yaakov


--
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: /dev/sdb permission denied

[andrei]

Larry Hall (Cygwin  cygwin.com> writes:

> 
> On 4/8/2013 12:04 PM, andrei wrote:
> > Hi
> >
> > Running version 1.7.17-1
> >
> > Trying to $ dd if=/dev/sdb of=/dev/null count=10 - compact flash card in 
the
> > PC CF card reader.
> >
> > Running above command displays: dd: opening `/dev/sdb': Permission 
denied
> >
> > Searched for solutions, but could not find anything to solve.  Also 
tried
> > running cygwin as administrator but still the same problem.
> >
> > Do I have to mount the /dev/sdb or it is not required in later versions
> > anymore?
> 
> No, you don't.  Have you seen this FAQ entry?
> 
> 
> 
> What's the result of 'ls /dev/sd*'?
> 

Hello Larry,

result of 'ls /dev/sd*':

$ ls /dev/sd*
/dev/sda   /dev/sda2  /dev/sdb1  /dev/sdc1  /dev/sdd1  /dev/sde1
/dev/sda1  /dev/sdb   /dev/sdc   /dev/sdd   /dev/sde

according to  I should have /dev/shm and 
/dev/mqueue and possibly other directories in the /dev directory?

$ cat /proc/partitions
major minor  #blocks  name

8 0 312571224 sda
8 1 301684603 sda1
8 2  10884037 sda2
816   1000944 sdb
832 0 sdc
848 0 sdd
864 0 sde

the above shows the 1gig CF card is detected and has 'sdb' assingend to it.

so it looks like the problem is that I'm missing /dev/shm and /dev/mqueue - 
is this correct? what can be done to solve

thanks,
andrei  





--
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: Missing values in w32api enum

[Kai Tietz]

2013/4/9 Corinna Vinschen schrieb:
> On Apr  9 01:05, Charles Wilson wrote:
>> The following are missing from the definition of enum
>> WELL_KNOWN_SID_TYPE in winnt.h:
>> [...]
>> Should I send this as a patch to mingw64.sf (are they the
>> maintainers of our w32api now?)
>
> Yes, and yes.
>
>
> Thanks,
> Corinna

I applied the missing enumerator values to mingw-w64's trunk at rev 5735.

Thanks for pointing me to this missing stuff.

Regards,
Kai

--
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: Bug in ddk headers when used from cygwin

[Corinna Vinschen]

On Apr  9 11:16, Corinna Vinschen wrote:
> On Apr  8 13:54, Charles Wilson wrote:
> > On 4/8/2013 3:48 AM, Corinna Vinschen wrote:
> > >On Apr  8 01:59, Charles Wilson wrote:
> > >>Any suggestions for a fix?
> > >
> > >Yes.  Do not use the ddk headers with Cygwin.  Not only that intrin.h is
> > >really missing(*), the ddk headers in mingw-w64 are not fit for usage in
> > >user space code.  For that reason the latest Cygwin code does not use
> > >these headers either.
> > >
> > >There are two user space headers exposing ntdll stuff, winternl.h and
> > >ntdef.h.  They partially contradict each other so they can't be used in
> > >parallel.  Usage of winternl.h is preferred.  Wintern.h isn't exactly
> > >set in stone upstream, so additions and fixes are welcome.
> > >And, as a side note,  from mingw32 became just
> > > in mingw-w64.
> > 
> > OK, I'll try to figure out what getVolInfo was using from ddk, and
> > see if I can replicate the functionality with pure w32api non-ddk
> > stuff. I'll also have to ask the original developer what she was
> > thinking, relying on ddk internals... :-)
> 
> You can still use the same functions.  Just the header files to include
> have changed.  That's what winternl.h aand ntdef.h are for, basically,
> with ntdef.h going the way of deprecation at one point.

And, btw.,  patches to winternl.h are mostly welcome upstream.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: cygwin64 build recipe (was: Re: cygwin64 process substitution: known bug?)

[Corinna Vinschen]

On Apr  8 13:53, Gregory M. Turner wrote:
> On 4/8/2013 2:38 AM, Corinna Vinschen wrote:
> >On Apr  8 10:10, Corinna Vinschen wrote:
> >>On Apr  7 13:53, Gregory M. Turner wrote:
> >>>On my cygwin64, all bash process substitutions fail:
> >>>
> >>>$ ls -l <(echo foo)
> >>>lrwxrwxrwx 1 greg None 0 Apr  7 13:20 /dev/fd/63 -> pipe:[656]
> >>>
> >>>$ cat <(echo foo)
> >>>cat: /dev/fd/63: No such file or directory
> >>>
> >>>Here's an strace: http://pastebin.com/KS9766Vv
> >>>
> >>>Anyone know what's going on?  I don't have a cygwin64 kernel/libc
> >>>build tree, yet, but, if this merits further investigation, I
> >>>suppose it's as good an excuse as any to build one, as this is
> >>>messing up my play-time.
> >>Confirmed.  Looks like a bug in bash or (more likely) 64 bit Cygwin.
> >>I'm going to fix a problem reported on the cygwin-apps list first, but
> >>I'll have a look into this later this week.
> >>
> >>Of course I'd appreciate if you look into this, too.  Many problems
> >>found in the 64 bit version during the last couple of weeks are based
> >>on sloppy datatype handling, so I guess this is another one of them.
> >I looked into this first, accidentally.  This should be fixed in CVS
> >I'll upload a new 64 bit Cygwin DLL later today.
> >
> >
> >Thanks again for the report,
> 
> No, thank you for the fix!
> 
> If I may hijack my own thread a bit: I tried a cygwin64 core build
> but things didn't go great.
> 
> Is bootstrap.sh on *-*-linux-gnu still the best way to roll your own
> cygwin64? 

No, not really.  You can do that, and I still use the Linux cross
compiler to build Cygwin, but we don't really *have* to bootstrap
anymore.

> My attempts to cross the cygwin64 cygport on cygwin32
> resulted in tons of fussy problems centered around dlmalloc.c (I
> also had to kludge around some Makefile problems).

Dunno about that, but it sounds weird.  For one thing, we don't have
the 32->64 bit cross compiler yet, so you would have to bootstrap
on 32 bit Cygwin.  The other problem is that the 32 bit cygport isn't
up to the task yet.

If you want to build 64 bit Cygwin outside of Linux, just install
64 bit Cygwin including gcc, cygport, make, etc,. etc.  Run your
shell, extrace the cygport file from the 64 bit Cygwin source package
and call

  $ cygport cygwin.cygport download prep compile install package

or

  $ cygport cygwin.cygport download allmostall

That should do it.


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: Missing values in w32api enum

[Corinna Vinschen]

On Apr  9 01:05, Charles Wilson wrote:
> The following are missing from the definition of enum
> WELL_KNOWN_SID_TYPE in winnt.h:
> [...]
> Should I send this as a patch to mingw64.sf (are they the
> maintainers of our w32api now?)

Yes, and yes.


Thanks,
Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: Bug in ddk headers when used from cygwin

[Corinna Vinschen]

On Apr  8 13:54, Charles Wilson wrote:
> On 4/8/2013 3:48 AM, Corinna Vinschen wrote:
> >On Apr  8 01:59, Charles Wilson wrote:
> >>Any suggestions for a fix?
> >
> >Yes.  Do not use the ddk headers with Cygwin.  Not only that intrin.h is
> >really missing(*), the ddk headers in mingw-w64 are not fit for usage in
> >user space code.  For that reason the latest Cygwin code does not use
> >these headers either.
> >
> >There are two user space headers exposing ntdll stuff, winternl.h and
> >ntdef.h.  They partially contradict each other so they can't be used in
> >parallel.  Usage of winternl.h is preferred.  Wintern.h isn't exactly
> >set in stone upstream, so additions and fixes are welcome.
> >And, as a side note,  from mingw32 became just
> > in mingw-w64.
> 
> OK, I'll try to figure out what getVolInfo was using from ddk, and
> see if I can replicate the functionality with pure w32api non-ddk
> stuff. I'll also have to ask the original developer what she was
> thinking, relying on ddk internals... :-)

You can still use the same functions.  Just the header files to include
have changed.  That's what winternl.h aand ntdef.h are for, basically,
with ntdef.h going the way of deprecation at one point.

> But doesn't this mean that the cygwin's w32api package should
> exclude all of the ddk headers; it's not simply a case that you
> "shouldn't" use ddk/*.h, but that you actually cannot, because
> compilation will fail.

The absence of intrin.h was a bug, but otherwise you could still use
the ddk headers for what they are supposed to be:  Writing device
drives and other kernel stuff.  The difference is just that the ddk
headers from mingw-w64 cannot be used together with the user space
headers like windows.h, but that's not different from "upstream".


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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: cp "skipping file ..., as it was replaced while being copied

[Corinna Vinschen]

On Apr  8 17:01, Charles Wilson wrote:
> On 3/29/2013 4:36 PM, Larry Hall (Cygwin) wrote:
> >On 3/29/2013 4:25 PM, Bill Priest wrote:
> >>#3 I saw lots of complaints and responses for requests for drive info;
> >>but I never saw an explanation of why this checking is being done.
> >
> >I haven't looked at the code like you have but I believe this is to
> >avoid the case of the file being copied onto itself.
> >
> 
> FWIW, I am also seeing this problem, on a remote share (not "ftp")
> mounted to a drive letter, or via its UNC path.  I've worked around
> the issue by using rsync to copy the file, rather than cp (rcp and
> scp also fail).  I'm not sure what rsync does differently, but it
> works.
> 
> user@machine /k/path $ cp bob fred
> cp: skipping file `bob', as it was replaced while being copied

cp checks the inode numbers before and after, and it seems the inode
numbers on this drive are not persistent.

> [...]
> user@machine /k/path $ /usr/lib/csih/getVolInfo.exe /k
> Device Type: 7
> Characteristics: 10
> Volume Name: 
> Serial Number  : 2684354574
> Max Filenamelength : 255
> Filesystemname : 
> Flags  : 4004e
>   FILE_CASE_SENSITIVE_SEARCH  : FALSE
>   FILE_CASE_PRESERVED_NAMES   : TRUE
>   FILE_UNICODE_ON_DISK: TRUE
>   FILE_PERSISTENT_ACLS: TRUE
>   FILE_FILE_COMPRESSION   : FALSE
>   FILE_VOLUME_QUOTAS  : FALSE
>   FILE_SUPPORTS_SPARSE_FILES  : TRUE
>   FILE_SUPPORTS_REPARSE_POINTS: FALSE
>   FILE_SUPPORTS_REMOTE_STORAGE: FALSE
>   FILE_VOLUME_IS_COMPRESSED   : FALSE
>   FILE_SUPPORTS_OBJECT_IDS: FALSE
>   FILE_SUPPORTS_ENCRYPTION: FALSE
>   FILE_NAMED_STREAMS  : TRUE
>   FILE_READ_ONLY_VOLUME   : FALSE
>   FILE_SEQUENTIAL_WRITE_ONCE  : FALSE
>   FILE_SUPPORTS_TRANSACTIONS  : FALSE
> 
> user@machine /k/path $ mount -m
> C: /c ntfs binary,posix=0 0 0
> F: /f netapp binary,posix=0 0 0
> H: /h netapp binary,posix=0,user 0 0
> K: /k cifs binary,exec,posix=0,user 0 0

Drive K: is not recognized.  It's *some* drive, claiming to be NTFS, but
not being NTFS, and the rules to recognize Samba drive don't match either.
What kind of drive is that?

Apart from that, try to mount the drive with the ihash mount option.
Does that help?


Corinna

-- 
Corinna Vinschen  Please, send mails regarding Cygwin to
Cygwin Maintainer 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