GNU nano - Bugs: bug #36864, saving to a full device can lead...
You are not allowed to post comments on this tracker with your current authentication level.
bug #36864: saving to a full device can lead to emptying the file
Submitter: | Clarence Risher <sparr> | ||
Submitted: | Tue 17 Jul 2012 04:07:24 PM UTC | ||
Severity: | 4 - Important | Status: | Wont Fix |
Assigned to: | None | Open/Closed: | Closed |
Jump to the original submission
Mon 14 Mar 2022 04:33:49 PM UTC, comment #16: |
Benno Schulenberg <bens> |
Mon 14 Mar 2022 03:15:16 PM UTC, comment #15: I propose that a ^X Y failure leading to the original file on disk being lost is the bug, before any further [lack of] interaction from the user. Some of the comments here are about losing data in the buffer that couldn't be written to disk being user error, and I think that could be reasonable. However, that reasoning does not extend to losing data that was already stored on the disk. |
Clarence Risher <sparr> |
Thu 03 Mar 2022 04:11:12 PM UTC, comment #14: If you can't make room, or other processes eat the space up immediately, then... well, you're screwed, nano can't help you there.
|
Benno Schulenberg <bens> |
Thu 03 Mar 2022 12:36:46 PM UTC, comment #13: Hey guys!
|
Lucas Freitas <lucasff> |
Thu 03 Mar 2022 10:19:21 AM UTC, comment #12: The issue has been mitigated somewhat in git, commit 47c11ae8, by giving an extra warning about the file having been truncated, plus a suggestion on how to proceed:
|
Benno Schulenberg <bens> |
Tue 01 Mar 2022 12:26:33 PM UTC, comment #11: Would something like the attached patch be helpful? It prevents the user from simply exiting after a write failure due to an ENOSPC ("No space left on device"). |
Benno Schulenberg <bens> |
Mon 28 Feb 2022 04:37:04 PM UTC, comment #10: Lucas, if you really did Ctrl+X (whereupon nano asked "Save modified buffer?") and you typed N, then nano will not touch the existig file at all. But when you type Y to that question, then you risk losing the file if the disk is full.
|
Benno Schulenberg <bens> |
Mon 28 Feb 2022 02:46:22 PM UTC, comment #9: Hello all. I know this an old bug/thread but I wanted to pitch in. I got bitten by this bug yesterday. I assume this is related to the "swap" file that nano creates and therefore fails in an empty disk.
|
Lucas Freitas <lucasff> |
Tue 01 May 2018 05:45:34 PM UTC, comment #8: Hmm... The thing is, probably, that when writing the current, modified buffer fails due to "No space left", that then the user assumes that the original file is still on the disk and they can therefore safely discard the current buffer and do ^X N. In fact, I cannot blame them. And it would be nice if things indeed worked that way: nano shouldn't truncate and rewrite the target file, it should instead write a temp file, and when that has succeeded, move that temp file over the target file. |
Benno Schulenberg <bens> |
Sat 03 Mar 2018 10:38:23 AM UTC, comment #7: Indeed, when I apply the attached testing patch (which pauses for twelve seconds after opening the file for writing), and then run 'nano box/color.c' and type ^R NEWS <Enter> ^O <Enter>, and then in a second terminal do:
|
Benno Schulenberg <bens> |
Thu 01 Mar 2018 06:33:39 PM UTC, comment #6: Bug #30786 has been marked as a duplicate of this report. |
Benno Schulenberg <bens> |
Thu 01 Mar 2018 05:10:53 PM UTC, comment #5: Hello Clarence and David and anonymous,
|
Benno Schulenberg <bens> |
Mon 14 Jul 2014 10:31:35 PM UTC, comment #4: Hi!
|
Anonymous |
Wed 05 Feb 2014 05:34:43 PM UTC, comment #3: I also did the same thing with nano-2.3.2-2.1.2.x86_64 provided by open suse 13.1. |
david <ballsystemlord> |
Wed 05 Feb 2014 05:32:25 PM UTC, comment #2: Hi, I recreated this bug by repartitioning my hard disk.
|
david <ballsystemlord> |
Thu 10 Jan 2013 03:56:53 AM UTC, comment #1: Hello. Can you let me know what version of nano you were using? There have been several sets of fixes for full files in various versions, but they have not gone back to all stable branches. |
Chris Allegretta <astyanax> |
Tue 17 Jul 2012 04:07:24 PM UTC, original submission:
I was editing a file on a full partition. Attempting to save it yielded an error that the device was full, which was ok. The problem is that this left the file on disk in a zero byte state. This should not happen. |
Clarence Risher <sparr> |
Depends on the following items: None found
Items that depend on this one: None found
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 14 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2022-03-14 | bens | Summary | saving to a full device can lead to an empty file | saving to a full device can lead to emptying the file | |
2022-03-14 | bens | Open/Closed | Open | Closed | |
2022-03-03 | bens | Status | None | Wont Fix | |
2022-03-01 | bens | Attached File | - | Added 0001-files-prevent-the-user-from-just-exiting-after-a-No-.patch, #52943 | |
Status | Need Info | None | |||
2020-11-11 | bens | Assigned to | bens | None | |
2020-07-17 | bens | Summary | saving to full device leads to empty file | saving to a full device can lead to an empty file | |
2018-03-03 | bens | Attached File | - | Added pause-after-opening.patch, #43440 | |
2018-03-01 | bens | Assigned to | astyanax | bens | |
Summary | Saving to full device leads to empty file | saving to full device leads to empty file | |||
2014-02-05 | ballsystemlord | Attached File | - | Added core.xz, #30464 | |
2013-01-10 | astyanax | Severity | 3 - Normal | 4 - Important | |
Status | None | Need Info | |||
Assigned to | None | astyanax |
Powered by Savane 3.13-d3ae.
Corresponding source code
Yes, that ^X Y, or ^O ^M, or simpy ^S, can cause the file on disk to be truncated to zero bytes is the bug. I've adjusted the subject line to make this clearer.