Re: Please test latest developer snapshot

Re: Please test latest developer snapshot

[Angelo Graziosi]

Corinna Vinschen wrote:
> And, btw., if you find that something suddenly starts working better
> using the snapshot, I'd be happy to hear this.  Good news help to
> keep up the spirit.

It seems that, with this snapshot, the slowdown I flagged after the 
release of 1.7.6[*], reverted (almost). Now the things are more faster. 
Thanks!

Ciao,
Angelo.

---
[*] http://cygwin.com/ml/cygwin/2010-08/msg00689.html

--
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: Please test latest developer snapshot

[jdzstz - gmail dot com]

I have tested the bugs I reported about Varnish Cache program and It
works fine with last snapshot:
    - Make sure that the random number generator is seeded on a
per-thread basis.
    - Fix bind(2) behaviour related to SO_REUSEADDR.

and they works ok.  New madvise call also works ok.

--
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: Please test latest developer snapshot

[Christopher Faylor]

On Thu, Mar 03, 2011 at 02:53:13PM +0200, Oleg Marchuk wrote:
>I fixed error with downgrade cygwin package from 1.7.8-1 to 1.7.7-1

Or, you could, ...you know... please test the latest developer snapshot....

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: Please test latest developer snapshot

[Oleg Marchuk]

I fixed error with downgrade cygwin package from 1.7.8-1 to 1.7.7-1

On Thu, Mar 3, 2011 at 2:22 PM, Oleg Marchuk <kingoleg@gmail.com> wrote:
> I have got error similar to one described in
> http://www.mail-archive.com/cygwin at cygwin.com/msg114840.html
>
> Cygwin works fine until I install screens, try using git in screens,
> get error related to git repository name in prompt and then uninstall
> screens.
>
> In screens:
>
> sh: __git_ps1: command not found
>
> omarchuk@OMarchuk /cygdrive/c/git/gpag $rm /cygdrive/c/git/gpag/.git/index.lock
> rm: cannot remove `/cygdrive/c/git/gpag/.git/index.lock': No such file
> or directory
> sh: __git_ps1: command not found
>
> Then:
>
> omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$git commit
> Projects/web/src/com/luxoft/edms/gpag/web/files/DocumentBean.java
> Projects/web/src/com/luxoft/edms/gpag/web/navigation/MainMenueBean.java
>     6 [main] git 12192 C:\cygwin\bin\git.exe: *** fatal error -
> could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
> Stack trace:
> Frame     Function  Args
> 00229AF4  6102792B  (00229AF4, 00000000, 00000000, 00000000)
> 00229DE4  6102792B  (6117DC60, 00008000, 00000000, 6117F977)
> 0022AE14  61004F3B  (6117F101, 0022AE40, 6C2E6D6F, 666F7875)
> 0022B074  6100176E  (610EECC1, 0022B0A0, 70697263, 690A3B74)
> 0022B0B8  6115DE2C  (6123D0E0, 666F7875, 64652E74, 672E736D)
> 0022B0E8  610EF04E  (0022B130, 00000000, 726F706D, 6F632074)
> 0022B148  610C2C45  (0053A820, 00000000, 00000124, 00000010)
> 0022B168  00467C20  (0053A820, 00000124, 00000010, 00482D3E)
> 0022B198  00482F4A  (0022C2D4, 746E656D, 6E616542, 74786520)
> 0022C298  0048315B  (7FF80000, 00022468, 00000000, 006E0910)
> 0022C2F8  00485A04  (7FF80000, 00022468, 004FF6E4, 006CE684)
> 0022C338  00485A84  (00000001, 00000003, 00605908, 00000002)
> 0022C378  00485CBA  (006CE684, 00000005, 0022C458, 00000001)
> 0022C3B8  00485E3A  (006CE684, 00605908, 0022C458, 00000001)
> 0022C438  0046DD75  (00550E00, 00605908, 0022C458, 00000000)
> 0022C4C8  004179C9  (00510B90, 00000001, 00000000, 00000000)
> End of stack trace (more stack frames may be present)
> Hangup
>
> omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$git commit
> Projects/web/src/com/luxoft/edms/gpag/web/files/DocumentBean.java
> Projects/web/src/com/luxoft/edms/gpag/web/navigation/MainMenueBean.java
> fatal: Unable to create '/cygdrive/c/git/gpag/.git/index.lock': File exists.
>
> If no other git process is currently running, this probably means a
> git process crashed in this repository earlier. Make sure no other git
> process is running and remove the file manually to continue.
>
> omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$rm
> /cygdrive/c/git/gpag/.git/index.lock
>
> omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$uname -a
> CYGWIN_NT-5.1 OMarchuk 1.7.8(0.236/5/3) 2011-03-01 09:36 i686 Cygwin
>
> --
> King Oleg
> ----
>



-- 
King Oleg
----
   http://kingoleg.livejournal.com/

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Please test latest developer snapshot

[Oleg Marchuk]

I have got error similar to one described in
http://www.mail-archive.com/cygwin at cygwin.com/msg114840.html

Cygwin works fine until I install screens, try using git in screens,
get error related to git repository name in prompt and then uninstall
screens.

In screens:

sh: __git_ps1: command not found

omarchuk@OMarchuk /cygdrive/c/git/gpag $rm /cygdrive/c/git/gpag/.git/index.lock
rm: cannot remove `/cygdrive/c/git/gpag/.git/index.lock': No such file
or directory
sh: __git_ps1: command not found

Then:

omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$git commit
Projects/web/src/com/luxoft/edms/gpag/web/files/DocumentBean.java
Projects/web/src/com/luxoft/edms/gpag/web/navigation/MainMenueBean.java
    6 [main] git 12192 C:\cygwin\bin\git.exe: *** fatal error -
could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
Stack trace:
Frame     Function  Args
00229AF4  6102792B  (00229AF4, 00000000, 00000000, 00000000)
00229DE4  6102792B  (6117DC60, 00008000, 00000000, 6117F977)
0022AE14  61004F3B  (6117F101, 0022AE40, 6C2E6D6F, 666F7875)
0022B074  6100176E  (610EECC1, 0022B0A0, 70697263, 690A3B74)
0022B0B8  6115DE2C  (6123D0E0, 666F7875, 64652E74, 672E736D)
0022B0E8  610EF04E  (0022B130, 00000000, 726F706D, 6F632074)
0022B148  610C2C45  (0053A820, 00000000, 00000124, 00000010)
0022B168  00467C20  (0053A820, 00000124, 00000010, 00482D3E)
0022B198  00482F4A  (0022C2D4, 746E656D, 6E616542, 74786520)
0022C298  0048315B  (7FF80000, 00022468, 00000000, 006E0910)
0022C2F8  00485A04  (7FF80000, 00022468, 004FF6E4, 006CE684)
0022C338  00485A84  (00000001, 00000003, 00605908, 00000002)
0022C378  00485CBA  (006CE684, 00000005, 0022C458, 00000001)
0022C3B8  00485E3A  (006CE684, 00605908, 0022C458, 00000001)
0022C438  0046DD75  (00550E00, 00605908, 0022C458, 00000000)
0022C4C8  004179C9  (00510B90, 00000001, 00000000, 00000000)
End of stack trace (more stack frames may be present)
Hangup

omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$git commit
Projects/web/src/com/luxoft/edms/gpag/web/files/DocumentBean.java
Projects/web/src/com/luxoft/edms/gpag/web/navigation/MainMenueBean.java
fatal: Unable to create '/cygdrive/c/git/gpag/.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.

omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$rm
/cygdrive/c/git/gpag/.git/index.lock

omarchuk@OMarchuk /cygdrive/c/git/gpag (master)$uname -a
CYGWIN_NT-5.1 OMarchuk 1.7.8(0.236/5/3) 2011-03-01 09:36 i686 Cygwin

--
King Oleg
----

--
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: Please test latest developer snapshot

[David Rothenberger]

On 2/28/2011 11:06 PM, Christopher Faylor wrote:
> On Fri, Feb 25, 2011 at 04:09:44PM -0800, David Rothenberger wrote:
>> On 2/25/2011 3:24 PM, David Rothenberger wrote:
>>> I realize this report won't be terribly useful, but I did encounter
>>> a problem with the latest snapshot. I have a local git
>>> repository. With the snapshot, "git log" produces:
>>>
>>>       0 [main] git 4944 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
>>>
>>> This works fine up through the 20100924 snapshot and starts to fail
>>> on the 20100926 snapshot.
>>>
>>> This only occurs on some of my git repositories. I was not able to
>>> reproduce it using the latest snapshot by just making a simple
>>> repository, adding a file, then running "git log".
>>>
>>> This is on Windows XP Pro in case it matters (32-bit, all patches
>>> installed).
>>>
>>> I wish I could be more helpful and provide a test case to reproduce
>>> it.
>>
>> I was able to reproduce this using a clone of the git repository itself:
>>
>> % uname -a
>> CYGWIN_NT-5.1 tela 1.7.8s(0.236/5/3) 20110221 20:36:00 i686 Cygwin
>> % git clone git://github.com/git/git.git
>> Cloning into git...
>> remote: Counting objects: 134689, done.
>> remote: Compressing objects: 100% (39672/39672), done.
>> remote: Total 134689 (delta 100250), reused 126970 (delta 93150)
>> Receiving objects: 100% (134689/134689), 28.44 MiB | 621 KiB/s, done.
>> Resolving deltas: 100% (100250/100250), done.
>> % cd git/
>> % git log
>>      0 [main] git 3088 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
> 
> Just to dot the i's here, could you try the latest snapshot?
> 
> Corinna and I went back and forth a little on the best way to fix this.
> The current snapshot has more stringent checking but should still work
> fine.

Yep, still works fine here.

> (Although the fix is still hacky)

Thanks for the fixy hack. :)

-- 
David Rothenberger  ----  daveroth@acm.org

Cynic, n.:
        Experienced.

--
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: Please test latest developer snapshot

[Christopher Faylor]

On Fri, Feb 25, 2011 at 04:09:44PM -0800, David Rothenberger wrote:
>On 2/25/2011 3:24 PM, David Rothenberger wrote:
>> I realize this report won't be terribly useful, but I did encounter
>> a problem with the latest snapshot. I have a local git
>> repository. With the snapshot, "git log" produces:
>> 
>>       0 [main] git 4944 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
>> 
>> This works fine up through the 20100924 snapshot and starts to fail
>> on the 20100926 snapshot.
>> 
>> This only occurs on some of my git repositories. I was not able to
>> reproduce it using the latest snapshot by just making a simple
>> repository, adding a file, then running "git log".
>> 
>> This is on Windows XP Pro in case it matters (32-bit, all patches
>> installed).
>> 
>> I wish I could be more helpful and provide a test case to reproduce
>> it.
>
>I was able to reproduce this using a clone of the git repository itself:
>
>% uname -a
>CYGWIN_NT-5.1 tela 1.7.8s(0.236/5/3) 20110221 20:36:00 i686 Cygwin
>% git clone git://github.com/git/git.git
>Cloning into git...
>remote: Counting objects: 134689, done.
>remote: Compressing objects: 100% (39672/39672), done.
>remote: Total 134689 (delta 100250), reused 126970 (delta 93150)
>Receiving objects: 100% (134689/134689), 28.44 MiB | 621 KiB/s, done.
>Resolving deltas: 100% (100250/100250), done.
>% cd git/
>% git log
>      0 [main] git 3088 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487

Just to dot the i's here, could you try the latest snapshot?

Corinna and I went back and forth a little on the best way to fix this.
The current snapshot has more stringent checking but should still work
fine.

(Although the fix is still hacky)

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: Please test latest developer snapshot

[David Rothenberger]

On 2/27/2011 2:20 AM, Corinna Vinschen wrote:
> On Feb 26 11:35, Corinna Vinschen wrote:
>> On Feb 25 16:09, David Rothenberger wrote:
>>> I was able to reproduce this using a clone of the git repository itself:
>>>
>>> % uname -a
>>> CYGWIN_NT-5.1 tela 1.7.8s(0.236/5/3) 20110221 20:36:00 i686 Cygwin
>>> % git clone git://github.com/git/git.git
>>> Cloning into git...
>>> remote: Counting objects: 134689, done.
>>> remote: Compressing objects: 100% (39672/39672), done.
>>> remote: Total 134689 (delta 100250), reused 126970 (delta 93150)
>>> Receiving objects: 100% (134689/134689), 28.44 MiB | 621 KiB/s, done.
>>> Resolving deltas: 100% (100250/100250), done.
>>> % cd git/
>>> % git log
>>>       0 [main] git 3088 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
>>
>> Thanks for the report.  I can reproduce this under Windows XP but
>> not under Windows 7.  Stay tuned.
> 
> Please test the latest developer snapshot.  It contains a fix which is
> supposed to fix the problem.  It looks like there's a bug in the winmm
> DLL, at least in older versions.  I found a workaround which shouldn't
> work, but it does.  If you're interested in the technical details,
> see the thread starting here:
> http://cygwin.com/ml/cygwin-developers/2011-02/msg00007.html
> 
> If it works for you, and still works for others, I'll release 1.7.8 ASAP.

Works here. Thanks for the quick fix!

-- 
David Rothenberger  ----  daveroth@acm.org

meetings, n.:
        A place where minutes are kept and hours are lost.

--
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: Please test latest developer snapshot

[Angelo Graziosi]

Corinna Vinschen wrote:
> If it works for you, and still works for others,

It works for me (WinXP SP3), I think:

$ uname -a
CYGWIN_NT-5.1 mypc 1.7.8s(0.236/5/3) 20110227 02:35:16 i686 Cygwin

$ git clone git://github.com/git/git.git
Cloning into git...
remote: Counting objects: 134777, done.
remote: Compressing objects: 100% (39706/39706), done.
remote: Total 134777 (delta 100323), reused 127056 (delta 93204)
Receiving objects: 100% (134777/134777), 28.46 MiB | 355 KiB/s, done.
Resolving deltas: 100% (100323/100323), done.

$ cd git

