Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Angelo Graziosi]

Larry Hall wrote:
>> Corinna Vinschen wrote:
>>> - Improve performance of stat and a few other functions.  ls(1) should
>>>   be up to 30% faster
>>
>> I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'.
>>
>> When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files.
>>
>> Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects.
>>
>> The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM.
>
> Try a recent snapshot:
>
> <http://cygwin.com/snapshots/>

I have tried cygwin1-20100820.dll.bz2 and cygwin-inst-20100820.tar.bz2, 
but it is even worse: Cygwin.bat DOES NOT start at all and Windows 
complains with a message like this:

...Cannot find entry point CreateProcessAsUserW in KERNEL32.DLL...

So I have tried with the DLL suggested by Corinna in [*]: Cygwin.bat 
starts, but it shows the same problems I am flagging.

Ciao,
Angelo.

---
[*] http://cygwin.com/ml/cygwin/2010-08/msg00630.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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Corinna Vinschen]

On Aug 21 14:18, Angelo Graziosi wrote:
> Larry Hall wrote:
> >>Corinna Vinschen wrote:
> >>>- Improve performance of stat and a few other functions.  ls(1) should
> >>>  be up to 30% faster
> >>
> >>I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'.
> >>
> >>When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files.
> >>
> >>Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects.
> >>
> >>The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM.
> >
> >Try a recent snapshot:
> >
> ><http://cygwin.com/snapshots/>
> 
> I have tried cygwin1-20100820.dll.bz2 and
> cygwin-inst-20100820.tar.bz2, but it is even worse: Cygwin.bat DOES
> NOT start at all and Windows complains with a message like this:
> 
> ...Cannot find entry point CreateProcessAsUserW in KERNEL32.DLL...

The problem is, there *is* an entry point CreateProcessAsUserW in the
Win32 DLL kernel32.dll.

At least on NT-based systems.  What strikes me as weird is that
kernel32.dll usually is stored with its name in all lowercase letters on
NT-based systems.  The fact that you see an all uppercase KERNEL32.DLL
looks like you have such a DLL in your path, possible from Windows
95/98/Me, possibly installed by some third party stuff, at some point
which is found earlier in the DLL search path than the lowercase
kernel32.dll in C:\Windows\System32.


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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Corinna Vinschen]

On Aug 21 15:48, Corinna Vinschen wrote:
> On Aug 21 14:18, Angelo Graziosi wrote:
> > Larry Hall wrote:
> > >>Corinna Vinschen wrote:
> > >>>- Improve performance of stat and a few other functions.  ls(1) should
> > >>>  be up to 30% faster
> > >>
> > >>I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'.
> > >>
> > >>When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files.
> > >>
> > >>Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects.
> > >>
> > >>The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM.
> > >
> > >Try a recent snapshot:
> > >
> > ><http://cygwin.com/snapshots/>
> > 
> > I have tried cygwin1-20100820.dll.bz2 and
> > cygwin-inst-20100820.tar.bz2, but it is even worse: Cygwin.bat DOES
> > NOT start at all and Windows complains with a message like this:
> > 
> > ...Cannot find entry point CreateProcessAsUserW in KERNEL32.DLL...
> 
> The problem is, there *is* an entry point CreateProcessAsUserW in the
> Win32 DLL kernel32.dll.
> 
> At least on NT-based systems.  What strikes me as weird is that
> kernel32.dll usually is stored with its name in all lowercase letters on
> NT-based systems.  The fact that you see an all uppercase KERNEL32.DLL
> looks like you have such a DLL in your path, possible from Windows
> 95/98/Me, possibly installed by some third party stuff, at some point
> which is found earlier in the DLL search path than the lowercase
> kernel32.dll in C:\Windows\System32.

Oh, and, the call to CreateProcessAsUserW in cygwin1.dll is *old*, as in
"May 2008".  The former call to CreateProcessAsUserA is in Cygwin for
over 10 years.  However, just to be sure I installed the cygwin1-20100820
snapshot DLL on my W7 box and it works fine.  This is quite certainly a
local problem.  
Btw., after downloading cygwin1-20100820.dll.bz2 and bunzipping it, did
you make sure the executable bits are set (chmod +x cygwin1-20100820.dll)?


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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Angelo Graziosi]

Corinna Vinschen wrote:
> I can't reproduce such a problem and I don't have AVG9 (virus scanner?).

Am I indiscreet if I ask you what AV are you using? Just a curiosity...

Anyway thanks for clarification.


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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Angelo Graziosi]

