Re: cron on Win9x works

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Fri, 11 Apr 2003, BB wrote:

> Igor,
> ----------------------
> cron/crontab on win9x:
>
> I don't think there is any way to change a directory's creation time on
> Win9x, so cron cannot be signalled to read the new tabs.  The CreatFile flag
> FILE_FLAG_BACKUP_SEMANTICS is what does it on NT/2K/XP.
> According to the MSDN, the flag is not supported on Win9x.

According to MSDN, you cannot open a directory using CreateFile at all on
Win9x.  You should use CreateDirectory.

> Based on the cron code, if cron detects a more recent timestamp on the
> file "/etc/crontab", the directories "etc/cron.d" or /var/cron/tabs", or
> any previously processed tab file in "/etc/cron.d", it totally rebuilds
> it's database. crontab only touchs the "/var/cron/tabs" directory.  On
> Win9x, cron will not detect new or deleted file in either "etc/cron.d"
> or modified files in "/var/cron/tabs". This is because Win9x does not
> updated the directory timestamp when the contents change and utimes does
> not work when crontab tries to update tabs.
>
> Maybe on Win9x, a simple solution would be to define a new file that
> crontab creates if not there and touches if there.  cron would use that
> file's timestamp also, rebuilding the entire list if it has a more
> recent timestamp.  This would solve the crontab problem but not the
> problem if a new file is added to /etc/cron.d".

I'm just browsing MSDN, and it seems like using
FindFirstChangeNotification in cron might be a possibility.  See
<http://msdn.microsoft.com/library/en-us/fileio/base/obtaining_directory_change_notifications.asp>

Another possibility, as I mentioned, would be to use CreateDirectory in
utimes...

> Or, possibly a better solution to solve the problem totally on win9x,
> cron could always get the latest timestamp of all files in "/etc/cron.d"
> and "/var/cron/tabs" and use that timestamp as the new timestamp for its
> database.  It's a little more processing every 60 seconds, but wouldn't
> the directories be cached in memory so there would be no disk access?
> It already does this for files in "/etc/cron.d". I plan to try this out
> because I need a solution for this.

This would be a last resort, I'd guess, if it really does turn out to be
impossible to change the timestamp on a directory in Win9x (although I
have a gut feeling that it should be quite possible, we just don't know
how).

> --------------------
> cygrunsrv on Win9x:
>
> When running cron as a 9x 'service', hiding the window is not the only
> problem.  Getting the app to terminate when the system shuts down is the
> problem I've been dealing with.  By using an win gui app, I can monitor
> the messages to a hidden window to get the ENDSESSION message.  But, any
> code you have might help, especially if it eliminates the need to make
> it a GUI app with a hidden window.

Umm, not really...  But it does eliminate the windows created when the
service is run...

> After a quick analysis, I think cygrunsrv could be modified.   If I modify
> cygrunsrv, I think I would need to change it to use WinMain() so it's a
> GUI app.  On Win9x, it would create a window so it could get the
> ENDSESSION message at system shutdown.

Hmm, I suggest another approach: write a rudimentary service manager for
Win9x.  This is not as bad as it sounds: you'll have only one process that
will watch for the ENDSESSION message, and it'll have a similar interface
to the NT service manager, so cygrunsrv wouldn't need to be changed
(much).

> Option -I would write an entry to the regitry key
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunServices
> such as init with the string value value C:\cygwin\cygrunsrv.exe -S init
> It would need to store the parameters for init somewhere.  Maybe they
> could be stored in an init key under RunServices.

Or we could create a completely new key... ;-)

> The -S option on Win9x would only be modified to run the service rather
> than call the service manager to start it. This is how Win9x would call
> cygrunsrv at startup.  The options stored in the registry would be used
> to run the service.  cygrunsrv wouldnt return in this case until the
> service exited.  register_9x_service(); would be called so the service
> would not be shut down when the user logs out.  On Win9x, a hidden
> window would be created so the app would be terminated at system
> shutdown. On termination, the term signal would be sent to the
> 'service'.  If you have a better way to hide the window, maybe WinMain
> would not be needed.

The "service manager" could be a GUI app with a hidden window.  It'll only
need to respond to the messages from cygrunsrv and the ENDSESSION message.

> By the way, is there and existing function that will convert the WinMain
> lpCmdLine or GetCommandLine() arguments to argc, argv format?

Yes.  It's called WinMain in MSVCRT*.dll (or other C runtimes).

> The -R option would simply remove the registry entries

Makes sense.

> The -E stop option would not be supported.

Why not?  If we have our own "service manager", it could simply issue a
signal to the service app, same way it happens on NT...

> To actually run a service based on the RunServices registry entry, the
> system would need to be shut down and restarted.

