loop in backup-copy-buffer

loop in backup-copy-buffer

[Glenn Morris]

You added the (potentially infinite) loop in backup-buffer-copy a few
years ago. Looks like it was adapted from make-temp-name. I can see it
might make sense to loop while trying to make a tempfile name, but was
there ever a case where this was found to be necessary when backing
up? Can we just get rid of this loop? The ChangeLog entry is not
helpful as to why such a loop might be needed.



2005-04-23  Richard M. Stallman  <rms@gnu.org>

            * files.el (read-directory-name): Always pass non-nil
            DEFAULT-FILENAME arg to read-file-name.
            (backup-buffer-copy, basic-save-buffer-2): Take care
            against writing thru an unexpected existing symlink.

Re: loop in backup-copy-buffer

[Richard Stallman]

    You added the (potentially infinite) loop in backup-buffer-copy a few
    years ago. Looks like it was adapted from make-temp-name. I can see it
    might make sense to loop while trying to make a tempfile name, but was
    there ever a case where this was found to be necessary when backing
    up?

In make-temp-name, this is needed because of possible race conditions.
I think there is also a possible race condition for making backup files,
and that's why I put something similar here.

I won't say I am absolutely certain it is necessary,
but don't remove it just because you don't see the issue!
If you can prove this carefulness is not necessary,
well and good, we can remove it.  Otherwise, we should fix it,
not remove it.

Re: loop in backup-copy-buffer

[Glenn Morris]

Richard Stallman wrote:

> In make-temp-name, this is needed because of possible race
> conditions. I think there is also a possible race condition for
> making backup files, and that's why I put something similar here.
>
> I won't say I am absolutely certain it is necessary, but don't
> remove it just because you don't see the issue! If you can prove
> this carefulness is not necessary, well and good, we can remove it.

I don't want to get into that, so I installed the minimum fix for the
bug that prompted this.

Re: loop in backup-copy-buffer

[Stefan Monnier]

>     You added the (potentially infinite) loop in backup-buffer-copy a few
>     years ago. Looks like it was adapted from make-temp-name. I can see it
>     might make sense to loop while trying to make a tempfile name, but was
>     there ever a case where this was found to be necessary when backing
>     up?

> In make-temp-name, this is needed because of possible race conditions.
> I think there is also a possible race condition for making backup files,
> and that's why I put something similar here.

The problem with make-temp-name is not just a race-condition but that the
race-condition introduces a security hole.  I don't think the same holds for
backup files since they must have predicate names.


        Stefan

Re: loop in backup-copy-buffer

[Richard Stallman]

    The problem with make-temp-name is not just a race-condition but that the
    race-condition introduces a security hole.  I don't think the same holds for
    backup files since they must have predicate names.

You might be right -- I am not sure -- but what are predicate names?

Re: loop in backup-copy-buffer

[Stefan Monnier]

>     The problem with make-temp-name is not just a race-condition but that
>     the race-condition introduces a security hole.  I don't think the same
>     holds for backup files since they must have predicate names.

> You might be right -- I am not sure -- but what are predicate names?

They're typos.  I meant "predictable names".  The fact that the names have
to be predictable means that the looping trick is not a solution and that
a different solution needs to be used, typically by storing those files in
directories that are not world-writable (which is indeed the case for
backup files and if not, they do not present any additional danger compared
to the original file since they're in the same directory anyway).


        Stefan

Re: loop in backup-copy-buffer

[Richard Stallman]

I wish I could recall the specific reason why I thought this
problem applied to backup files.  I don't recall it now.