Question about handling file deletion

Question about handling file deletion

[Stephen Berman]

If a package provides functionality for deleting files used by it, is it
considered a bug in the package if it does not handle the situation
where a user deletes such files using a command outside of the package
and this causes errors when using the package which don't arise if the
package file-deletion functionality is used?  I'm faced with this issue
in the new version of todo-mode.el (see bug#14688).  If someone deletes
a todo file using e.g. Dired and then gets an error in Todo mode and
reports it as a bug, is it kosher for me reply "If it hurts, don't do
that.  Use todo-delete-file." and close the bug?  (That command doesn't
actually exist yet, but I think it will be much easier to implement than
trying to handle the result of deleting todo files outside of Todo
mode.)

Steve Berman

Re: Question about handling file deletion

[Stefan Monnier]

> in the new version of todo-mode.el (see bug#14688).  If someone deletes
> a todo file using e.g. Dired and then gets an error in Todo mode and
> reports it as a bug, is it kosher for me reply "If it hurts, don't do
> that.  Use todo-delete-file." and close the bug?  (That command doesn't

There's no rule, but usually it's OK for Emacs to misbehave slightly in
such circumstances, tho it's also usually he case that Emacs tries to
handle such cases gracefully.

IOW it depends: should it be obvious to the user that just "rm"ing the
file will lead to an error?
E.g. can she still see a reference to the file somewhere else)?  If the
remaining ("dangling") reference to the lost file is not shown to the
user, than Emacs should work harder to try and handle the
disappearance seamlessly.


        Stefan

Re: Question about handling file deletion

[Stephen Berman]

On Wed, 26 Jun 2013 10:33:19 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> in the new version of todo-mode.el (see bug#14688).  If someone deletes
>> a todo file using e.g. Dired and then gets an error in Todo mode and
>> reports it as a bug, is it kosher for me reply "If it hurts, don't do
>> that.  Use todo-delete-file." and close the bug?  (That command doesn't
>
> There's no rule, but usually it's OK for Emacs to misbehave slightly in
> such circumstances, tho it's also usually he case that Emacs tries to
> handle such cases gracefully.
>
> IOW it depends: should it be obvious to the user that just "rm"ing the
> file will lead to an error?
> E.g. can she still see a reference to the file somewhere else)?  If the
> remaining ("dangling") reference to the lost file is not shown to the
> user, than Emacs should work harder to try and handle the
> disappearance seamlessly.

I'm not sure I understand what you mean by "reference to the lost file".
The Todo mode state includes a list of all todo files, which is exposed
to users for e.g. minibuffer completion.  If a file is deleted from
outside of Todo mode, this list won't be updated, so in that sense it
contains a "reference to the lost file", which the user can see.  But
while the user presumably knows the file is missing, Todo mode doesn't,
and that can lead to errors, especially if a live buffer is still
holding the content of the deleted file and the user calls a Todo
command to manipulate the buffer.  This problem can be avoided with a
todo-delete-file command which updates the file list.  But that doesn't
help if it's possible to delete a file behind Todo mode's back.  What
would help is a delete-file-hook, but that doesn't exist AFAIK.  The
only other alternative I can think of is to build the needed checks into
each Todo command that could manipulate a file or a buffer visiting a
file.

Do other packages go to such lengths?  Some don't, e.g., if you delete a
mail file without telling Gnus, Gnus will try to open it and signal an
error (and not what you might think: gnus-request-expire-articles: Wrong
type argument: stringp, nil).  I guess it's taken for granted that
you're only supposed to delete mail files by using commands provided by
the mail client.  I would like the same kind of assumption to be made
for Todo mode; but maybe that's asking too much.

Steve Berman

Re: Question about handling file deletion

[Stefan Monnier]

> I'm not sure I understand what you mean by "reference to the lost file".

I meant it in a very general way.  E.g. a buffer whose buffer-file-name
points to this file.  Or the presence of this file name in a list of
files somewhere.

> The Todo mode state includes a list of all todo files, which is exposed
> to users for e.g. minibuffer completion.  If a file is deleted from
> outside of Todo mode, this list won't be updated, so in that sense it
> contains a "reference to the lost file", which the user can see.

That seems harmless.

> But while the user presumably knows the file is missing, Todo mode
> doesn't, and that can lead to errors, especially if a live buffer is
> still holding the content of the deleted file and the user calls
> a Todo command to manipulate the buffer.

What kind of errors?


        Stefan

Re: Question about handling file deletion

[Stephen Berman]

On Wed, 26 Jun 2013 21:42:19 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote:

>> But while the user presumably knows the file is missing, Todo mode
>> doesn't, and that can lead to errors, especially if a live buffer is
>> still holding the content of the deleted file and the user calls
>> a Todo command to manipulate the buffer.
>
> What kind of errors?

