This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: man.conf missing after cygwin upgrade


Ron,

Please make sure your mailer respects the Reply-To: header -- I set it for
a reason.  There's no need to Cc: me on the messages, as I read the list.

On Tue, 5 Jul 2005, FischRon.external wrote:

> > On Mon, 4 Jul 2005, FischRon.external wrote:
> >
> > > Now I checked /usr/share/misc and found that it has permissions 000.
> > > I chmod the permissions to 0777. Also I found that /usr/share/misc
> > > is empty, i.e. there is no file man.conf in it.
> >
> > Ah, that could be the reason -- permissions 000 would make the
> > postinstall script fail when copying the man.conf file from its
> > default location.
>
> I found that all in a while, a file created under cygwin ends up
> with permission 000...

This usually indicates wrong directory permissions on higher-level
directories.  Could you please post the output of "getfacl /usr /usr/share
/usr/share/misc" (seeing as you've already posted the output of "getfacl
/").

> > If you haven't run setup since upgrading man, see if
> > /var/log/setup.log.full has any messages from /etc/postinstall/man.sh.
>
> Nothing useful. man.sh is mentioned only once:
>
>     Installing file cygfile:///etc/postinstall/man.sh

Very weird.  So the postinstall script didn't run?

> man.conf is mentioned in several directories, such as
>
>    Installing file cygfile:///usr/share/man/pt/man5/man.conf.5
>
> but never in /usr/share/misc (where man is obviously looking for it).

Right, because it's copied to /usr/share/misc by the postinstall script
(to avoid overwriting user changes, if any).

> The only thing which might look like an error message does not seem
> related to the man problem:
>
>    2005/07/04 12:27:54 zsh
>    2005/07/04 12:27:54 running: C:\cygwin\bin\sh.exe -c /etc/postinstall/base-files-mketc.sh
>    Unknown system type ; exiting

That's even weirder.  What does "uname -a" show?  You should not get that
message on Win2k Pro (as your previously attached cygcheck output
indicates).

> > You should re-run /etc/postinstall/man.sh.done
>
> I guess you mean: /etc/postinstall/man.sh  - there is no file
> /etc/postinstall/man.sh.done

No, I meant /etc/postinstall/man.sh.done, since I didn't realize that the
postinstall script didn't run.  If you still haven't run setup since that
fateful man installation (or if you kept a separate copy of it), please
post /var/log/setup.log.full to the list -- something weird happened
during your install, and, hopefully, the log will show it.

> This went very quickly, and it created the file:
>
>    /etc/postinstall $ man.sh
>    Using the default version of /usr/share/misc/man.conf (/etc/defaults/usr/share/misc/man.conf)
>    /etc/postinstall $ ls -l /usr/share/misc/man.conf
>    -rw-r--r--  1 fischron mkgroup_l_d 4576 Jul  5 08:46 /usr/share/misc/man.conf
>
> and now the error message on invoking man does not appear anymore.
>
> Thank you for helping!

Glad it helped.  This still doesn't explain why the postinstall script
didn't run, however.

> > Now that your /usr/share/misc has better permissions, future man
> > upgrades should work.  If I were you, I'd investigate *why*
> > /usr/share/misc ended up with 000 permissions in the first place (it's
> > created by setup.exe using the inherited Windows permissions -- are
> > the ACLs on / too strict?).
>
> As far I can tell, they look fine:
>
> $ getfacl /
> # file: /
> # owner: Administrators
> # group: mkgroup_l_d
> user::rwx
> group::rwx
> group:SYSTEM:rwx
> mask:rwx
> other:rwx
> default:user:Administrators:rwx
> default:group:SYSTEM:rwx
> default:mask:rwx

Hmm, hopefully the Cygwin security experts will chime in here.  All I can
tell is the fact that the directory is owned by a group, and that you have
default permissions, looks suspicious.  Does your /etc/passwd contain the
Administrators user?

> I found that files with permission 000 are sometimes created when we run
> build scripts via ant. Just in case you are not familiar: ant is a tool
> for producing applications (used for similar tasks as one would use
> make), which is used a lot by Java developers. ant is a Java
> application, but of what I have seen, it uses the cygwin library
> (because it is platform independent). In most cases, things work fine,
> but sometimes, certain files are created with 000. We have never found
> out why this happens, and regularly do a chmod afterwards.

Must be something on your system -- probably some directory has weird
permissions which are inherited.  For the record: ant doesn't use any
Cygwin libraries, except that the invocation script uses /bin/sh.  Once
ant is invoked, it's a pure Java application.  Files created by Java
follow Windows permission inheritance rules.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]