Re: Crontab problems

[Raphael <raphael at oninet dot pt>]

On Sat, Sep 14, 2002 at 07:55:36PM -0400, Igor Pechtchanski wrote:
> On Sat, 14 Sep 2002, Raphael wrote:
> 
> > On Sat, Sep 14, 2002 at 01:00:20PM -0400, Igor Pechtchanski wrote:
> > > On Thu, 12 Sep 2002, Raphael wrote:
> > >
> > > > On Wed, Sep 11, 2002 at 05:53:24PM -0400, Igor Pechtchanski wrote:
> > > > > On Wed, 11 Sep 2002, Nicholas Wourms wrote:
> > > > >
> > > > > > --- Raphael <raphael@oninet.pt> wrote:
> > > > > > > Hi guys/girls~,
> > > > > > >
> > > > > > > I'm having a bit of a problem with my windows based editor. Using
> > > > > > > it with
> > > > > > > Pine or Mutt is not problem. Using it with Crontab -e gives a
> > > > > > > sharing
> > > > > > > violation error when I want to save the new file.
> > > > > > >
> > > > > > > Is this a crontab problem?
> > > > > >
> > > > > > Use vi.exe
> > > > >
> > > > > Most windows editors adopt a remove-and-recreate (or rename-and-recreate)
> > > > > policy.  This basically means that they will try to remove or rename the
> > > > > crontab-created file (which will fail, silently), and then create that
> > > > > file over (which will fail since crontab has it open).  This is where your
> > > > > sharing violation comes from.
> > > >
> > > > Ok, I can understand that explenation.
> > > >
> > > > > I've verified this with notepad and
> > > > > editpad, but I'm sure most of the others will behave similarly.  Thus,
> > > > > looks like using a cygwin-based editor is your only option, unless you can
> > > > > find a windows one that writes the files in-place.  If this creates one
> > > > > more convert for the vi camp, all the better. ;-)
> > > >
> > > > Don't think so, why should Cron not be able to act like Pine or Mutt. I
> > > > guess the latter start opening the file in shared mode?
> > >
> > > I don't know about mutt, but pine, IIRC, does not keep the file open while
> > > it's being edited by an external editor.  It re-opens the file afterwards,
> > > which is why it doesn't care whether it's the same file, or a newly
> > > created one.
> >
> > Hi Igor,
> > But do you have any idea why Cron shouldn't be able to act the same?
> 
> Quoting straight from the crontab-3.0.1-7 source (crontab.c:418):
> 
>         /* we still have the file open.  editors will generally rewrite the
>          * original file rather than renaming/unlinking it and starting a
>          * new one; even backup files are supposed to be made by copying
>          * rather than by renaming.  if some editor does not support this,
>          * then don't use it.  the security problems are more severe if we
>          * close and reopen the file around the edit.
>          */
> 
> Hope this answers your question.  

Hmmm, it answers the question, but raises others. I cannot see the security 
issue for Cygwin as I now work arround by editing /var/cron/tabs/<currentuser>
directly and restarting the service afterwards.

> By the way, the patch to close the file
> and re-open it is trivial, and is left as an exercise for the reader.

Great but without any C knowledge I wouldn't even know where to start. I'm 
wondering, if Corinne is reading this, if the patch might not be standarized 
for Cygwin considering the interchangability between Cygwin and Windows.
Ofcourse only if there is really no security issue.

> Boy, I get to quote the source a lot these days...  Not that I'm
> complaining or anything... :-D

I'm sure everyone is very greatfull for you sharing this information. It's
considarably more informative than a blunt ŽUse vi.exeŽ some people try
to kill a thread with. Thank you very much.

Kind Regards

Raphael.

Attachment: msg00747/pgp00000.pgp
Description: PGP signature