$ git log
commit 0...22
Author: Jonathan Nieder <...>
Date:   Tue Feb 22 22:43:23 2011 +0000

     update-index --refresh --porcelain: add missing const

     Signed-off-by: Jonathan Nieder <...>
     Signed-off-by: Junio C Hamano <...>

commit b3c...246e79d3d2029
Author: Jonathan Nieder <...>
Date:   Tue Feb 22 22:43:22 2011 +0000

     checkout: add missing const to describe_detached_head

     Signed-off-by: Jonathan Nieder <...>
     Signed-off-by: Junio C Hamano <...>

commit d...0
Merge: a...e2 4...260
Author: Junio C Hamano <...>
Date:   Mon Feb 21 22:46:09 2011 -0800

I have added ... where it needs :-)


Ciao,
Angelo.

--
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: Please test latest developer snapshot

[Corinna Vinschen]

On Feb 26 11:35, Corinna Vinschen wrote:
> On Feb 25 16:09, David Rothenberger wrote:
> > I was able to reproduce this using a clone of the git repository itself:
> > 
> > % uname -a
> > CYGWIN_NT-5.1 tela 1.7.8s(0.236/5/3) 20110221 20:36:00 i686 Cygwin
> > % git clone git://github.com/git/git.git
> > Cloning into git...
> > remote: Counting objects: 134689, done.
> > remote: Compressing objects: 100% (39672/39672), done.
> > remote: Total 134689 (delta 100250), reused 126970 (delta 93150)
> > Receiving objects: 100% (134689/134689), 28.44 MiB | 621 KiB/s, done.
> > Resolving deltas: 100% (100250/100250), done.
> > % cd git/
> > % git log
> >       0 [main] git 3088 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
> 
> Thanks for the report.  I can reproduce this under Windows XP but
> not under Windows 7.  Stay tuned.

Please test the latest developer snapshot.  It contains a fix which is
supposed to fix the problem.  It looks like there's a bug in the winmm
DLL, at least in older versions.  I found a workaround which shouldn't
work, but it does.  If you're interested in the technical details,
see the thread starting here:
http://cygwin.com/ml/cygwin-developers/2011-02/msg00007.html

If it works for you, and still works for others, I'll release 1.7.8 ASAP.


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: Please test latest developer snapshot

[Vorfeed Canal]

On Sat, Feb 26, 2011 at 4:03 AM, Thomas Wolff <towo@towo.net> wrote:
> No, what used to work (and didn't work in cygwin for a while) is that the
> current directory of some process is removed, not mentioning how it could be
> removed.

Sure, this is pre-requisite of rmdir("."). I was specifically talking about
rmdir(".") and rmdir("..").

> It cannot be removed by "rmdir ." for the reasons I mentioned.

Well, may be it can not be done in CygWin for some internal reasons but it
was possible to do that in Linux for a long time - till it was explicitly
forbidden.

> It can only be removed by using its full path, or relative path from its parent
> directory. The parent directory must be referred explicitly, otherwise it
> cannot work - because, as I tried to explain, the semantics of removing a
> directory entry (whether file or subdirectory) could not be established.
>

It can be established and it was established in Linux 15 years ago.

> Actually, in traditional Unix terminology, directories were also special
> files; moreever, there could even be hard links of directories - but that
> doesn't contribute to the issue.
>

Oh, but it does. Sure, long time ago directories were just "files+" and you had
no need for getdents(2) and Co. But as long as directories are just a special
files and you are allowed to make hardlinks you can corrupt filesystem from
userspace using standard Unix API. Not good(tm). Thus small alteration was made:
".." entity. It was introduced to make sure you are not introducing loops (you
can traverse back to the root using chains of ".." and see that you are not
corrupting the tree).

But the introduction of ".." and special functions needed to manipulate the tree
made it perfectly fine to do rmdir(".") - there are not ambguity from this point
on!

> This conclusion is not correct. The code you seem to refer to is just a way
> of handling an error that would otherwise go unhandled and produce problems.

No, it'll not produce problems. It'll just work(tm). Well, may be it'll produce
problems today (it's possible there are some other places in kernel which depend
on these checks today), but it certainly worked in Linux for a long, long time
without any ill effects (except for some brain-dead scripts). Long enough to
paper over the problem in rmdir(1)...

> Error handling is not a limitation.

It's the only limitation.

> Further down in the code, where the actual removal is invoked, the code needs
> the parent directory which it would not have in the case guarded by the error
> checking.

Why do you think so? Parent directory is ALWAYS available via ".."
entity. In some
case it's not available (for example if it's the root of the filesystem) - well,
in this case rmdir(".") obviously can not work.

Sure, in original Unix design where ".." was convenience, not a requirement it's
not possible to make rmdir(".") work, but these Unix system were extinct for so
long that we may happily forget about them.

P.S. Actually in modern Unix systems (including Linux) ".." entity does not
exist on disk - but it's strictly enforced in VFS layer so it does not change
anything conceptually: rmdir(".") makes perfect sense in Unix filesystem
and the ONLY reason it does not work on modern Unix systems is explicit
prohibition in POSIX.

--
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: Please test latest developer snapshot

[Vorfeed Canal]

On Sat, Feb 26, 2011 at 4:03 AM, Thomas Wolff <towo@towo.net> wrote:
> No, what used to work (and didn't work in cygwin for a while) is that the
> current directory of some process is removed, not mentioning how it could be
> removed.

Sure, this is pre-requisite of rmdir("."). I was specifically talking about
rmdir(".") and rmdir("..").

> It cannot be removed by "rmdir ." for the reasons I mentioned.

Well, may be it can not be done in CygWin for some internal reasons but it
was possible to do that in Linux for a long time - till it was explicitly
forbidden.

> It can only be removed by using its full path, or relative path from its parent
> directory. The parent directory must be referred explicitly, otherwise it
> cannot work - because, as I tried to explain, the semantics of removing a
> directory entry (whether file or subdirectory) could not be established.
>

It can be established and it was established in Linux 15 years ago.

> Actually, in traditional Unix terminology, directories were also special
> files; moreever, there could even be hard links of directories - but that
> doesn't contribute to the issue.
>

Oh, but it does. Sure, long time ago directories were just "files+" and you had
no need for getdents(2) and Co. But as long as directories are just a special
files and you are allowed to make hardlinks you can corrupt filesystem from
userspace using standard Unix API. Not good(tm). Thus small alteration was made:
".." entity. It was introduced to make sure you are not introducing loops (you
can traverse back to the root using chains of ".." and see that you are not
corrupting the tree).

But the introduction of ".." and special functions needed to manipulate the tree
made it perfectly fine to do rmdir(".") - there are not ambguity from this point
on!

> This conclusion is not correct. The code you seem to refer to is just a way
> of handling an error that would otherwise go unhandled and produce problems.

No, it'll not produce problems. It'll just work(tm). Well, may be it'll produce
problems today (it's possible there are some other places in kernel which depend
on these checks today), but it certainly worked in Linux for a long, long time
without any ill effects (except for some brain-dead scripts). Long enough to
paper over the problem in rmdir(1)...

> Error handling is not a limitation.

It's the only limitation.

> Further down in the code, where the actual removal is invoked, the code needs
> the parent directory which it would not have in the case guarded by the error
> checking.

Why do you think so? Parent directory is ALWAYS available via ".."
entity. In some
case it's not available (for example if it's the root of the filesystem) - well,
in this case rmdir(".") obviously can not work.

