The road to 1.3.11 -- please try the latest snapshot

[Christopher Faylor]

I'm close to releasing cygwin 1.3.11 but I need feedback on the current
state of cygwin. So, please try a snapshot at:

http://cygwin.com/snapshots/

To install a snapshot:

1) Download the latest cygwin-20020???.dll.bz2 file from the above
web page into a temporary directory.

2) bunzip2 cygwin-20020???.dll.bz2

3) copy c:\cygwin\bin\cygwin1.dll c:\cygwin\bin\cygwin1.dll.saf

4) copy cygwin-20020???.dll c:\cygwin\bin\cygwin1.dll

Obviously, you have to replace the 'c:\cygwin\bin' with the ms-dos path
name of your /bin directory. You also *must* use Windows tools (e.g.,
"copy" or GUI "drag and drop") to copy the DLL to its new home since you
can't easily overwrite a busy DLL.

Reports of success or failure to the list, please.

AFAIK, there are still two things left to do prior to release 1) fix the
gettimeofday problem and 2) complete the review and possible
incorporation of some outstanding pthreads patches.

If there are other outstanding patches that need review please report
them here.

cgf

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Pavel Tsekov]

CF> Reports of success or failure to the list, please.

First of all I decided to try the new /proc filesystem - here are some
things I have noticed and haven't seen them reported to the list so
far (or I missed them):

1. Under /proc and /proc/registry you can "cd" to unexisting directories.

***@MORDOR ~
$ cd /proc/not_existing_dir

***@MORDOR /proc/not_existing_dir
$ ls -l
ls: .: Not a directory

***@MORDOR /proc/not_existing_dir

Now if tou type "cd .." you get:

***@MORDOR /proc/non_existing_dir
$ cd ..

***@MORDOR /proc/non_existing_dir/..
$ ls
104 140 1796 loadavg registry uptime
1144 1428 328 meminfo stat version

***@MORDOR /proc/non_existing_dir/..
$ cd ..

***@MORDOR /proc/non_existing_dir/../..
$ ls
bin cygwin.ico home sbin test_mds_7.bpr usr
cygwin.bat etc lib sys tmp var

2. Deleting a directory under /proc/registry/ takes
enormous time if this directory has subdirectories. I tried to
trace with strace since first I thought that some kind of infinite
loop causes this behaviour, but then it turned out that "rm" is actually
working - it just takes too much time to complete ... Most of the time
is spent in the cygwin internal path conversion routines, trying to
convert the POSIX path representation of the registry key/data into
Win32 path name.

Yes, I know this is read-only file system :)


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Chris January]

Post by Pavel Tsekov
CF> Reports of success or failure to the list, please.
First of all I decided to try the new /proc filesystem - here are some
things I have noticed and haven't seen them reported to the list so
1. Under /proc and /proc/registry you can "cd" to unexisting directories.

What is your CYGWIN environment variable set to?

Chris





--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Pavel Tsekov]

Post by Pavel Tsekov
1. Under /proc and /proc/registry you can "cd" to unexisting directories.

CJ> What is your CYGWIN environment variable set to?

***@MORDOR ~
$ echo $CYGWIN
binmode tty ntsec codepage:oem


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Christopher Faylor]

Post by Pavel Tsekov
CF> Reports of success or failure to the list, please.
First of all I decided to try the new /proc filesystem - here are some
things I have noticed and haven't seen them reported to the list so
1. Under /proc and /proc/registry you can "cd" to unexisting directories.
$ cd /proc/not_existing_dir
$ ls -l
ls: .: Not a directory
$ cd ..
$ ls
104 140 1796 loadavg registry uptime
1144 1428 328 meminfo stat version
$ cd ..
$ ls
bin cygwin.ico home sbin test_mds_7.bpr usr
cygwin.bat etc lib sys tmp var

cd'ing to a nonexistent directory should now be fixed, i.e., it should
not be possible to do so.

Post by Pavel Tsekov
2. Deleting a directory under /proc/registry/ takes
enormous time if this directory has subdirectories. I tried to
trace with strace since first I thought that some kind of infinite
loop causes this behaviour, but then it turned out that "rm" is actually
working - it just takes too much time to complete ... Most of the time
is spent in the cygwin internal path conversion routines, trying to
convert the POSIX path representation of the registry key/data into
Win32 path name.
Yes, I know this is read-only file system :)

I didn't look at this one. Maybe Chris J will have some insight.

Thanks for the report.
cgf

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Pavel Tsekov]