Larry Hall wrote:
>> Corinna Vinschen wrote:
>>> - Improve performance of stat and a few other functions.  ls(1) should
>>>   be up to 30% faster
>>
>> I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'.
>>
>> When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files.
>>
>> Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects.
>>
>> The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM.
>
> Try a recent snapshot:
>
> <http://cygwin.com/snapshots/>

I have tried cygwin1-20100822.dll.bz2, but same results. :(

The first time (no cache 'effects') I do

$ time ls -lrt /usr/bin

the results are:

CYGWIN_NT-5.1  1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin
time ls -lrt /usr/bin
real    0m16.531s
user    0m0.108s
sys     0m0.421s

CYGWIN_NT-5.1  1.7.6(0.230/5/3) 2010-08-16 16:06 i686 Cygwin
real    1m3.171s
user    0m0.155s
sys     0m0.702s

CYGWIN_NT-5.1  1.7.6s(0.231/5/3) 20100822 02:25:11 i686 Cygwin
real    1m4.218s
user    0m0.280s
sys     0m0.609s

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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Corinna Vinschen]

On Aug 22 10:57, Angelo Graziosi wrote:
> Larry Hall wrote:
> >>Corinna Vinschen wrote:
> >>>- Improve performance of stat and a few other functions.  ls(1) should
> >>>  be up to 30% faster
> >>
> >>I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take about 30 seconds to list the files. After the first time, the listing is almost without delay. The same happens also with 'ls -l /usr/bin'.
> >>
> >>When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which 'ls -l' is almost immediate, regardless of the number and type of files.
> >>
> >>Obviously I have tested this, each time, with a 'fresh machine', to avoid 'cache' effects.
> >>
> >>The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM.
> >
> >Try a recent snapshot:
> >
> ><http://cygwin.com/snapshots/>
> 
> I have tried cygwin1-20100822.dll.bz2, but same results. :(
> 
> The first time (no cache 'effects') I do
> 
> $ time ls -lrt /usr/bin
> 
> the results are:
> 
> CYGWIN_NT-5.1  1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin
> time ls -lrt /usr/bin
> real    0m16.531s
> user    0m0.108s
> sys     0m0.421s
> 
> CYGWIN_NT-5.1  1.7.6(0.230/5/3) 2010-08-16 16:06 i686 Cygwin
> real    1m3.171s
> user    0m0.155s
> sys     0m0.702s
> 
> CYGWIN_NT-5.1  1.7.6s(0.231/5/3) 20100822 02:25:11 i686 Cygwin
> real    1m4.218s
> user    0m0.280s
> sys     0m0.609s

I can't reproduce such a problem and I don't have AVG9 (virus scanner?).
The effect is unfortunate, but the only important thing which has
changed in 1.7.6 in terms of readdir and stat is the fact that the code
tries to reduce the number of NtCreateFile/NtOpenFile calls by reusing a
handle already opened on the file or directory before.  I don't know
what Cygwin can do about it, other than dropping the speedup entirely.
Always assuming this is the real cause.  There's no good reason that
AVG9 hangs on anything Cygwin opens at all.  There are only *very* few
cases in which a handle is opened without allowing to share the file,
and if so, it's never doing that for longer than the respective function
call.


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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Angelo Graziosi]

Corinna Vinschen wrote:
> Btw., after downloading cygwin1-20100820.dll.bz2 and bunzipping it, did
> you make sure the executable bits are set (chmod +x cygwin1-20100820.dll)?

Obviously, it is the first thing I thought and checked. To summarize, I 
did the following:

wget http://cygwin.com/snapshots/cygwin1-20100820.dll.bz2
bunzip2 cygwin1-20100820.dll.bz2
chmod +x cygwin1-20100820.dll

and the same for 20100814, 20100816, 20100818 snapshots, and for the DLL 
you propose here

http://cygwin.com/ml/cygwin/2010-08/msg00630.html

Then from a DOS box (but also with Explorer)

cd \cygwin-2\bin
rename cygwin1.dll cygwin1.dll.orig
copy ..\tmp\cygwin1-20100814.dll cygwin1.dll
...

With 20100814, 20100816, 20100818 snapshots and newer-cygwin1.dll, 
Cygwin.bat starts and works.

With 20100820 snapshot Cygwin.bat does not start and Windows says 
(literally):

"Impossibile trovare il punto d'ingresso CreateProcessAsUserW della 
procedura nella libreria di collegamento dinamico KERNEL32.dll"

which Google translates as

"Can not find entry point CreateProcessAsUserW procedure in the dynamic 
link library KERNEL32.dll"

As you can see a mystery...