Ugh... Ugly.  I'd much rather the "service manager" always ran as service
(so restart is unavoidable if you want to start it), but later any
services you wish to run could be run through the already running service
(thus no restart required).
	Igor

> BB
>
> "Igor Pechtchanski" <pechtcha at cs dot nyu dot edu> wrote in message
> news:Pine dot GSO dot 4 dot 44 dot 0304101446040 dot 8014-100000 at slinky dot cs dot nyu dot edu dot  dot  dot 
> > BB,
> >
> > I applaud the effort.  I think it would be terrific to have a cygrunsrv
> > equivalent on Win9x systems.  I don't know how far you've gotten in terms
> > of design, but here are a few suggestions:
> >
> > - instead of creating yet another program, we should probably change
> >   cygrunsrv to do something different on Win9x.  That way, the READMEs
> >   (and some scripts) will apply
> >
> > - if you need help hiding that command window, I have code
> >   that's been tested on Win9x (I think the command interpreter on Win9x
> >   is actually "command.com", not "cmd.exe", though)
> >
> > - utime() is unimplemented for directories at all...  I don't know that it
> >   even works on WinNT/2k/XP...  Corinna?
> > Igor
> >
> > On Thu, 10 Apr 2003, BB wrote:
> >
> > > I've notice some discussion about problems running cron on Win9x.
> > > I'm currently running cron and init on Win95.  Win98 works too.
> > > I'm not running anything complex with cron yet though.
> > > Unfortunately, I'm stuck in Win9x mode, but at least I'm being paid
> > > for it.
> > >
> > > One thing that is required is the addition of
> > > "SYSTEM:*:18:544:,S-1-5-18::"
> > > to the /etc/passwd file.
> > > The ",S-1-5-18" part probably isn't required, but I just simply copied
> > > the
> > > entry from an XP machine.  I also added "SYSTEM:S-1-5-18:18:" to
> > > /etc/group
> > > but I don't think it matters.
> > >
> > > -----------from cron.h----------------
> > > #ifdef __CYGWIN__
> > > #define ROOT_UID 18
> > > #define ROOT_USER "SYSTEM"
> > > #else
> > > -------------------------------------
> > >
> > > Try adding the SYSTEM user as mentioned above and then run
> > > /usr/sbin/cron -D.  In this case, the window it is running in will
> > > remain open.  If you run it without the -D and then try to exit from
> > > the cmd window, the window will not close until you kill cron.
> > >
> > > I am in the process of writing a cygwin /windows gui app (cygruncmd)
> > > modeled around the service_main() of cygrunsrv.  It will fork and
> > > exec a cmd (i.e. cron or init) redirecting stdout output the to a
> > > log such as /var/log/cron.log as cygrunsrvdoes.  I also plan to use
> > > it to run init on Win9x for agetty.  It needs to be a windows gui
> > > app so I can monitor system shutdown and kill the cmd when the
> > > system shuts down.  An option to the app will be to run with the
> > > window hidden.  Another option might be to respawn when the cmd
> > > exits.  Which gets me to another option I might try, running cron
> > > from init.  Not sure about this one.
> > >
> > > A few additional notes:
> > > 1. cron doesn't seem monitor system clock changes as far as I can
> > > tell. So if the time is adjusted backwards say from 11:00am -
> > > 10:00am, when cron wakes up and adds 60 seconds to its previous time
> > > of 11:00 to 11:01, it will wait an hour before it wakes again.  I
> > > guess this could be a problem in the fall if the change in time is
> > > automatic.  If manually changing the time, restarting cron is the
> > > solution as long as the use knows about the problem.
> > >
> > > 2. On Win9x, crontab cannot touch the time on "/var/cron/tabs", so
> > > cron doesn't notice a change.  You can get around this my runnning
> > > the following commands, but you MUST not remove the tabs directory
> > > close to the 0 second or cron might exit when it wakes up and cannot
> > > find tabs.  Maybe crontab could be enhanced to make sure the
> > > directory time is modified on Win9x systems.  This workaround is
> > > fine for me right now.  I plan to insert a call to a program that
> > > waits until 30 seconds after the minute so cron doesnt fail between
> > > the cp and mv.
> > > ------------------------------------------
> > > rm -R -f /var/cron/tabs.sav
> > > cp -R /var/cron/tabs /var/cron/tabs.sav
> > > rm -R -f /var/cron/tabs
> > > mv /var/cron/tabs.sav /var/cron/tabs
> > > ----------------------------------------
> > >
> > > Hope this helps.
> > > [snip]
> > > BB

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha at cs dot nyu dot edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor at watson dot ibm dot com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Knowledge is an unending adventure at the edge of uncertainty.
  -- Leto II


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/