This is not a serious bug, more a user interface thing.

When 'darcs get' is interrupted (before it says "Copying patches, to get 
lazy repository hit ctrl-C...") because the user really wants to interrupt 
it, the output from darcs leaves the impression that the get completed 
successfully ("Finished getting."). This is not the case as shown here:

    mare: .../base/local > darcs get 3-14-8-2 blub
    Couldn't handle interrupt since darcs was in a sensitive job.
    Copying patches, to get lazy repository hit ctrl-C...
    Finished getting.
    mare: .../base/local > darcs whatsnew --repodir blub --look-for-adds
    R ./src/cas/os/vms/login.com

Darcs should not continue if it gets interrupted in a sensitive job and 
cannot recover from this. Instead, interrupting a 'darcs get' in this way 
should either completely remove the newly created directory and stop as 
soon as possible, or try again to copy the file in question until the 
pristine tree is complete.

Cheers
Ben
-- 
"TDD replaces a type checker in Ruby in the same way that a
strong drink replaces sorrows."       (byorgey on #haskell)

Any text below this line has automatically been added by the
mail server and does not necessarily represent my personal opinion.
-------------------------------------------------------------------

Helmholtz-Zentrum Berlin für Materialien und Energie GmbH   
Glienicker Straße 100, 14109 Berlin   
Vorsitzende des Aufsichtsrates: Dr. Beatrix Vierkorn-Rudolph   
Stellvertretende Vorsitzende: Dr. Jutta Koch-Unterseher   
Geschäftsführer: Prof. Dr. Anke Rita Pyzalla, Prof. Dr. Dr. h.c. Wolfgang Eberhardt, Dr. Ulrich Breuer   
Sitz der Gesellschaft: Berlin Handelsregister: AG Charlottenburg, 89 HRB 5583   

Information:   
Durch die Fusion mit dem ehemaligen Hahn-Meitner-Institut (HMI) ist   
BESSY nun Teil des neuen Helmholtz-Zentrum Berlin für Materialien   
und Energie (HZB).    

By the merger with the former Hahn-Meitner-Institut (HMI), BESSY   
became part of the new Helmholtz-Zentrum Berlin für Materialien und   
Energie (HZB).   

Disclaimer automatically attached by the E-Mail Security Appliance   
mail0.bessy.de 04/21/09 at Helmholtz-Zentrum Berlin GmbH.

I think the kind of confusion this can cause is enough to classify this as as bug.  

It sounds like we should be keeping track of interrupts in such a way that if we
receive one when we're in a sensitive job, we at least keep track of the fact
that it happened so that we can later handle it.

I don't really understand this part of the code very well, so I'll paste in
withSignalsBlocked and wonder if we can return something like IO Bool and use an
IORef or something to keep track of 'was interrupted'

withSignalsBlocked :: IO () -> IO ()
withSignalsBlocked job = (block job) `catchSignal` couldnt_do
    where couldnt_do s | s == sigINT = oops "interrupt"
                       | s ==  sigHUP = oops "HUP"
                       | s ==  sigABRT = oops "ABRT"
                       | s ==  sigALRM = oops "ALRM"
                       | s ==  sigTERM = oops "TERM"
                       | s ==  sigPIPE = return ()
                       | otherwise = oops "unknown signal"
          oops s = hPutStrLn stderr $ "Couldn't handle " ++ s ++
                   " since darcs was in a sensitive job."

Setting to need-action so that somebody can study the code and explain if I'm
making any sense or if I'm just rambling incoherently.