> The fact that you see an all uppercase KERNEL32.DLL
> looks like you have such a DLL in your path, possible from Windows
> 95/98/Me, possibly installed by some third party stuff, at some point
> which is found earlier in the DLL search path than the lowercase
> kernel32.dll in C:\Windows\System32.

Really the Windows messages says 'KERNEL32.dll' with 'dll' in lowercase, 
and beside this, searching ('all directories visible') 'kernl32', I find 
this:

----------+ 1 root Nessuno 1028608 16 apr  2007 
/WinXP/WINDOWS/$NtServicePackUninstall$/kernel32.dll
-rwxrwx---+ 1 Administrators SYSTEM 1033728 21 mar  2009 
/WinXP/WINDOWS/system32/kernel32.dll
-rwx------+ 1 root Nessuno 1033728 14 apr  2008 
/WinXP/WINDOWS/ServicePackFiles/i386/kernel32.dll
-rwx------+ 1 root Nessuno 1033728 21 mar  2009 
/WinXP/WINDOWS/system32/dllcache/kernel32.dll
----rwx---+ 1 root SYSTEM 1029120  5 lug  2006 
/WinXP/WINDOWS/$hf_mig$/KB917422/SP2QFE/kernel32.dll
----------+ 1 root Nessuno 1030144 16 apr  2007 
/WinXP/WINDOWS/$hf_mig$/KB935839/SP2QFE/kernel32.dll
----------+ 1 root Nessuno 1035776 21 mar  2009 
/WinXP/WINDOWS/$hf_mig$/KB959426/SP3QFE/kernel32.dll

(WinXP is a symlink to /cygdrive/c)

Thanks,
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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Angelo Graziosi]

Corinna Vinschen wrote:
> - Improve performance of stat and a few other functions.  ls(1) should
>   be up to 30% faster

I have a directory (500MB, 30 files) which contains mainly 'exe' (setups 
for TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time 
it take about 30 seconds to list the files. After the first time, the 
listing is almost without delay. The same happens also with 'ls -l 
/usr/bin'.

When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes 
about 50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, 
with which 'ls -l' is almost immediate, regardless of the number and 
type of files.

Obviously I have tested this, each time, with a 'fresh machine', to 
avoid 'cache' effects.

The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM.

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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Larry Hall (Cygwin)]

On 8/20/2010 8:56 PM, Angelo Graziosi wrote:
> Corinna Vinschen wrote:
>> - Improve performance of stat and a few other functions. ls(1) should
>> be up to 30% faster
>
> I have a directory (500MB, 30 files) which contains mainly 'exe' (setups for
> TB, FF, OO etc.). If I try 'ls -l' in this directory, the first time it take
> about 30 seconds to list the files. After the first time, the listing is
> almost without delay. The same happens also with 'ls -l /usr/bin'.
>
> When there is the 'hang' (30 secs.), Task Manager shows that AVG9 takes about
>  50% of CPU: this occurs *only* with 1.7.6 but _not_ with 1.7.5, with which
> 'ls -l' is almost immediate, regardless of the number and type of files.
>
> Obviously I have tested this, each time, with a 'fresh machine', to avoid
> 'cache' effects.
>
> The system is WinXP SP3, AMD Athlon 64X2DC 2.03GHz, 1.75GB RAM.

Try a recent snapshot:

<http://cygwin.com/snapshots/>

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

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

[ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Corinna Vinschen]

Hi Cygwin friends and users,


I just released 1.7.6-1.  This release fixes a bunch of bugs, and
introduces a few new features.   It also contains a change which will
affect calling native Win32 API functions from Cygwin applications.

I would like to urge you to have another look into the documentation
at http://cygwin.com/cygwin-ug-net/cygwin-ug-net.html.  It contains
a couple of improvements and the description for new features and
changes from old behaviour.


What's new since Cygwin 1.7.5:
==============================

- Add new mount options "dos" and "ihash" to allow overriding Cygwin
  default behaviour on broken filesystems not recognized by Cygwin.
  See http://cygwin.com/cygwin-ug-net/using.html#mount-table
  and http://cygwin.com/cygwin-ug-net/using-utils.html#mount

- Add new mount option "bind" to allow remounting parts of the POSIX file
  hirarchy somewhere else.
  See http://cygwin.com/cygwin-ug-net/using.html#mount-table
  and http://cygwin.com/cygwin-ug-net/using-utils.html#mount

- Ttys and ptys are handled as securable objects using file-like
  permissions and owner/group information.  chmod and chown now work on
  ttys/ptys.  A new mechanism is used to propagate pty handles safely to
  other processes, which does not require to use Cygserver.

- Pass on coresize settings made with setrlimit(2).  This allows
  shells to disable creating stackdump files in child processes via
  `ulimit -c 0' in bash or `limit coredumpsize 0' in tcsh.

