Hi. I'm sorry you're having trouble and I want to make it work for
you (in your existing configuration).
Stéphane Glondu writes ("Bug#933827: "dgit fetch" fails with "cannot remove
directory for ...""):
> It might be relevant to know that /home/steph is on NFS.
Urgh.
> Indeed, /home/.../findlib-1.7.3/debian/source is empty after the
> command exists. I suspect dgit tries to remove it while having files
> of this directory open. This does not work on NFS, and I see no good
> reason to need this feature in dgit.
I think you're probably right that there is no good reason and I will
try to work around this. (Even though I consider this a bug in NFS.)
> Why doesn't dgit unpack somewhere in /tmp?
1. It wants to be on the same filesystem as .. for Reasons.
2. Using /tmp makes your software less crash-only.
3. Using /tmp makes it harder to debug failures after the event.
Is there an easy way for you to tell me what the name or contents of
the errant file is ? If so then I can probably fix this quite
easily. If not then I will have to think of a way to do an audit or
run appropriate tests or stare and hope, or something ?
Eg, maybe adding END { sleep 100; } somewhere and then you can ls or
cat ? I think this may be easier for you since you do have NFS and I
don't.
Regards,
Ian.
