[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Funny situation with Licq.

On Sat, Nov 25, 2000 at 11:59:42AM -0600, Kirk Strauser <kirk@strauser.com> was heard to say:
> I suppose that it's still a bug, Daniel, but I'm still uncertain
> as to whose responsibility it is.  Is it a problem for the
> Debian folks, because it's included with Debian, or should the
> report have been more properly directed toward the upstream
> coders?

  Well, I'd say that the Debian maintainer should at least forward such bugs
upstream.  I think it's useful to have them in the Debian BTS, personally,
just so their progress can be tracked and users can see quickly whether
the bug has been reported (most projects don't have their own bug system,
and those that do are all different (and generally a lot harder to use
than ours, IMO); http://bugs.debian.org/package is much easier for me
personally when checking for a bug)

> I would also venture to guess that a good percentage of Debian
> packages have the exact same error.  Should every maintainer
> audit all code, and update the patches when new upstream
> versions come out?  Please don't take this as a flame - it
> wasn't meant as one.  It just seems problematic to have several
> layers of responsibility for each and every program.

  I don't really think auditing is necessary unless someone wants to, but
dealing with such reports in a way other than "it's not my bug, go away" is
useful :)

> > Luckily, it looks like the maintainer finally understands that
> > writing a temporary file and using rename() is a good idea, so
> > maybe he'll forward it..
> Actually, are there any circumstances in which this can fail,
> possibly causing data loss?  Delete/rename isn't an atomic
> operation.  I ask because ...

  rename IS atomic.  If you don't believe me, here's the manpage:

       rename  renames  a  file, moving it between directories if

       Any other  hard  links  to  the  file  (as  created  using
       link(2)) are unaffected.

       If  newpath  already exists it will be atomically replaced
       (subject to a few conditions - see ERRORS below), so  that
       there  is  no point at which another process attempting to
       access newpath will find it missing.

       If newpath exists but the operation fails for some  reason
       rename  guarantees  to  leave  an  instance  of newpath in

       However, when overwriting there will probably be a  window
       in  which both oldpath and newpath refer to the file being

  So basically, the worst thing that can happen is that you'll end up with
two links to the file instead of one if someone happens to kick the power
cord at precisely the wrong time.  Aside from that, the kernel does guarantee
that either the file is replaced or it isn't.  (I don't think you can fix
this issue without journalling)

  (this is done basically by clobbering the old link in that directory
   entry with a link to the new inode, then deleting the old link, so you
   can never end up with the new link not existing -- this is much better than
   deleting the old link first, as I'm sure you'll agree :) )


/----------------- Daniel Burrows <Daniel_Burrows@brown.edu> -----------------\
|               Hi, I'm a .signature virus!                                   |
|               Copy me into your .signature to help me spread!               |
\------- Listener-supported public radio -- NPR -- http://www.npr.org --------/

Reply to: