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:
DESCRIPTION
rename renames a file, moving it between directories if
required.
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
place.
However, when overwriting there will probably be a window
in which both oldpath and newpath refer to the file being
renamed.
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
--
/----------------- 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: