GNU nano - Bugs: bug #42373, reading in a file into another...
You are not allowed to post comments on this tracker with your current authentication level.
bug #42373: reading in a file into another leaves a lock file behind
Submitter: | Benno Schulenberg <bens> | ||
Submitted: | Thu 15 May 2014 09:15:56 PM UTC | ||
Severity: | 3 - Normal | Status: | Fixed |
Assigned to: | astyanax | Open/Closed: | Closed |
Wed 14 Jan 2015 08:44:41 PM UTC, comment #3: |
Benno Schulenberg <bens>![]() |
Wed 14 Jan 2015 02:37:18 AM UTC, comment #2: Hey Benno, this should be fixes as of r5104. Hopefully this fix didn't break something else, let me know if you do find something. |
Chris Allegretta <astyanax>![]() ![]() |
Sun 18 May 2014 10:44:12 AM UTC, comment #1: It seems it has to do with reading in another file. To reproduce, do: 'nano stuck', then type ^R TODO <Enter> ^X <Y> <Enter>, and then see how there is still a .stuck.swp file. |
Benno Schulenberg <bens>![]() |
Thu 15 May 2014 09:15:56 PM UTC, original submission:
Since a few days I have 'set locking' in my .nanorc file, and twice a day or so I get the message that someone else is editing the file I'm trying to open -- but the PID given in the message is long gone. I haven't figured out yet when this occurs.
|
Benno Schulenberg <bens>![]() |
No files currently attached
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 5 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2015-03-23 | bens | Status | Ready For Test | ![]() |
Fixed |
Open/Closed | Open | ![]() |
Closed | ||
2015-01-14 | astyanax | Status | None | ![]() |
Ready For Test |
Assigned to | None | ![]() |
astyanax | ||
2014-06-17 | bens | Summary | Quite often nano finds a stale lock file | ![]() |
reading in a file into another leaves a lock file behind |
Hi Chris. It worked well during the first five minutes of testing...
However, the error message in delete_lockfile() is of very little use, because when it gets triggered, either nano closes or immediately switches to another buffer, so it would be visible for maybe a millisecond. And in the current situation in never gets shown anyway -- even when I add a sleep(2) after the message (and then test it by making the dir unwritable after nano has opened a file), nothing gets shown. The flushing of the statusbar to the screen is missing.
Oh, the response to 'src/nano TODO/file' (opening a file in nonexistent directory that has the name of an existing file) is interesting: Cancelled.
And the response to 'src/nano nothing/file' is no longer that there was an error writing the lock file; instead there is no complaint at all -- until the first character is typed; then it warns about editing an unlocked file.
In both these cases it should complain that an invalid directory name was used, and then skip the file.