bugGNU nano - Bugs: bug #61883, cancelling the overwriting of a...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #61883: cancelling the overwriting of a changed file at Exit does not cancel the exit

Submitter:  Tasos Papastylianou <tpapastylianou>
Submitted:  Thu 20 Jan 2022 04:39:09 PM UTC
   
 
Severity:  3 - Normal Status:  Fixed
Assigned to:  bens Open/Closed:  Closed

Jump to the original submission

Thu 10 Feb 2022 09:10:21 AM UTC, comment #6: 

Released in nano-6.1.  Thank you for reporting!

Benno Schulenberg <bens>
Group administrator
Sat 22 Jan 2022 11:59:48 AM UTC, comment #5: 

Fixed in git, commit 1c074cc8, by staying at the filename prompt when the user Cancels (after having typed ^X Y <Enter>).  Thanks for reporting the problem, and for confirming the fix.

Bug existed since version 2.9.0.  The offending commit was 217cfbf3: "check for a changed disk file also for 'savefile' and --tempfile", which fixed bug #51040.

About the wording of the prompt...  It can't be helped.  I hate prompts that contain instructions about how to answer them, so that's not going to happen.  Also, you keep talking about "save-on-exit", but I don't see what that has got to do with it.  I could reproduce the issue also when using --saveonexit.  In fact, when using that option, it is much clearer that the user chose to exit and that nano will exit whether the user chooses Yes or No, and that the only way to stop nano from exiting is Cancel.

Anyway, the issue is self-inflicted.  If the user chooses to open the same file multiple times (in the same nano or in different nanos), they should be prepared for trouble.  When they then panic at a prompt... they themselves are to blame.  (And if it's in a multi-user environment, they really should be using --locking, and the one that ignored the lock is the culprit.)

(If you still want to suggest a rewording of the prompt, file a new issue.  But prompts have to be short.  Several translations of this particular prompt are already 70 characters long.  They should really not become any longer.)

Benno Schulenberg <bens>
Group administrator
Sat 22 Jan 2022 12:09:05 AM UTC, comment #4: 

Dear Benno!

I can confirm that the patch is a good solution from a programmatic point of view!




However, from a behavioural / linguistic point of view, the phrasing of the message shown can still trip the user very easily into pressing No when they should be pressing Cancel instead.
Consider this scenario:

> Nano: File modified since you opened it; continue saving?"
> User: Oh, shit, I'm about to overwrite something potentially important. So, NO, I don't want to continue! Stop!
> User: (presses 'No', unintentionally discarding all their hard work)

In other words, the phrasing "continue saving?" makes the user instinctively answer 'no', with the intent of aborting the 'overwriting'. But they end up "not saving and then proceeding to exit" instead, potentially losing important changes.


In theory, the least-work change would be to change this message to something that would be more or less compatible with both a 'save-on-exit' scenario as well as a 'plain-save' one, e.g.:

> File modified since you opened it; continue saving? ('Y' to overwrite, 'N' to ignore saving, '^C' to abort operation)


But, having said that, I think what would make the most sense would be to create a brand new message for the specific case of save-on-exit. E.g. something like:

> File modified since you opened it; continue saving? (Note: 'No' will exit without saving!)




Also, as a minor thing. While the second patch seems more sensible, the comment on your first patch made it a lot easier for me to understand what was going on and follow the code. From a "help newbies read the code" point of view, it might be nice to add a comment or something next to what the choices do in that context :)

e.g. :


if (choice == 1) // 'Yes'
else if (choice == 0)  // 'No'
else if (choice < 0) // 'Cancel'


(you have a similar comment in search.c, from what I've seen)




Tasos Papastylianou <tpapastylianou>
Fri 21 Jan 2022 03:13:49 PM UTC, comment #3: 

A better proposed patch is attached.

(file #52704)

Benno Schulenberg <bens>
Group administrator
Fri 21 Jan 2022 02:34:59 PM UTC, comment #2: 

I think attached patch fixes the problem.  Please try it out.

(file #52703)

Benno Schulenberg <bens>
Group administrator
Fri 21 Jan 2022 11:17:37 AM UTC, comment #1: 

Hmm...  I never get there because I always type ^S before typing ^X (or type ^X^Q when I don't want to keep the changes), so for me it hasn't started to exit and it just cancels the Save.  I agree that in your case it ought to cancel the Exit, but... I don't know if that will be possible without major replumbing.

Benno Schulenberg <bens>
Group administrator
Thu 20 Jan 2022 04:39:09 PM UTC, original submission:  

Assume the following scenario.

0. You open 'file.txt' in nano (instance #1)
0. Without exiting #1, you open 'file.txt' in nano again (instance #2). #2 informs you that the file is already open and asks you to confirm if you really want to continue editing. Select yes.
0. Make a change in #2, save normally and exit.
0. Make a change in #1.

At this point, if you press Ctrl-X to exit, hoping to be prompted to save any unsaved changes while exiting, nano does the following

0. Save modified buffer?  (press yes)
0. File name to write? (confirm 'file.txt')
0. Nano will inform you the file has changed on disk and ask you if you want to save anyway!

At this point, expected behaviour would be:

- Press 'Yes' if you want to save anyway, overwriting any changes made externally.
- Press 'No' if you want to exit, discarding all local changes (and thus keeping the external version).
- Press 'Cancel' to abort EXITING, and continue editing (possibly to save a backup of the local version without tampering with the external version).

Instead what happens is that both 'No' and 'Cancel' exit nano, discarding all changes.




== Why is this the wrong behaviour?

Programmatically, this behaviour makes sense. If you've reached the "save file?" dialogue, if you say 'no' or 'cancel', it will abort ONLY the 'save' action, and continue with what it was doing before, i.e. the 'exit' action.

However, this is not meaningful in the above scenario. If you are about to save a file and you are confronted with the 'file has changed on disk' message, and you are not sure how, the most natural thing to want to do is to abort the exiting part (not just the saving part), and while nano is still open, attempt to save a backup under a different name, so that you can 'diff' this against the file on disk to see what changed and if it's worth keeping / merging the difference.

As it is now, even if you press "Cancel", nano will still exit and you will lose all your unsaved changes. I would treat this behaviour as a bug.

Tasos Papastylianou <tpapastylianou>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #52703:  cancel-an-exit.patch added by bens (370B - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bens (Posted a comment)
  • -email is unavailable- added by tpapastylianou (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-02-10 bens Open/ClosedOpen Closed
        Discussion LockLocked None
    2022-01-22 bens StatusReady For Test Fixed
        Discussion LockNone Locked
    2022-01-21 bens Attached File- Added 0001-files-let-C-cancel-the-exiting-when-the-file-on-disk.patch, #52704
    2022-01-21 bens Attached File- Added cancel-an-exit.patch, #52703
        StatusNone Ready For Test
    2022-01-21 bens Assigned toNone bens
        Summary&quot;Save at Exit&quot; Cancel option does not cancel exit. cancelling the overwriting of a changed file at Exit does not cancel the exit

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code