Hello Christopher,

Saturday, June 01, 2002, 4:48:19 AM, you wrote:

[snip]

Post by Pavel Tsekov
2. Deleting a directory under /proc/registry/ takes
enormous time if this directory has subdirectories. I tried to
trace with strace since first I thought that some kind of infinite
loop causes this behaviour, but then it turned out that "rm" is actually
working - it just takes too much time to complete ... Most of the time
is spent in the cygwin internal path conversion routines, trying to
convert the POSIX path representation of the registry key/data into
Win32 path name.
Yes, I know this is read-only file system :)

CF> I didn't look at this one. Maybe Chris J will have some insight.

Here is something else I want to share - it may be connected to the
above problem, though I think its not (or not entirely).

Anyone who wants to experience it can try this:
ls -l /proc/registry/HKEY_CLASSES_ROOT

The point is to select a key (directory) with many entries under it.

This takes an enormous time to complete - I've debugged the problem
and I think I've found the culprit though I'm not sure about the
solution. The problem lies in fhandler_registry::exists - this is
called by fhandler_registry::fstat, which is called by stat_worker.
ls -l uses lstat call to gather various information about the directory
components it processes - this is why the problem would show only if one
passes the -l option and not otherwise.

So, fhandler_registry::exists() will call RegEnumKeyEx until it exausts
all entries in a given directory, hits an error or it finds the entry it is
looking for... The whole search is done for every single entry from the
beginning... So consider that you have 3000+ entries in HKEY_CLASSES_ROOT
(as on my machine)...

Ok now - there is this comment in at the start
fhandler_registry::exists().. Could someone sched more light (Chris J
maybe :) ) why is this necessary ? Any links pointers would be
appreciated... I havent searched too hard the MSDN but there doesnt
seem to be too much info on the securiy of the registry :(

Here is the comment I refer to:

/* Returns 0 if path doesn't exist, >0 if path is a directory,
* <0 if path is a file.
*
* We open the last key but one and then enum it's sub-keys and values to see if
the
* final component is there. This gets round the problem of not having security
access
* to the final key in the path.
*/


So if we could avoid the RegEnumEntryEx thing i.e. just use
RegOpenKeyEx this would speed up the process very much.


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Chris January]

Post by Pavel Tsekov
Ok now - there is this comment in at the start
fhandler_registry::exists().. Could someone sched more light (Chris J
maybe :) ) why is this necessary ? Any links pointers would be
appreciated... I havent searched too hard the MSDN but there doesnt
seem to be too much info on the securiy of the registry :(
/* Returns 0 if path doesn't exist, >0 if path is a directory,
* <0 if path is a file.
*
* We open the last key but one and then enum it's sub-keys and values to see if
the
* final component is there. This gets round the problem of not having security
access
* to the final key in the path.
*/
So if we could avoid the RegEnumEntryEx thing i.e. just use
RegOpenKeyEx this would speed up the process very much.

You're right, it would speed things up considerably.
The reason I did things that way is because a key, for which you have enum
permissions, may have a subkey for which you have no permissions at all (and
so would fail on RegOpenKeyEx).
In retrospect, the correct implementation is to try RegOpenKeyEx first, then
try the enum method if and only if RegOpenKeyEx fails with
ERROR_ACCESS_DENIED. I will try to make a patch for this as soon as a I have
a free minute (not easy at present). Alternatively feel free to submit your
own patch once your copyright assignment has been received by Red Hat.
Please note I haven't looked at your patch for unlink or rmdir and won't do
so until your assignment has been received. That way I can generate my own
patch with the same functionality if need be.

Regards
Chris



--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[David Starks-Browning]

Post by Christopher Faylor
I'm close to releasing cygwin 1.3.11 but I need feedback on the current
http://cygwin.com/snapshots/
1) Download the latest cygwin-20020???.dll.bz2 file from the above
web page into a temporary directory.
2) bunzip2 cygwin-20020???.dll.bz2
3) copy c:\cygwin\bin\cygwin1.dll c:\cygwin\bin\cygwin1.dll.saf
4) copy cygwin-20020???.dll c:\cygwin\bin\cygwin1.dll

On NT4 with CYGWIN=ntsec, I found it necessary to right-click on
c:\cygwin\bin\cygwin1.dll in explorer, properties, permissions,
and grant read-access to everyone. Before I did that, I got
"application failed to initialize" error pop-up whenever I tried to
invoke any Cygwin application.