Sure, in original Unix design where ".." was convenience, not a requirement it's
not possible to make rmdir(".") work, but these Unix system were extinct for so
long that we may happily forget about them.

P.S. Actually in modern Unix systems (including Linux) ".." entity does not
exist on disk - but it's strictly enforced in VFS layer so it does not change
anything conceptually: rmdir(".") makes perfect sense in Unix filesystem
and the ONLY reason it does not work on modern Unix systems is explicit
prohibition in POSIX.

--
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: Please test latest developer snapshot

[Vorfeed Canal]

On Sat, Feb 26, 2011 at 4:03 AM, Thomas Wolff <towo@towo.net> wrote:
> No, what used to work (and didn't work in cygwin for a while) is that the
> current directory of some process is removed, not mentioning how it could be
> removed.

Sure, this is pre-requisite of rmdir("."). I was specifically talking about
rmdir(".") and rmdir("..").

> It cannot be removed by "rmdir ." for the reasons I mentioned.

Well, may be it can not be done in CygWin for some internal reasons but it
was possible to do that in Linux for a long time - till it was explicitly
forbidden.

> It can only be removed by using its full path, or relative path from its parent
> directory. The parent directory must be referred explicitly, otherwise it
> cannot work - because, as I tried to explain, the semantics of removing a
> directory entry (whether file or subdirectory) could not be established.
>

It can be established and it was established in Linux 15 years ago.

> Actually, in traditional Unix terminology, directories were also special
> files; moreever, there could even be hard links of directories - but that
> doesn't contribute to the issue.
>

Oh, but it does. Sure, long time ago directories were just "files+" and you had
no need for getdents(2) and Co. But as long as directories are just a special
files and you are allowed to make hardlinks you can corrupt filesystem from
userspace using standard Unix API. Not good(tm). Thus small alteration was made:
".." entity. It was introduced to make sure you are not introducing loops (you
can traverse back to the root using chains of ".." and see that you are not
corrupting the tree).

But the introduction of ".." and special functions needed to manipulate the tree
made it perfectly fine to do rmdir(".") - there are not ambguity from this point
on!

> This conclusion is not correct. The code you seem to refer to is just a way
> of handling an error that would otherwise go unhandled and produce problems.

No, it'll not produce problems. It'll just work(tm). Well, may be it'll produce
problems today (it's possible there are some other places in kernel which depend
on these checks today), but it certainly worked in Linux for a long, long time
without any ill effects (except for some brain-dead scripts). Long enough to
paper over the problem in rmdir(1)...

> Error handling is not a limitation.

It's the only limitation.

> Further down in the code, where the actual removal is invoked, the code needs
> the parent directory which it would not have in the case guarded by the error
> checking.

Why do you think so? Parent directory is ALWAYS available via ".."
entity. In some
case it's not available (for example if it's the root of the filesystem) - well,
in this case rmdir(".") obviously can not work.

Sure, in original Unix design where ".." was convenience, not a requirement it's
not possible to make rmdir(".") work, but these Unix system were extinct for so
long that we may happily forget about them.

P.S. Actually in modern Unix systems (including Linux) ".." entity does not
exist on disk - but it's strictly enforced in VFS layer so it does not change
anything conceptually: rmdir(".") makes perfect sense in Unix filesystem
and the ONLY reason it does not work on modern Unix systems is explicit
prohibition in POSIX.

--
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: Please test latest developer snapshot

[Corinna Vinschen]

On Feb 25 16:09, David Rothenberger wrote:
> I was able to reproduce this using a clone of the git repository itself:
> 
> % uname -a
> CYGWIN_NT-5.1 tela 1.7.8s(0.236/5/3) 20110221 20:36:00 i686 Cygwin
> % git clone git://github.com/git/git.git
> Cloning into git...
> remote: Counting objects: 134689, done.
> remote: Compressing objects: 100% (39672/39672), done.
> remote: Total 134689 (delta 100250), reused 126970 (delta 93150)
> Receiving objects: 100% (134689/134689), 28.44 MiB | 621 KiB/s, done.
> Resolving deltas: 100% (100250/100250), done.
> % cd git/
> % git log
>       0 [main] git 3088 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487

Thanks for the report.  I can reproduce this under Windows XP but
not under Windows 7.  Stay tuned.


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: Please test latest developer snapshot

[marco atzeri]

On Sat, Feb 26, 2011 at 1:09 AM, David Rothenberger  wrote:
> On 2/25/2011 3:24 PM, David Rothenberger wrote:
>> I realize this report won't be terribly useful, but I did encounter
>> a problem with the latest snapshot. I have a local git
>> repository. With the snapshot, "git log" produces:
>>
>>       0 [main] git 4944 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
>>
>> This works fine up through the 20100924 snapshot and starts to fail
>> on the 20100926 snapshot.
>>
>> This only occurs on some of my git repositories. I was not able to
>> reproduce it using the latest snapshot by just making a simple
>> repository, adding a file, then running "git log".
>>
>> This is on Windows XP Pro in case it matters (32-bit, all patches
>> installed).
>>
>> I wish I could be more helpful and provide a test case to reproduce
>> it.
>
> I was able to reproduce this using a clone of the git repository itself:
>
> % uname -a
> CYGWIN_NT-5.1 tela 1.7.8s(0.236/5/3) 20110221 20:36:00 i686 Cygwin
> % git clone git://github.com/git/git.git
> Cloning into git...
> remote: Counting objects: 134689, done.
> remote: Compressing objects: 100% (39672/39672), done.
> remote: Total 134689 (delta 100250), reused 126970 (delta 93150)
> Receiving objects: 100% (134689/134689), 28.44 MiB | 621 KiB/s, done.
> Resolving deltas: 100% (100250/100250), done.
> % cd git/
> % git log
>      0 [main] git 3088 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
>
>
> --
> David Rothenberger
>

same on XP SP3,

$ uname -a
CYGWIN_NT-5.1 MATZERI-FSC-EU 1.7.8s(0.236/5/3) 20110221 20:36:00 i686 Cygwin


$ git log
     10 [main] git 4800 E:\cygwin2\bin\git.exe: *** fatal error -
could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
Stack trace:
Frame     Function  Args
0022AEB4  6102785B  (0022AEB4, 00000000, 00000000, 00000000)
0022B1A4  6102785B  (6117DC60, 00008000, 00000000, 6117F997)
0022C1D4  61004E5B  (6117F084, 0022C200, 00000000, 00000000)
0022C434  610013F7  (610EEBC1, 0022C460, 7C90DFCA, 7C8329C8)
0022C478  6115DE2C  (6123D0E0, 0022C6FC, 0022C588, 610E9A06)
0022C5E8  610BE3BF  (0022C6FC, 0022C660, 0022C640, 0022C620)
0022C748  610BEDC0  (00000001, 0022C770, 0022C6A0, 0022C770)
0022C778  610C2B45  (00000007, 0000003D, 00000001, 61024273)
0022C7E8  00469F57  (0052A490, 0022C868, 0022C848, 00430B15)
0022C7F8  004653FE  (0022CC14, 0022C838, 0022C868, 0022CC24)
0022C848  00430B15  (0022C868, 0022CC24, 00610C30, 00610C38)
0022CC38  00430FDA  (00000001, 61245B88, 00000000, 0022CCD4)
0022CCE8  004017A9  (612459E4, 004DB17A, 00000000, 00000000)
0022CD48  004019FE  (00000000, 00000000, 0022CD88, 61006F68)
0022CD88  61006F68  (00000000, 0022CDC4, 610068B0, 7FFDC000)
End of stack trace

