Completely at odds with norma Unix behaviour, Darcs has a habit of
creating temporary files in the working tree, instead of in $TMPDIR or
/tmp.  Nor do they have mkstemp-style names (-0 instead of .XXXXXX).

This confuses our users, e.g.

13:35 <dino-> I just did a darcs tag with long comment. What is the 'darcs-tag-0' file that it left in the project root dir about?
13:36 <dino-> Is that normal?
13:36 <twb> dino-: it's a backup file :-(
13:36 <twb> Darcs is stupid and doesn't know how to name backup files properly, or to put them in $TMPDIR
13:36 <dino-> The tag otherwise seemed to work, looks fine in cha output
13:37 <dino-> So harmless bug?
13:37 <twb> dino-: basically you can just delete that file

AFAIK these files are also not in the default boring list (so darcs
add and darcs record -l want to version control them), and often they
are not deleted.  Presumably the excuse for this is to avoid data
loss, but IMO the current behaviour is excessive.

Currently my repo has:

    darcs-amend-record-0
    darcs-amend-record-0.~1~
    darcs-amend-record-1
    darcs-amend-record-1.~1~
    darcs-amend-record-2
    darcs-amend-record-2.~1~
    darcs-record-0 darcs-temp-mail-0
    darcs-temp-mail-0.~1~
    darcs-temp-mail-0.~2~
    darcs-temp-mail-0.~3~
    darcs-temp-mail-1
    darcs-temp-mail-1.~1~
    darcs.cabal-darcs-backup0
    darcs9599-new_3c63f32f823ff92f99d802c48a9ddd0a
    darcs9603-new_fe335076796c541830bc54310d35cec7

So incidentally, I think that -darcs-backupN should instead be .~N+1~,
the standard GNU and CVS style for numbered backups.

On Mon, Apr 06, 2009 at 03:37:09 -0000, Trent Buck wrote:
> Completely at odds with norma Unix behaviour, Darcs has a habit of
> creating temporary files in the working tree, instead of in $TMPDIR or
> /tmp.

So darcs knows about $TMPDIR and other similar paths (see tempdir_loc).
The question is when it should be using these locations.

In commands which generate a log, the current code is

 make_log = world_readable_temp "darcs-amend-record"

Perhaps there needs to be a variant of world_readable_temp that
generates files in that location.

Also, we should be slightly careful to consider (a) reasons that we may
want to keep these logs around (darcs record --logfile?) and (b) cases
where we really do want them to be in the working directory (e.g.
backups)

I'll mark this ProbablyEasy in any case

Marking as a feature and ProbablyEasy.

Also, perhaps the discoverability of these log files is a good thing?

Is there a deeper problem like - the log files are actually being created in the
right place (we really do want them in working), but we're just not cleaning
them up in the cases where darcs record is successful?  Maybe the real behaviour
we're aiming for is for the log files to stick around only if there is a
problem, like a test that fails.

On Tue, Apr 07, 2009 at 04:38:29PM -0000, Eric Kow wrote:
> Also, perhaps the discoverability of these log files is a good
> thing?

I concede that's a point for the status quo, but I think matters could
be improved by making them LOOK like backup files.  Having said that,
tools like mutt and reportbug happily create their analogous working
files in /tmp, and that doesn't seem to bother anybody.

> Is there a deeper problem like - the log files are actually being
> created in the right place (we really do want them in working), but
> we're just not cleaning them up in the cases where darcs record is
> successful?

No, I think Darcs is pretty good in that respect.  But for me the
problem with this is that I run "darcs record" and "darcs amend"
*expecting* the tests to fail.  That's the only way I know to run the
commit test!  (I could use "darcs check", but that will take
deciminutes or even hours because I'm working on a lazy darcs-2
repository and there is a log of history to download and validate.)

> Maybe the real behaviour we're aiming for is for the log files to
> stick around only if there is a problem, like a test that fails.

That's what mutt and reportbug do, but they use /tmp (or TMPDIR, if
it's defined).  Then, if there's a problem, they actually print on
stdout

    I had a problem.  The file you were editing is available at
    /tmp/mutt-XXXXXX-XXX-XXX

On Wed, Apr 08, 2009 at 07:40:35 -0000, Trent Buck wrote:
> > Maybe the real behaviour we're aiming for is for the log files to
> > stick around only if there is a problem, like a test that fails.
> 
> That's what mutt and reportbug do, but they use /tmp (or TMPDIR, if
> it's defined).  Then, if there's a problem, they actually print on
> stdout
> 
>     I had a problem.  The file you were editing is available at
>     /tmp/mutt-XXXXXX-XXX-XXX

Sounds like a much nicer plan (assuming we can always know when we've
had a problem, which we do for failing tests, at least)

On Wed, Apr 08, 2009 at 11:03:39AM -0000, Eric Kow wrote:
> On Wed, Apr 08, 2009 at 07:40:35 -0000, Trent Buck wrote:
>>> Maybe the real behaviour we're aiming for is for the log files to
>>> stick around only if there is a problem, like a test that fails.
>>
>> That's what mutt and reportbug do, but they use /tmp (or TMPDIR, if
>> it's defined).  Then, if there's a problem, they actually print on
>> stdout
>>
>>     I had a problem.  The file you were editing is available at
>>     /tmp/mutt-XXXXXX-XXX-XXX
>
> Sounds like a much nicer plan (assuming we can always know when we've
> had a problem, which we do for failing tests, at least)

Also I should mention that last time I asked for this (or something
similar?), David vetoed it on the basis that the working directory was
guaranteed to be writable, but the temp area might not... or something
equally strange but vaguely plausible.  It ought to be in the
darcs-users archive if someone wants to dig it up.

I need somebody to track down David's objection on the mailing list, link to it
and comment on plausibility of his objection and solutions.  

This would be a good time to compare tradeoffs: how likely is this to fail?
would a backing off strategy make the code pointlessly ugly? Note that users
could always tell darcs what directory to use as temp.

Seems like you could start with temp and back off to the working dir as
a last resort.  Note Trent's suggestion to emit a message about the log
file's location.

PS. I've copied Trent's suggestion about the name of backup files to
issue1812