This is the mail archive of the
mailing list for the Cygwin project.
Re: cron in cygwin
> > cygrunsrv: unknown option -- D
> Bill, did you use the *exact* line from /usr/doc/Cygwin/cron.README?
No. Looks like you are right. "cron" does have a -D option, even though
the cron man page doesn't mention one.
> > > Regarding your "NOTE 1" below -- is it reproducible? Could you please
> > > post the output of "getfacl filename" before and after "chown
> > > Perhaps Pierre or Corinna could comment on this?
> > It reproduces 100% of the time. I've tried it on several different
> > as well..
> Looks fine to me. What error do you get if you try "echo 'hi' >> foo.txt"
> after that? What if you try it from a SYSTEM-owned shell?
Yesterday, "EPERM". Today nothing. It no-longer reproduces. I've actually
spent several hours trying to figure out why previously the problem occurred
on multiple machines, with 100% reproducibility, and even cause many of my
attempted daemon installs to fail until I found workarounds.
It turns out the problem is I used an old Unix trick to "su". Under XP Home
edition, the "SYSTEM"
account does not have a password assigned, and the "passwd" command fails to
assign a password
to it. Consequently "login" does not work for logging in as SYSTEM. The
"su" command also fails
do to the way setuid is implemented under XP. However, the old hackers
trick is if you have write
access to the /etc/passwd file, just change the UID of an account you can
login to, and make sure that
account is listed after the real account. So, I changed "docbill" to UID
18. Walla, when I start a new
console, I am SYSTEM. Then I just edit the UID back to normal, for my next
However, after I used that trick a few times I realized under CYGWIN the
trick doesn't really work.
Even though the "id" command will identify me as SYSTEM, and all the files I
create will be listed as
owned by SYSTEM. When a cygrunsrv daemon tries to read one of those files
it gets an EPERM
command. The same thing happens when I use that trick to switch between
user accounts. So I exited the consoles with the modified UID and stopped
using that trick. (Instead I set up a home directory and .ssh/authorized
files for use with 'ssh' to do the equivalent of an su.)
Several days later, I notice "chown" doesn't work correctly. And the
problem exists on multiple
machines. Guess what? It appears the effects of the bogus UID trick
continue to have effects on
the chown command and other file permission commands until the next reboot.
Last night we had
a bad storm, so I shut all the computers down. Today there is no more chown
problem... Just a bunch of files with questionalable permissions that I
need to do a setfacl command on to make sure
the permissions really are what they claim to be.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html