$ cygcheck git
Found: E:\cygwin2\bin\git.exe
E:\cygwin2\bin\git.exe
  E:\cygwin2\bin\cygcrypto-0.9.8.dll
    E:\cygwin2\bin\cygwin1.dll
      C:\WINDOWS\system32\ADVAPI32.DLL
        C:\WINDOWS\system32\KERNEL32.dll
          C:\WINDOWS\system32\ntdll.dll
        C:\WINDOWS\system32\RPCRT4.dll
          C:\WINDOWS\system32\Secur32.dll
    E:\cygwin2\bin\cygz.dll
      E:\cygwin2\bin\cyggcc_s-1.dll
  E:\cygwin2\bin\cygiconv-2.dll


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: Please test latest developer snapshot

[Thomas Wolff]

Am 26.02.2011 01:24, schrieb Vorfeed Canal:
> On Mon, Feb 21, 2011 at 6:20 PM, Thomas Wolff<towo@towo.net>  wrote:
>> And this is not an artificial limitation but there is no way that this
>> could conceivably work.
> What do you mean "there is no way that this could conceivably work"?
>
> It worked in Linux till it was explicitly forbidden...
>
> See here, for example: http://lkml.org/lkml/1997/9/12/100
No, what used to work (and didn't work in cygwin for a while) is that 
the current directory of some process is removed, not mentioning how it 
could be removed. It cannot be removed by "rmdir ." for the reasons I 
mentioned. It can only be removed by using its full path, or relative 
path from its parent directory. The parent directory must be referred 
explicitly, otherwise it cannot work - because, as I tried to explain, 
the semantics of removing a directory entry (whether file or 
subdirectory) could not be established.

>> By Unix design, removing a file or directory basically means removing
>> its entry from its parent directory, so it is not an operation on the
>> file in the first place (or on the target directory in this case).
> Well, yeah - and this explains all subsequent effects. Directories are not
> files, directory can only have one name at most so there are no confusion.
Actually, in traditional Unix terminology, directories were also special 
files; moreever, there could even be hard links of directories - but 
that doesn't contribute to the issue.

>> The parent directory is obviously needed by design, thus "." is not
>> something that could ever be removed (from where?).
>  From filesystem?
Which means from its parent directory because that concept is a core 
part of the Unix filesystems.
> This artificial limitation was added to POSIX (and
> later to Linux) to fix some old broken scripts. I'm not sure if it was
> good idea or not, but it's written in a standard now so that's how it
> works.
>
> But yes, it IS quite artificial limitation:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/namei.c;h=0087cf9c2c6bccaf99000fbd0bfe95257549d81b;hb=HEAD#l2866
>
> As you can see the only reason you can not rmdir(".") and then rmdir("..")
> is because it's quite explicitly checked for to satisfy POSIX.
This conclusion is not correct. The code you seem to refer to is just a 
way of handling an error that would otherwise go unhandled and produce 
problems. Error handling is not a limitation. Further down in the code, 
where the actual removal is invoked, the code needs the parent directory 
which it would not have in the case guarded by the error checking.

Thomas

--
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: Please test latest developer snapshot

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 966 bytes --]

On 02/25/2011 05:24 PM, Vorfeed Canal wrote:
> On Mon, Feb 21, 2011 at 6:20 PM, Thomas Wolff <towo@towo.net> wrote:
>> And this is not an artificial limitation but there is no way that this
>> could conceivably work.
> 
> What do you mean "there is no way that this could conceivably work"?
> 
> It worked in Linux till it was explicitly forbidden...

