Re: cygcheck -f ... misleading as to file ownership & no relative paths

[Brian Dessent <brian at dessent dot net>]

Linda Walsh wrote:

> I understand why cygcheck doesn't ID the files in "/etc", and "/etc/ssh",
> but it's problematic -- since I don't know for certain which files
> ssh is compiled to use...  If I had to guess, I'd go for /etc/ssh/...,
> but "cygcheck" doesn't even classify that directory as "owned" by
> the openssh package.

It doesn't know about them because the package manager doesn't own
them.  The user owns them, the package manager must never touch config
files that the user has edited.  That is why packages should only
contain configs located in the defaults skeleton.  The usual route is a
preremove script that removes the copy in /etc if it compares the same
as the one in the skeleton, coupled with a postinstall that installs the
skeleton one in /etc if one does not exist.  The end result: if a user
does not edit the file, it gets upgraded with the package.  But if it
was changed at all, hands off.

If you want to know what the proper location for ssh_config is, I
suggest "man ssh_config" which will tell you that it should be
/etc/ssh_config.  I don't know where this /etc/ssh directory came from. 
If there isn't a man page, look at the postinstall.

>         Two executable "hosts" files?  I ran across this
> with another file and one was a .lnk file.  But for whatever
> reason, it doesn't show up with a "@".  When I deleted the .lnk
> file (under cmd.exe), I couldn't recreate the effect, since
> "ln -s file file", fails with an "already exists" error message.

There are two kinds of symlinks: the old style which consist of a file
with the same name as the link and the 'S' attribute; and the new style
which consists of an explorer shortcut (link name plus .lnk) with the
'R' attribute set.  If the attribute in either case is not set the file
will no longer be seen as a symlink by Cygwin, but rather as the normal
file that it really is.  (A somewhat strange consequence of this is that
any old file whose name happens to end in .lnk can also be accessed with
the filename minus .lnk.)

The Cygwin DLL can obviously read both style symlinks, but it only
creates the new style unless you set nowinsymlinks in $CYGWIN.  And so
programs that access symlinks through the DLL (i.e. almost everything:
ln, ls, etc.) will behave in the same way.

The setup.exe program however doesn't use the DLL and only really knows
about old-style symlinks.  This means that when setup is extracting
files from the tarball and encounters a symlink, if there happens to
exist already a new-style symlink of the same name it will be oblivious
to it and will create a second (old-style) symlink of the same name. 
That is how you get two files of the same name, and why you can't
recreate it with ln.  There is some support in setup already for knowing
about .lnk shortcuts when uninstalling, so most of the time this should
be irrelevant as the new-style symlink would have been removed during
the uninstall phase.  This aspect of setup is in need of some serious
TLC though.

Brian

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