Some "interesting" changes checked in

Corinna Vinschen
Tue Mar 6 05:07:00 GMT 2001

On Mon, Mar 05, 2001 at 01:34:58AM -0500, Christopher Faylor wrote:
> I've checked in some changes that may destabilize things for a while
> until the bugs have been wrung out.
> 1) Changed CTRL-Z handling so that tty handler recognizes when a signal
>    has been sent and exits appropriately.
> 2) Cleaned up extension scanning in symlink_info::check.  I've been slowly
>    cleaning up this routine and Corinna's addition of .lnk scanning prompted
>    me to work on this a little more.
> 3) Eliminated the ReadFile (this topic was all the rage in the cygwin mailing
>    list a while ago) unless the program using cygwin needs to check for the
>    executable bit.  This requires a recompilation to operate correctly.
> The one that is probably most iffy is 2.  I really redesigned things and
> everything seemed to work the first time.  That's usually a symptom that
> I got something horribly wrong somewhere and I just don't remember one
> of the parameters to the problem.  It does seem to scan .exe extensions
> correctly and correctly default to finding .lnk when appropriate,
> though.

Your patch has broken readdir's ability to drop the .lnk suffix.
The problem is that in symlink::check the call to suffix.lnk_match()
only sets sym_check to 1 when has added the .lnk suffix
by itself but not when it's already given in the input file name. This
results in a weird behaviour.


cd /
mkdir foo
cd ~
ln -s /foo
ls -l foo
	-> results in `lrwxrwxrwx ... foo -> /foo      <- OK
ls -l foo.lnk
	-> results in `lrwxrwxrwx ... foo.lnk -> /foo  <- OK
ls -l
	-> results in `lrwxrwxrwx ... foo.lnk -> /foo  <- Wrong
cd foo
	-> works                                       <- OK
cd ~
cd foo.lnk
	-> results in `foo.lnk: Not a directory.'      <- Wrong

The error is in suffix_scan::has. The order of the conditionals
disallows .lnk suffixes for input files when in_suffixes is NULL.

I have checked in a patch.


Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                      
Red Hat, Inc.

More information about the Cygwin-developers mailing list