Well, there's other strange effects with operating on "." and "..".  At
one point, the Hurd operating system tried to honor
rename("subdir/..","other") (similar to this discussion about
rmdir(".")), with the net result of deadlocking the filesystem and
making all subsequent syscalls fail with EIEIO ("the computer bought the
farm").  There's a reason that POSIX forbids some operations on these
names, because they are too prone to bad implementations royally
screwing up your system.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: Please test latest developer snapshot

[Vorfeed Canal]

On Mon, Feb 21, 2011 at 6:20 PM, Thomas Wolff <towo@towo.net> wrote:
> And this is not an artificial limitation but there is no way that this
> could conceivably work.

What do you mean "there is no way that this could conceivably work"?

It worked in Linux till it was explicitly forbidden...

See here, for example: http://lkml.org/lkml/1997/9/12/100

> By Unix design, removing a file or directory basically means removing
> its entry from its parent directory, so it is not an operation on the
> file in the first place (or on the target directory in this case).

Well, yeah - and this explains all subsequent effects. Directories are not
files, directory can only have one name at most so there are no confusion.

> The parent directory is obviously needed by design, thus "." is not
> something that could ever be removed (from where?).

From filesystem? This artificial limitation was added to POSIX (and
later to Linux) to fix some old broken scripts. I'm not sure if it was
good idea or not, but it's written in a standard now so that's how it
works.

But yes, it IS quite artificial limitation:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=fs/namei.c;h=0087cf9c2c6bccaf99000fbd0bfe95257549d81b;hb=HEAD#l2866

As you can see the only reason you can not rmdir(".") and then rmdir("..")
is because it's quite explicitly checked for to satisfy POSIX.

--
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: Please test latest developer snapshot

[David Rothenberger]

On 2/25/2011 3:24 PM, David Rothenberger wrote:
> I realize this report won't be terribly useful, but I did encounter
> a problem with the latest snapshot. I have a local git
> repository. With the snapshot, "git log" produces:
> 
>       0 [main] git 4944 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487
> 
> This works fine up through the 20100924 snapshot and starts to fail
> on the 20100926 snapshot.
> 
> This only occurs on some of my git repositories. I was not able to
> reproduce it using the latest snapshot by just making a simple
> repository, adding a file, then running "git log".
> 
> This is on Windows XP Pro in case it matters (32-bit, all patches
> installed).
> 
> I wish I could be more helpful and provide a test case to reproduce
> it.

I was able to reproduce this using a clone of the git repository itself:

% uname -a
CYGWIN_NT-5.1 tela 1.7.8s(0.236/5/3) 20110221 20:36:00 i686 Cygwin
% git clone git://github.com/git/git.git
Cloning into git...
remote: Counting objects: 134689, done.
remote: Compressing objects: 100% (39672/39672), done.
remote: Total 134689 (delta 100250), reused 126970 (delta 93150)
Receiving objects: 100% (134689/134689), 28.44 MiB | 621 KiB/s, done.
Resolving deltas: 100% (100250/100250), done.
% cd git/
% git log
      0 [main] git 3088 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487


-- 
David Rothenberger  ----  daveroth@acm.org

malpractice, n.:
        The reason surgeons wear masks.

--
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: Please test latest developer snapshot

[David Rothenberger]

I realize this report won't be terribly useful, but I did encounter
a problem with the latest snapshot. I have a local git
repository. With the snapshot, "git log" produces:

      0 [main] git 4944 C:\cygwin\bin\git.exe: *** fatal error - could not load C:\WINDOWS\system32\winmm.dll, Win32 error 487

This works fine up through the 20100924 snapshot and starts to fail
on the 20100926 snapshot.

This only occurs on some of my git repositories. I was not able to
reproduce it using the latest snapshot by just making a simple
repository, adding a file, then running "git log".

This is on Windows XP Pro in case it matters (32-bit, all patches
installed).

I wish I could be more helpful and provide a test case to reproduce
it.


-- 
David Rothenberger  ----  daveroth@acm.org

"The geeks shall inherit the earth."
                -- Karl Lehenbauer

--
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: Please test latest developer snapshot

[Corinna Vinschen]

On various days, various members of the Cygwin community wrote:
> [...snapshot testing...]

Wow, that's all pretty good news.  Thanks to all of you for testing
the snapshots.  Stay tuned for the release.


Thanks again,
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: Please test latest developer snapshot

[Kai Tietz]

Yes, good progress. A lot of those x64 Win7 issues don't appear
anymore for me and I didn't had now for some time no more forking
issues.

Thanks,
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: Please test latest developer snapshot

[Reini Urban]

>>  Please test latest developer snapshot

Lots of perl builds and smokes passed with no new errors.
-- 
Reini

--
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: Please test latest developer snapshot

[Karl M]

----------------------------------------
> Date: Thu, 24 Feb 2011 16:16:11 +0100
> From: corinna
> Subject: Re: Please test latest developer snapshot
>
> On Feb 24 09:56, Chris Sutcliffe wrote:
> > On 17 February 2011 07:04, Corinna Vinschen wrote:
> > > Apart from your testing and our fixing of obvious bugs, the other item
> > > holding up the release of Cygwin 1.7.8 is the imminent release of
> > > Service Pack 1 for Windows 7. It seems unwise to release a new Cygwin
> > > package just minutes before a Service Pack comes out. Given the latest
> > > experience that even monthly fixes can come with a nice, hidden gift, I
> > > rather wait for a couple of days and test with SP1 first.
> >
> > Just a heads up, I've been testing the latest snapshot on Win7SP1 x64
> > and have not encountered any issues as of yet in my day-to-day use.
>
> Thank you! I'm running SP1 32 and 64 bit for a couple of days now, too.
> But we all have different usage profiles so I appreciate to get this
> kind of feedback.
>
> If there's nothing else missing, I'm planning to release 1.7.8 on the
> weekend or early next week.
>
Also great here Vista 32...lots of ssh, sftp, ssh port forwarding.
 
Thanks for making it happen...
 
...Karl 		 	   		  

--
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: Please test latest developer snapshot

[Corinna Vinschen]

On Feb 24 09:56, Chris Sutcliffe wrote:
> On 17 February 2011 07:04, Corinna Vinschen wrote:
> > Apart from your testing and our fixing of obvious bugs, the other item
> > holding up the release of Cygwin 1.7.8 is the imminent release of
> > Service Pack 1 for Windows 7.  It seems unwise to release a new Cygwin
> > package just minutes before a Service Pack comes out.  Given the latest
> > experience that even monthly fixes can come with a nice, hidden gift, I
> > rather wait for a couple of days and test with SP1 first.
> 
> Just a heads up, I've been testing the latest snapshot on Win7SP1 x64
> and have not encountered any issues as of yet in my day-to-day use.

Thank you!  I'm running SP1 32 and 64 bit for a couple of days now, too.
But we all have different usage profiles so I appreciate to get this
kind of feedback.

If there's nothing else missing, I'm planning to release 1.7.8 on the
weekend or early next week.


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: Please test latest developer snapshot

[Chris Sutcliffe]

On 17 February 2011 07:04, Corinna Vinschen wrote:
> Apart from your testing and our fixing of obvious bugs, the other item
> holding up the release of Cygwin 1.7.8 is the imminent release of
> Service Pack 1 for Windows 7.  It seems unwise to release a new Cygwin
> package just minutes before a Service Pack comes out.  Given the latest
> experience that even monthly fixes can come with a nice, hidden gift, I
> rather wait for a couple of days and test with SP1 first.

Just a heads up, I've been testing the latest snapshot on Win7SP1 x64
and have not encountered any issues as of yet in my day-to-day use.

Chris

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

--
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: Please test latest developer snapshot

[Thomas Wolff]

Am 21.02.2011 15:16, schrieb Eric Blake:
> On 02/19/2011 11:29 AM, Warren Young wrote:
>   
>> On 2/17/2011 5:04 AM, Corinna Vinschen wrote:
>>     
>>> - Reintroduce the ability to delete an empty directory which is the
>>>    current working directory of the same or another Cygwin process.
>>>       
>> I don't see that.  Testcase:
>>
>>     $ mkdir foo
>>     $ cd foo
>>     $ rmdir .
>>     rmdir: failed to remove `.': Invalid argument
>>     
> POSIX doesn't allow rmdir(2) to succeed if the last component is '.'.
> You have to use rmdir ../foo instead.
>   
And this is not an artificial limitation but there is no way that this
could conceivably work.
By Unix design, removing a file or directory basically means removing
its entry from its parent directory, so it is not an operation on the
file in the first place (or on the target directory in this case).
The parent directory is obviously needed by design, thus "." is not
something that could ever be removed (from where?).
Thomas

--
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: Please test latest developer snapshot

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

On 02/19/2011 11:29 AM, Warren Young wrote:
> On 2/17/2011 5:04 AM, Corinna Vinschen wrote:
>> Hi crowd,
> 
> rabble? angry mob?
> 
>> - Reintroduce the ability to delete an empty directory which is the
>>    current working directory of the same or another Cygwin process.
> 
> I don't see that.  Testcase:
> 
>     $ mkdir foo
>     $ cd foo
>     $ rmdir .
>     rmdir: failed to remove `.': Invalid argument

POSIX doesn't allow rmdir(2) to succeed if the last component is '.'.
You have to use rmdir ../foo instead.

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 619 bytes --]

Re: Please test latest developer snapshot

[Corinna Vinschen]

