Re: backup-buffer-copy loops if old backup can't be deleted

[Martin von Gagern]

martin rudalics wrote:
> Did you apply that patch?

Yes, I did, and even got it included in the relevant byte-compiled code.
Seems to work well enough here.

> Suppose the file to-name exists but cannot be
> deleted.  `copy-file' will raise its `file-already-exists' error and you
> remain trapped in that loop.

No, if the file cannot be deleted, the delete-file will signal a
file-error so copy-file doesn't even get a chance to signal a
file-already-exists error because it doesn't get called at all. As the
outer condition-case doesn't catch file-error, the signal will propagate
up the call stack.

> You have to either change the backup file's permissions from within the
> `condition-case'

A possible solution in my simple test case, but not a solution for the
real world case where user A wants to edit a file in a dir belonging to
B, where B granted write permission to A only for that single file, not
for its backup and neither for the directory. Nothing A can da about it.

> or mandate error handling up to `backup-buffer' where
> it attempts to do the (convert-standard-filename "~/%backup%~") stuff.

Already happens like this.

> I can't test these solutions here since my file system doesn't provide
> permissions.

Tough luck.
Which system? Isn't even the MS-DOS readonly flag enough for this?

Greetings,
 Martin von Gagern

signature.asc
Description: OpenPGP digital signature