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/