On Feb 19 13:34, Warren Young wrote:
> On 2/19/2011 11:35 AM, Warren Young wrote:
> >On 2/19/2011 11:29 AM, Warren Young wrote:
> >>$ rmdir .
> >>rmdir: failed to remove `.': Invalid argument
> >
> >Nevermind. It doesn't work on Linux, either. I guess /bin/rmdir has code
> >in it to check for that, which rmdir(2) does not.
> 
> Better test, which does work with 20110215, and which proves it's
> rmdir(1) being too clever, but not so clever it can't be outsmarted:
> 
> 	$ mkdir foo
> 	$ cd foo
> 	$ rmdir ../foo
> 
> Eat that, rmdir(1)!

It's not missing cleverness of rmdir(1) but by design of the rmdir(2)
function per POSIX.  See
http://pubs.opengroup.org/onlinepubs/9699919799/functions/rmdir.html

  "If the path argument refers to a path whose final component is either
   dot or dot-dot, rmdir() shall fail.


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: Please test latest developer snapshot

[Warren Young]

On 2/19/2011 11:35 AM, Warren Young wrote:
> On 2/19/2011 11:29 AM, Warren Young wrote:
>> $ rmdir .
>> rmdir: failed to remove `.': Invalid argument
>
> Nevermind. It doesn't work on Linux, either. I guess /bin/rmdir has code
> in it to check for that, which rmdir(2) does not.

Better test, which does work with 20110215, and which proves it's 
rmdir(1) being too clever, but not so clever it can't be outsmarted:

	$ mkdir foo
	$ cd foo
	$ rmdir ../foo

Eat that, rmdir(1)!

--
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: Please test latest developer snapshot

[Warren Young]

On 2/19/2011 11:29 AM, Warren Young wrote:
> $ rmdir .
> rmdir: failed to remove `.': Invalid argument

Nevermind.  It doesn't work on Linux, either.  I guess /bin/rmdir has 
code in it to check for that, which rmdir(2) does not.

--
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: Please test latest developer snapshot

[Warren Young]

On 2/17/2011 5:04 AM, Corinna Vinschen wrote:
> Hi crowd,

rabble? angry mob?

> - Reintroduce the ability to delete an empty directory which is the
>    current working directory of the same or another Cygwin process.

I don't see that.  Testcase:

	$ mkdir foo
	$ cd foo
	$ rmdir .
	rmdir: failed to remove `.': Invalid argument

cd .. && rmdir foo does work.

> - Core file access functions have been slightly redesigned to gain
>    performance.  Hopefully file access got just a bit faster now...

This is the one that explains the 2.5x faster cygport builds I reported 
during the "rm -rf sometimes fails" thread back in December, I'm guessing?

This looks like a *huge* release, Corinna.  I think you could get away 
with calling it 1.9.0, and nevermind how recent 1.7.0 was.

--
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: Please test latest developer snapshot

[marco atzeri]

