On Mon, Aug 29, 2005 at 12:13:53AM +0200, Juliusz Chroboczek wrote: > > (By the way, this is the second time that I'm offering to remove > functionality that I personally implemented in order to fit your > particular tastes. Not that I have much choice.)
I haven't had the impression I was going against a concensus (well, except for not having time to act on things as quickly as I'd like). If being the maintainer means I should just blindly accept anything I am given then I will replace myself with a small shell script and spend my time on the more enjoyable parts of darcs development. If you think I'm abusing my power as maintainer then perhaps you should bring it up in a separate thread to this technical discussion? > > I assume there's no library commonly available that has the > > functionality we want, by the way? Ah, I see we only use atomic_create for lockfiles, so liblockfile is something to look into: http://ftp.debian.org/debian/pool/main/libl/liblockfile/liblockfile_1.06.tar.gz At a quick glance I wasn't convinced by its handling of stale lockfiles, though; it would seem better to me if it could return L_STALE to us rather than removing it itself leaving (unless I read it wrong) a race condition. Still, we can send a patch for that if I'm right. Incidentally, I've realised that Windows doesn't use the functions we're talking about anyway, so it may not be particularly useful to bundle it with darcs and tweak configure to use the in-tree copy when necessary etc. Google suggests gentoo also has it and rpms of some form exist. That doesn't help with maybe_relink, though, and I think we'd be lucky to find that in a library. 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? Isn't the !S_ISREG(srcstat.st_mode) check (and also the srcstat.st_size != dststat.st_size check, but for the "gratuitious" tempstat.st_size != srcstat.st_size 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? > > And perhaps if not it would be worthwhile to split them off into a small > > C lib (probably also bundled with the darcs source for the forseeable > > future) so that other projects can make use of them without reinventing > > the wheel? > > It wouldn't save any work. Conscientious project maintainers would > still need to review our library for safety. Yes, but then you have had twice as many people trying to find bugs in the code, so it is less likely that something has been missed. And if non-conscientious project maintainers use it then at least you have saved them the trouble of writing a buggy implementation of their own. Also, the Haskell binding can be split off to its own cabal package at some point and used by other projects too. Thanks Ian _______________________________________________ darcs-devel mailing list [email protected] http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
