bugGNU nano - Bugs: bug #58343, [Wish] nano should save to a new...

 
 

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

bug #58343: [Wish] nano should save to a new file, then rename it to the old

Submitter:  Peter Passchier <pepa65>
Submitted:  Sun 10 May 2020 10:15:23 AM UTC
   
 
Severity:  1 - Wish Status:  Wont Fix
Assigned to:  None Open/Closed:  Closed

Thu 03 Mar 2022 10:22:17 AM UTC, comment #5: 

Patches are welcome, but until then... won't fix.  The issue of file truncation, however, has been made more clear in git, commit 47c11ae8, by showing an extra and clear warning.

Benno Schulenberg <bens>
Group administrator
Sat 16 May 2020 08:43:57 AM UTC, comment #4: 

The original article was about editing a bash script while it's running (as bash keeps reading its scripts line by line). Which of course is an edge case, and stupid, but leaving the original inode out of the newly saved file means that bash can keep reading the same content it was started with, and the saved changed file is elsewhere.

Does the editor clobber or supersede? So nano clobbers, emacs and vim (if writebackup is set, which it is by default) supersede. Another way to look at it is, is your save action atomic or not? (For instance, Sublime Text clobbers when "atomic_save": false, but supersedes by default.) Move operations are atomic, but saving by overwriting isn't.

It seems a lot of the more sophisticated editors make this configurable, and often have the 'supersede' option as the default, I guess because it is considered safer.

Because nano was often mentioned in the discussions as a 'clobber' editor, and I use nano most often, I thought it would be good to bring it up (again?).

Peter Passchier <pepa65>
Fri 15 May 2020 03:14:22 PM UTC, comment #3: 

Certainly I'm interested in the context, but not in a chaotic pile of chatter.  :|

But what other problem or risk (other than getting a truncated file when the file system is full and under pressure) does writing to the same inode have?

Benno Schulenberg <bens>
Group administrator
Sun 10 May 2020 04:04:35 PM UTC, comment #2: 

Sorry, I thought you'd be interested in the context. The problem is that a changed file is saved over the old file, while it seems that the better 'industry practice' is to save to a new file, to be more safe, as moves/renames are atomic.

Yes, this would require two ways of saving the file and checking which is possible.

Peter Passchier <pepa65>
Sun 10 May 2020 03:18:25 PM UTC, comment #1: 

What exactly is the problem?  (In other words: don't give me a URL and expect me to read all that stuff and figure out what the problem might be.)

Nano already uses the same inode when saving the chanegs to an existing file.  The one issue that this might lead to is bug #36864 (truncated, empty file when filesystem is full).  That it would be better if nano wrote to a new file and then renamed the new over the old is mentioned in bug #36864 comment #8.  But it would mean that nano needs two ways of writing a file: the current one when the relevant directory is unwritable, and the better one otherwise.

Benno Schulenberg <bens>
Group administrator
Sun 10 May 2020 10:15:23 AM UTC, original submission:  

There is a whole thing that came up on some editors reusing the same inode (not sure about other file systems' equivalents) that the file originally was on. Salient discussion here:

https://news.ycombinator.com/item?id=23087308

One of the editors that does this is nano; others like vim, dte, sed seem to intentionally save a (changed) file on a new inode and then removing (unlinking) the old name.

Maybe this has already come up in the past, but I thought it would be worth some attention.

Peter Passchier <pepa65>

 

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

No files currently attached

 

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 pepa65 (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 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-03-14 bens Open/ClosedOpen Closed
    2022-03-03 bens StatusNone Wont Fix
    2020-05-15 bens Severity3 - Normal 1 - Wish
        StatusInvalid None
        Summarynano uses the same inode when saving a file [Wish] nano should save to a new file, then rename it to the old
    2020-05-10 bens StatusNone Invalid
        SummaryUse the same inode after saving a file nano uses the same inode when saving a file

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code