On Fri, Feb 18, 2011 at 1:35 PM, Corinna Vinschen  wrote:
> On Feb 17 19:14, marco atzeri wrote:
>> On Thu, Feb 17, 2011 at 1:04 PM, Corinna Vinschen  wrote:
>> > Hi crowd,
>> >
>> >
>> > After the last round of patches we're now heading towards the
>> > 1.7.8 release.  Therefore I'd like to ask you to give the latest
>> > developer snapshot from http://cygwin.com/snapshots/ a try.
>>
>> Corinna,
>>
>> could you check ?
>>
>> $ bunzip2 -tvv cygwin1-20110215.dbg.bz2
>>   cygwin1-20110215.dbg.bz2:
>>     [1: huff+mtf rt+rld]
>>     [2: huff+mtf rt+rld]
>>     [3: huff+mtf rt+rld]
>>     [4: huff+mtf rt+rld]
>>     [5: huff+mtf rt+rld]
>>     [6: huff+mtf rt+rld]
>>     [7: huff+mtf rt+rld]
>>     [8: huff+mtf rt+rld]
>>     [9: huff+mtf rt+rld]
>>     [10: huff+mtf rt+rld]
>>     [11: huff+mtf rt+rld]
>>     [12: huff+mtf file ends unexpectedly
>>
>> You can use the `bzip2recover' program to attempt to recover
>> data from undamaged sections of corrupted files.
>
> I just checked, the file on cygwin.com is not corrupted and I can
> bunzip it on my machine.
>
>
> Corinna
>

Thanks,
it seems a proxy/filter problem in the middle

$ wget http://cygwin.org/snapshots/cygwin1-20110215.dbg.bz2
--2011-02-18 14:29:12--  http://cygwin.org/snapshots/cygwin1-20110215.dbg.bz2
Resolving cygwin.org (cygwin.org)... 209.132.180.131
Connecting to cygwin.org (cygwin.org)|209.132.180.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 2910590 (2.8M) [application/x-bzip2]
Saving to: `cygwin1-20110215.dbg.bz2'

99% [=====================================> ] 2,899,968    183K/s   in 16s

2011-02-18 14:29:30 (175 KB/s) - Connection closed at byte 2899968. Retrying

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: Please test latest developer snapshot

[Corinna Vinschen]

On Feb 17 19:14, marco atzeri wrote:
> On Thu, Feb 17, 2011 at 1:04 PM, Corinna Vinschen  wrote:
> > Hi crowd,
> >
> >
> > After the last round of patches we're now heading towards the
> > 1.7.8 release.  Therefore I'd like to ask you to give the latest
> > developer snapshot from http://cygwin.com/snapshots/ a try.
> 
> Corinna,
> 
> could you check ?
> 
> $ bunzip2 -tvv cygwin1-20110215.dbg.bz2
>   cygwin1-20110215.dbg.bz2:
>     [1: huff+mtf rt+rld]
>     [2: huff+mtf rt+rld]
>     [3: huff+mtf rt+rld]
>     [4: huff+mtf rt+rld]
>     [5: huff+mtf rt+rld]
>     [6: huff+mtf rt+rld]
>     [7: huff+mtf rt+rld]
>     [8: huff+mtf rt+rld]
>     [9: huff+mtf rt+rld]
>     [10: huff+mtf rt+rld]
>     [11: huff+mtf rt+rld]
>     [12: huff+mtf file ends unexpectedly
> 
> You can use the `bzip2recover' program to attempt to recover
> data from undamaged sections of corrupted files.

I just checked, the file on cygwin.com is not corrupted and I can
bunzip it on my machine.


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: Please test latest developer snapshot

[Yaakov (Cygwin/X)]

On Thu, 2011-02-17 at 13:04 +0100, Corinna Vinschen wrote:
> And, btw., if you find that something suddenly starts working better
> using the snapshot, I'd be happy to hear this.  Good news help to
> keep up the spirit.

I had also experienced problems on Win7 x64 after last week's Windows
update, but CVS HEAD is WJFFM again.

> - Raise the size of the default cygheap to 1 MB.  The cygheap is used by
>   Cygwin for internal datastructures which require special handling on
>   fork and/or exec calls.  Since internal datastructures have grown
>   quite a bit since Cygwin 1.7, this step is supposed to avoid some
>   unfortunate out-of-memory problems.

I haven't taken the time to rebuild gcc or qt4 since this patch, but
I'll keep an eye on this when I do next.

Thanks to all involved in the considerable improvements in this release.


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: Please test latest developer snapshot

[Aaron Peromsik]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> 
> And, btw., if you find that something suddenly starts working better
> using the snapshot, I'd be happy to hear this.  Good news help to
> keep up the spirit.
> 

The last snapshot I tested was 20110207, and with that one I still was unable to
start X, as reported here: http://cygwin.com/ml/cygwin/2011-01/msg00365.html

However, with 20100215, startxwin works just fine.

-- Aaron Peromsik


--
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: Please test latest developer snapshot

[marco atzeri]

On Thu, Feb 17, 2011 at 1:04 PM, Corinna Vinschen  wrote:
> Hi crowd,
>
>
> After the last round of patches we're now heading towards the
> 1.7.8 release.  Therefore I'd like to ask you to give the latest
> developer snapshot from http://cygwin.com/snapshots/ a try.

Corinna,

could you check ?

$ bunzip2 -tvv cygwin1-20110215.dbg.bz2
  cygwin1-20110215.dbg.bz2:
    [1: huff+mtf rt+rld]
    [2: huff+mtf rt+rld]
    [3: huff+mtf rt+rld]
    [4: huff+mtf rt+rld]
    [5: huff+mtf rt+rld]
    [6: huff+mtf rt+rld]
    [7: huff+mtf rt+rld]
    [8: huff+mtf rt+rld]
    [9: huff+mtf rt+rld]
    [10: huff+mtf rt+rld]
    [11: huff+mtf rt+rld]
    [12: huff+mtf file ends unexpectedly

You can use the `bzip2recover' program to attempt to recover
data from undamaged sections of corrupted files.


$ ls -l cygwin-inst-20110215.tar.bz2
-rw-------+ 1 Marco Domain_Users 2688345 Feb 17 17:40
cygwin-inst-20110215.tar.bz2


$ uname -a
CYGWIN_NT-5.1 xxxxxxxxxxxxxxx 1.7.8s(0.236/5/3) 20110215 17:49:59 i686 Cygwin

> Corinna
>
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: Please test latest developer snapshot

[Ken Brown]

On 2/17/2011 7:04 AM, Corinna Vinschen wrote:
> [...]
> And, btw., if you find that something suddenly starts working better
> using the snapshot, I'd be happy to hear this.  Good news help to
> keep up the spirit.

emacs users should find that the long-standing timezone problem (see 
/usr/share/doc/Cygwin/emacs.README) has disappeared as a result of the 
following fix:

> - Fix a problem in localtime related to the TZ setting.

Ken

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

Please test latest developer snapshot

[Corinna Vinschen]

Hi crowd,


After the last round of patches we're now heading towards the
1.7.8 release.  Therefore I'd like to ask you to give the latest
developer snapshot from http://cygwin.com/snapshots/ a try.

We're looking for regressions from 1.7.7 in the first place, as well
as for bugs in new features, based on the list of changes at the end
of this mail.  The ideal bugreport contains either a simple testcase
in plain C, or at least a simple way to reproduce the issue.

And, btw., if you find that something suddenly starts working better
using the snapshot, I'd be happy to hear this.  Good news help to
keep up the spirit.

Apart from your testing and our fixing of obvious bugs, the other item
holding up the release of Cygwin 1.7.8 is the imminent release of
Service Pack 1 for Windows 7.  It seems unwise to release a new Cygwin
package just minutes before a Service Pack comes out.  Given the latest
experience that even monthly fixes can come with a nice, hidden gift, I
rather wait for a couple of days and test with SP1 first.

What's new:

- Bad news first:  Running Cygwin now requires at least NT4 SP4.
  Will anybody notice...?

- Reintroduce the ability to delete an empty directory which is the
  current working directory of the same or another Cygwin process.

- Cygwin now ships the C standard library fenv.h header file, and
  implements the related APIs (including GNU/glibc extensions):
  feclearexcept, fedisableexcept, feenableexcept, fegetenv, fegetexcept,
  fegetexceptflag, fegetprec, fegetround, feholdexcept, feraiseexcept,
  fesetenv, fesetexceptflag, fesetprec, fesetround, fetestexcept,
  feupdateenv, and predefines both default and no-mask FP environments.

- Support for C99 complex functions, except for the "long double"
  implementations.  New APIs: cacos, cacosf, cacosh, cacoshf, carg,
  cargf, casin, casinf, casinh, casinhf, catan, catanf, catanh, catanhf,
  ccos, ccosf, ccosh, ccoshf, cexp, cexpf, cimag, cimagf, clog, clogf,
  conj, conjf, cpow, cpowf, cproj, cprojf, creal, crealf, csin, csinf,
  csinh, csinhf, csqrt, csqrtf, ctan, ctanf, ctanh, ctanhf.

- The strerror_r interface now has two flavors; if _GNU_SOURCE is
  defined, it retains the previous behavior of returning char * (but the
  result is now guaranteed to be NUL-terminated); otherwise it now obeys
  POSIX semantics of returning int.

- /proc/sys now allows unfiltered access to the native NT namespace.
  Access restrictions still apply.  Direct device access via /proc/sys
  is not yet supported.  File system access via block devices works,
  though.  So, here's the new interface to your Volume Shadow Copies:

    $ cd /proc/sys/Device/HarddiskVolumeShadowCopy1/

  Specifying the trailing slash is necessary to access the root
  directory, otherwise the access is treated as control access to the
  underlying block special device.

- Other new APIs: llround, llroundf, madvise, pthread_yield.  Export
  program_invocation_name, program_invocation_short_name.
  Support TIOCGPGRP, TIOCSPGRP ioctls.

- Define more recent setsockopt IP_TOS options as on Linux and OpenBSD.

- Raise the size of the default cygheap to 1 MB.  The cygheap is used by
  Cygwin for internal datastructures which require special handling on
  fork and/or exec calls.  Since internal datastructures have grown
  quite a bit since Cygwin 1.7, this step is supposed to avoid some
  unfortunate out-of-memory problems.

Important Bugfixes:

- Fix the width of "CJK Ambiguous Width" characters to 1 for singlebyte
  charsets and 2 for East Asian multibyte charsets. (For UTF-8, it
  remains dependent on the specified language, and the "@cjknarrow"
  locale modifier can still be used to force width 1.)

- Core file access functions have been slightly redesigned to gain
  performance.  Hopefully file access got just a bit faster now...

- On startup, Cygwin now removes enclosing quotes and trailing
  backslashes from Win32 environment path lists which have to be
  converted to POSIX.

- So far all exec functions tried to run a file as shell script under
  /bin/sh if the file type couldn't be recognized.  This has been
  changed per POSIX, so that only the execlp and execvp functions will
  do that.

- Fix a potential stack corruption when using file locking.

- Fix a potential hang in rename(2) due to a sharing violation.

- Fix some problems with tty process groups.

- Make sure that the random number generator is seeded on a per-thread basis.

- Reorganize signal initialization to work around slow process startup on
  some WOW64 systems.

- Try to make dynamic loading of system DLLs more foolproof.  Fix a
  potential stack corruption.

- Fix a synchronization problem in POSIX message queues.

- Fix a problem in localtime related to the TZ setting.

- Make raw disk write access work on Vista and later.

- A thread waiting for a blocking socket call can now be cancled
  using the pthread_cancel call.

- Fix bind(2) behaviour related to SO_REUSEADDR.

- Fix a bug when printing multibyte sequences broken up in multiple
  write calls.

- cygpath now returns more useful Win32 paths for OS-based devices.


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