On Tue, Aug 30, 2005 at 01:41:35PM +0200, Juliusz Chroboczek wrote:
> > How is the way your C code works better than first linking src to tmp
> > and then, assuming that succeeds, doing the various necessary checks and
> > either renaming it to dst or deleting it depending on the outcome?
>
> Link is synchronous on traditional Unix filesystems and on NFS.
I don't see how that's an argument one way or the other, given both rely
on it?
I'm thinking of something like (after checking they aren't already links
to the same file):
do let tempname = something_similar_to dst
-- This is a check we don't currently do. It can't affect us
-- currently due to how we use it, but I think it's good form to do
-- it anyway. We have the repo locked, so there is no race.
exists <- doesItExist tempname
-- We could also check src is a normal file here. There's a race,
-- but it's the best we can do to try not to make a hardlink to a
-- directory.
if exists
then do createLink src tempname
tempstat <- getFileStatus tempname
deststat <- getFileStatus dst
if we_decide_they_are_OK
then do rename tempname dst
return True
else fail "Don't like the look of them"
`catch` \e -> do removeLink tempname `catch` \_ -> return ()
return False
else return False
where we_decide_they_are_OK does the regular file, size match etc
checks, and the contents check if careful is True (in fact, I'm tempted
to say we should drop the careful argument and always do the check. It's
always True now anyway, and it really is something of a loaded gun to
leave lying around).
In my opinion this is simpler than the current way, where we first do
checks and then try to make sure they are still valid after the link.
What do you think? Is there a problem I've missed?
Would this still worry you as Haskell code, even given all the
interesting functions are coming from System.Posix?
> > Isn't the !S_ISREG(srcstat.st_mode) check [...] unsafe not only if
> > the file is modified in place, but also if it is removed and another
> > created which uses the same inode?
>
> This code assumes that i-nodes are not changed in place, and that inum
> wraparound doesn't happen. There's not much more you can do efficiently.
>
> And now could you /please/ answer the numbered points in message
> <[EMAIL PROTECTED]> dated 29 August?
What sort of an answer do you want?
My current prefered option for lockfiles is to write a Haskell binding
for liblockfile, assuming it does (or can be made to do) what we want.
For maybe_relink I haven't decided yet, but I think code like the above
scares me less than the problems associated with C, and correctly
interfacing to it.
Thanks
Ian
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