It might not happen to everyone, and it has come up on the list
before. But I thought it worth mentioning, in case others encounter
this and would otherwise be quite confused.

Beyond that, with this snapshot, I have no trouble doing the things I
normally do on NT4. (inetd, sshd, xemacs, rsync)

Thanks,
David


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Gerrit P. Haase]

Hallo Christopher,

Post by Christopher Faylor
I'm close to releasing cygwin 1.3.11 but I need feedback on the current
http://cygwin.com/snapshots/

I just finished a build of the upcoming perl-5.8 release candidate.
AFAICT no problems with the snapshot dll (importlib & headers also installed).

Gerrit

[Christopher Faylor]

Post by Gerrit P. Haase
Hallo Christopher,

Post by Christopher Faylor
I'm close to releasing cygwin 1.3.11 but I need feedback on the current
http://cygwin.com/snapshots/

I just finished a build of the upcoming perl-5.8 release candidate.
AFAICT no problems with the snapshot dll (importlib & headers also installed).

Thanks for the report. I'm generating a new snapshot now that fixes some of
the reported bugs. I'm glad that it worked for you.

cgf

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Jens Kessmeier]

Many thanks to Egor Duda for changing checks for
connectionless sockets. Logging to syslogd is working.

Thanks to Christopher Faylor for the outstanding fix of gettimeofday.
This will solve my ntpd jitter.

Here are 2 things I mailed two times in the past.

1) Behavior

Description:

(a) Telnet session from system A to cygwin system B
(b) Type telnet escape char and quit, or kill telnet
(c) Another telnet session from system A to cygwin system B
(d) On system B telnetd of step (a) is gone, user shell (a) is running

Process list on system B after (a):

UID PID PPID TTY STIME COMMAND
admin 95 1 ? Feb 14 /usr/sbin/syslogd
admin 114 1 ? Feb 14 /usr/local/bin/ntpd
admin 133 1 ? Feb 14 /usr/sbin/cron
admin 142 1 ? Feb 14 /usr/sbin/inetd
admin 425 1 ? Feb 17 /usr/sbin/sshd
admin 256 142 ? 17:09:13 /usr/libexec/in.telnetd
admin 94 256 0 17:09:17 /bin/bash <-
admin 303 94 0 17:09:34 /usr/bin/ps

Process list on system B after (c):

UID PID PPID TTY STIME COMMAND
admin 95 1 ? Feb 14 /usr/sbin/syslogd
admin 114 1 ? Feb 14 /usr/local/bin/ntpd
admin 133 1 ? Feb 14 /usr/sbin/cron
admin 142 1 ? Feb 14 /usr/sbin/inetd
admin 425 1 ? Feb 17 /usr/sbin/sshd
admin 94 1 0 17:09:17 /bin/bash <- ?
admin 277 142 ? 17:12:20 /usr/libexec/in.telnetd
admin 99 277 1 17:12:24 /bin/bash
admin 65 99 1 17:12:34 /usr/bin/ps

2) Behavior

Description:

(a) bash> /sys/winnt/system32/ping -t somehost
(b) Type CRTL-Z -> nothing happened (i know).
(c) Type CTRL-C -> ping is still running. <- ?


Help me to understand 1) and 2) ?

No thanks for your filter, this is the fifth try.



--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Alan Dobkin]

With this snapshot, if I cd to a /proc/{PID} and run
less * or more *, I get "Segmentation fault (core dumped)".
The two stackdump files are attached.

Alan

--On Wednesday, May 29, 2002 11:22 PM -0400 Christopher Faylor

Post by Christopher Faylor
I'm close to releasing cygwin 1.3.11 but I need feedback on
http://cygwin.com/snapshots/

[Christopher Faylor]

With this snapshot, if I cd to a /proc/{PID} and run less * or more *,
I get "Segmentation fault (core dumped)". The two stackdump files are
attached.

I never got a core dump but I did get some interesting behavior.
It seems like /cygdrive had the same problem.

This should be fixed in the next snapshot.

Thanks for the report.
cgf

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Conrad Scott]

Generally, the latest releases have been fine for me (CVS HEAD on a w2k
box). I'm running the latest beta of XEmacs compiled under cygwin as well as
various other tools for daily use.

The only strangeness I've noticed has been in opening /proc with dired in
XEmacs. In the current (as this email) CVS HEAD version of cygwin, XEmacs
shows all the entries in /proc but gives me the error "No file on this line"
if I try to open any of them. If I explicitly visit (via C-x C-f) one of the
files in /proc, /proc/uptime for example, it opens but I get an empty file.
Also the /proc/registry part can be navigated by trying to explicitly visit
files in it but again these are always empty.

All these things work fine for me using standard utilities from within the
shell.

I could try and do some tracing if that would help.

// Conrad




--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Conrad Scott]

Post by Conrad Scott
The only strangeness I've noticed has been in opening /proc with dired in
XEmacs. In the current (as this email) CVS HEAD version of cygwin,
XEmacs shows all the entries in /proc but gives me the error "No file on
this line" if I try to open any of them.

Okay: red face time: dired is broken in xemacs 21.5-b6 for *everything*, and
so it's *nothing* to do with /proc. The other problem about all the files
opening
as empty might be an issue but I'm busy building a more stable version of
XEmacs to test it.

Sorry for the false alert.

// Conrad



--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Christopher Faylor]

Post by Conrad Scott

Post by Conrad Scott
The only strangeness I've noticed has been in opening /proc with dired in
XEmacs. In the current (as this email) CVS HEAD version of cygwin,
XEmacs shows all the entries in /proc but gives me the error "No file on
this line" if I try to open any of them.

Okay: red face time: dired is broken in xemacs 21.5-b6 for *everything*, and
so it's *nothing* to do with /proc. The other problem about all the files
opening
as empty might be an issue but I'm busy building a more stable version of
XEmacs to test it.
Sorry for the false alert.

Don't worry about it. I looked into this and found some problems with
the stat() code for virtual devices (cygdrive, proc), so, even if this
doesn't pan out, there was benefit.

cgf

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Conrad Scott]

Post by Christopher Faylor

Post by Conrad Scott
Okay: red face time: dired is broken in xemacs 21.5-b6 for *everything*,
and so it's *nothing* to do with /proc. The other problem about all the

files

Post by Christopher Faylor

Post by Conrad Scott
opening as empty might be an issue but I'm busy building a more stable
version of XEmacs to test it.
Sorry for the false alert.

Don't worry about it. I looked into this and found some problems with
the stat() code for virtual devices (cygdrive, proc), so, even if this
doesn't pan out, there was benefit.

I'm glad that I didn't waste your time.

I've now got a copy of XEmacs 21.4.8 (a reasonably stable version) compiled
under cygwin and I'm getting strange results in /proc that are confusing me
(it must be time for bed).

One thing that seems reasonably clear (and maybe you've just fixed this), is
that XEmacs seems to think that any non-existent file inside the /proc/<pid>
directories is itself a directory. (How it can think that of a non-existent
file I don't know.) So opening /proc/<pid>/foo gives dired error messages
from XEmacs, i.e. it thinks that foo is a directory.

Anyhow, definitely time for bed, so goodnight everyone (wherever the sun may
be for you).

// Conrad



--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Christopher Faylor]

Post by Conrad Scott
One thing that seems reasonably clear (and maybe you've just fixed this), is
that XEmacs seems to think that any non-existent file inside the /proc/<pid>
directories is itself a directory. (How it can think that of a non-existent
file I don't know.) So opening /proc/<pid>/foo gives dired error messages
from XEmacs, i.e. it thinks that foo is a directory.

Nope, I didn't fix this. You can see the same behavior with ls -l
/proc/<pid>/foo . I'll look into it.

(Unless ChrisJ beats me to it)

Thanks,
cgf

--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Chris January]

Post by Christopher Faylor

Post by Conrad Scott
One thing that seems reasonably clear (and maybe you've just fixed this), is
that XEmacs seems to think that any non-existent file inside the /proc/<pid>
directories is itself a directory. (How it can think that of a non-existent
file I don't know.) So opening /proc/<pid>/foo gives dired error messages
from XEmacs, i.e. it thinks that foo is a directory.

Nope, I didn't fix this. You can see the same behavior with ls -l
/proc/<pid>/foo . I'll look into it.
(Unless ChrisJ beats me to it)

There's a line that went missing in fhandler_process.cc that causes the
empty file problem.

Chris



--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/

[Pavel Tsekov]

While trying to debug the slowdown which happens when doing a "rm -rf"
on a directory under /proc/registry/ I noticed the following thing..

My working directory is a directory under the proc hierarchy - in this
case it was /proc/registry/HKEY_CLASSES_ROOT. If I start gdb in this
directory and start debugging, the debug session thinks that the
current directory is the last directory I was in, before I've changed
the cwd to /proc/something. The same for strace.


--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/