- Locale categories contain all localization strings additionally as
  wide-char strings.  locale(1) prints these values just as on Linux.
  nl_langinfo(3) allows to fetch them.  See file:///usr/include/langinfo.h

- New interfaces mkostemp(3) and mkostemps(3).
  See file:///usr/include/stdlib.h

- New virtual file /proc/filesystems.

- clock_gettime(3) and clock_getres(3) accept CLOCK_MONOTONIC.

- Several small additions to header files.


What changed since Cygwin 1.7.5:
================================

- Cygwin handles the current working directory entirely on its own.  The
  Win32 current working directory is set to an invalid path to be out of
  the way.  This affects calls to the Win32 file API (CreateFile, etc.).
  See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api

- Change the way a process is made process group leader in case we're
  started from a non-Cygwin process.  This isn't foolproof and may need
  more work.

- Workaround a BLODA problem in rename(2) which otherwise results in
  annoying errors.

- Add more workarounds for broken filesystems which either don't grok
  reopening a file by handle (NWFS) or which are not capable of handling
  filenames with leading spaces or trailing dots or spaces (NWFS,
  Netapp).

- Don't try to evaluate reparse points (junctions) on remote filesystems
  as symlinks.

- Improve performance of stat and a few other functions.  ls(1) should
  be up to 30% faster on some drives.

- Speed up signal delivery slightly.

- Improve error output in strace.

- cygwin_conv_path now drops the "\\?\" prefix from short paths it returns
  with CCP_POSIX_TO_WIN_W.


Bugfixes since Cygwin 1.7.5:
============================

- Fix problem where pseudo-relocs were getting applied twice, resulting
  in a crash.

- Fix a crash when accessing /proc/registry*

- Avoid that connect on a not yet established AF_LOCAL/AF_UNIX
  socket misinterprets the socket file as non-socket.

- Fix stdin/out/err handle permissions when called from a non-Cygwin
  process.

- Fix codeset problem in internal handling of process name.

- Fix abbreviated month names for japanese and korean locale.

- Fix calls to gettimeofday after call to settimeofday.

- Fix REG_MULTI_SZ handling in /proc/registry*

- Honor cygwin username even if it only differs by case from Windows
  username.

- Fix potential memory leak when accessing // or //server directories.

- Fix using a wrong handle when checking for files inaccessible to
  current user.

- Fix erroneous handling of devices in path checking.

- Fix potential crash in exec(2) if parent uses file locking.

- Return useful error code when writing beyond free space on disk.

- Fix longstanding bug where pipe() would inappropriately reuse open fd's.

- Fix several signal races which caused SEGVs.

- Fix long-standing bug when trying to open an already opened pipe
  via /proc/$PID/fd/...

- Fix a potential crash when calling "mount -a".

- Fix bug in math functions lround(), llround(), lrint(), llrint().


Have fun,
Corinna


              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe: " tag in the email header of this message.
Send email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@cygwin.com

If you need more information on unsubscribing, start reading here:

http://cygwin.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Buchbinder, Barry (NIH/NIAID) [E]]

Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:16 AM
>What changed since Cygwin 1.7.5:
>================================
>
>- Cygwin handles the current working directory entirely on its own.  The
>  Win32 current working directory is set to an invalid path to be out of
>  the way.  This affects calls to the Win32 file API (CreateFile, etc.).
>  See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api
                         ^^^^^

In case you ever copy and paste the link, "htdocs/" needs to be deleted
for it to work.

Thanks for all you do for the cygwin community.

- Barry
  Disclaimer: Statements made herein are not made on behalf of NIAID.

Re: [ANNOUNCEMENT] Updated: cygwin-1.7.6-1

[Corinna Vinschen]

On Aug 18 22:00, Buchbinder, Barry (NIH/NIAID) [E] wrote:
> Corinna Vinschen sent the following at Tuesday, August 17, 2010 4:16 AM
> >What changed since Cygwin 1.7.5:
> >================================
> >
> >- Cygwin handles the current working directory entirely on its own.  The
> >  Win32 current working directory is set to an invalid path to be out of
> >  the way.  This affects calls to the Win32 file API (CreateFile, etc.).
> >  See http://cygwin.com/htdocs/cygwin-ug-net/using.html#pathnames-win32-api
>                          ^^^^^
> 
> In case you ever copy and paste the link, "htdocs/" needs to be deleted
> for it to work.

Ouch!  Thank you for the hint.  Actually that "htdocs" is a part of the
URL to the Cygwin docs on my private web server.  I hope I don't screw
up again in the next announcement...


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