E.g. bug#14688.  If you have debug-on-error enabled, you get the two
backtraces Leo reported (wrong-type-argument due to (find-file-noselect
nil), followed by file-error "Removing old name" "no such file or
directory" due to calling delete-file on the file that was already
deleted).  But if debug-on-error is disabled, you just get "Removing old
name: no such file or directory, /data/steve/.emacs.d/todo/Todo.todo" in
the echo area and above it a buffer in Todo mode whose name is the todo
file you just created.  If you try to add a category, you get
"find-file-noselect: Wrong type argument: stringp, nil".  If you
mistakenly think there is a category and try to navigate with `f' or
`b', you get "todo-forward-category: Arithmetic error"; if you try to
insert an item with e.g. `i i' you get prompted but after typing the
item text and hitting RET, you get "todo-basic-insert-item: Args out of
range: 1, 2".  Similar errors and other odd behavior can occur if you
leave the Todo mode buffer live after deleting the file, and can arise
later, after adding more todo files and using other commands.  So I
guess I have to bite the bullet and make Todo mode catch these errors.

Steve Berman

Re: Question about handling file deletion

[Stefan Monnier]

> E.g. bug#14688.  If you have debug-on-error enabled, you get the two
> backtraces Leo reported (wrong-type-argument due to (find-file-noselect
> nil), followed by file-error "Removing old name" "no such file or
> directory" due to calling delete-file on the file that was already
> deleted).  But if debug-on-error is disabled, you just get "Removing old
> name: no such file or directory, /data/steve/.emacs.d/todo/Todo.todo" in
> the echo area and above it a buffer in Todo mode whose name is the todo
> file you just created.  If you try to add a category, you get
> "find-file-noselect: Wrong type argument: stringp, nil".  If you
> mistakenly think there is a category and try to navigate with `f' or
> `b', you get "todo-forward-category: Arithmetic error"; if you try to
> insert an item with e.g. `i i' you get prompted but after typing the
> item text and hitting RET, you get "todo-basic-insert-item: Args out of
> range: 1, 2".  Similar errors and other odd behavior can occur if you
> leave the Todo mode buffer live after deleting the file, and can arise
> later, after adding more todo files and using other commands.  So I
> guess I have to bite the bullet and make Todo mode catch these errors.

Indeed, these errors seem annoying enough that we should try to handle
it a bit better.


        Stefan

Re: Question about handling file deletion

[Timur Aydin]

On 6/26/2013 3:22 PM, Stephen Berman wrote:
> If a package provides functionality for deleting files used by it, is it
> considered a bug in the package if it does not handle the situation
> where a user deletes such files using a command outside of the package
> and this causes errors when using the package which don't arise if the
> package file-deletion functionality is used?  I'm faced with this issue
> in the new version of todo-mode.el (see bug#14688).  If someone deletes
> a todo file using e.g. Dired and then gets an error in Todo mode and
> reports it as a bug, is it kosher for me reply "If it hurts, don't do
> that.  Use todo-delete-file." and close the bug?  (That command doesn't
> actually exist yet, but I think it will be much easier to implement than
> trying to handle the result of deleting todo files outside of Todo
> mode.)

When I visit a file and then delete that file using "rm", the buffer of 
that file is still there and emacs doesn't do anything about it. So if 
somebody deletes a TODO file, why not let the todo information stay in 
the respective buffer? So what is different about todo-mode.el that 
makes it necessary to implement a different behavior?

I'm not criticizing you motivation, only trying to understand the 
situation better.

-- 
Timur

Re: Question about handling file deletion

[Stephen Berman]

On Sat, 29 Jun 2013 16:37:25 +0300 Timur Aydin <ta@taydin.org> wrote:

> On 6/26/2013 3:22 PM, Stephen Berman wrote:
>> If a package provides functionality for deleting files used by it, is it
>> considered a bug in the package if it does not handle the situation
>> where a user deletes such files using a command outside of the package
>> and this causes errors when using the package which don't arise if the
>> package file-deletion functionality is used?  I'm faced with this issue
>> in the new version of todo-mode.el (see bug#14688).  If someone deletes
>> a todo file using e.g. Dired and then gets an error in Todo mode and
>> reports it as a bug, is it kosher for me reply "If it hurts, don't do
>> that.  Use todo-delete-file." and close the bug?  (That command doesn't
>> actually exist yet, but I think it will be much easier to implement than
>> trying to handle the result of deleting todo files outside of Todo
>> mode.)
>
> When I visit a file and then delete that file using "rm", the buffer of that
> file is still there and emacs doesn't do anything about it. So if somebody
> deletes a TODO file, why not let the todo information stay in the respective
> buffer? 

It does, and this can cause problems, as I elaborated in this thread.

>         So what is different about todo-mode.el that makes it necessary to
> implement a different behavior?
>
> I'm not criticizing you motivation, only trying to understand the situation
> better.

I tried to explain that here:

http://lists.gnu.org/archive/html/emacs-devel/2013-06/msg01154.html

But in this followup:

http://lists.gnu.org/archive/html/emacs-devel/2013-06/msg01216.html

I acknowledged that it's better to handle external file deletion, and
that's what I'll try to do.

Steve Berman