Ticket #12 (closed defect: fixed) — at Version 11
savannah: Open a symlink to edit when save, erase symlink and make a new file.
Reported by: | slavazanko | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | |
Component: | mcedit | Version: | master |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Branch state: | no branch | Votes for changeset: |
Description (last modified by ossi) (diff)
Original: http://savannah.gnu.org/bugs/?13091
Submitted by: | None | Submitted on: | Sun 15 May 2005 10:19:33 PM UTC |
Category: | Editor | Severity: | 3 - Normal |
Status: | Need Info | Privacy: | Public |
Assigned to: | None | Open/Closed: | Open |
Release: | 4.6.0 | Operating System: | GNU/Linux |
Original submission:
Open a file by symlink to edit, when close to save changes, MC erase symlink and make a new file. (Erase the symlink)
Comment 1 by wwp <wwp> at Sun 15 May 2005 10:41:59 PM UTC:
I do my best to avoid this behaviour in mc for years :-\ (now w/ 4.6.1-pre4a). I hope it's not by design that mc replaces an edited symlink w/ the target file when saving/editing it!
Comment 2 by Leonard den Ottolander <leonardjo> at Mon 16 May 2005 02:59:24 PM UTC:
? Could you provide a little more info (platform, example)? $ mcedit foo $ ln -s foo bar $ mcedit bar just edits foo for me (also tried this with 4.6.0). Or am I missing your point?
Comment 3 by wwp <wwp> at Mon 16 May 2005 03:12:51 PM UTC:
GNU/Linux x86, FC3 running mc 4.6.1-pre4 from the sources (was: SuSE 8.x, mc 4.6.x from the sources and older mc versions): $ rm -f foo bar; touch foo; ln -s foo bar; ls -l foo bar lrwxrwxrwx 1 wwp users 3 May 16 17:08 bar -> foo -rw-r--r-- 1 wwp users 0 May 16 17:08 foo $ mcedit bar (press F2 then F10) $ ls -l foo bar 1. -rw-r--r-- 1 wwp users 0 May 16 17:09 bar 2. -rw-r--r-- 1 wwp users 0 May 16 17:08 foo as you see, bar is no longer a symlink but a regular file.
Comment 4 by Leonard den Ottolander <leonardjo> at Mon 16 May 2005 04:11:23 PM UTC:
Weird. I cannot reproduce this on FC1 with MC_4_6_1_PRE from a couple of days ago. Where did you get this pre4 so I can compare? Can you reproduce this with mc-4.6.1-0.14.FC3 (pre3 with patches) or latest MC_4_6_1_PRE? Is it reproducible for non 0 byte files? Could this be a kernel issue?
Comment 5 by Oswald Buddenhagen <ossi> at Mon 16 May 2005 04:27:32 PM UTC:
F9 -> options -> save mode -> switch to "quick save" and everything is fine ... it might be worth consideration, though, to make the "safe save" and "do backups" modes follow symlinks.
Comment 6 by Anonymous at Mon 16 May 2005 04:39:27 PM UTC:
> Weird. I cannot reproduce this on FC1 with MC_4_6_1_PRE from a couple of days ago. Where did you get this pre4 so I can compare? I cannot remember, official places to find mc tarballs are still obscure to me. But IIRC it was from a "official" location as well as previous mc version I've been using. > Can you reproduce this with mc-4.6.1-0.14.FC3 (pre3 with patches) or latest MC_4_6_1_PRE? I reproduce it at least w/ mc-4.6.1a-0.8 (FC3 rpm). Let me know if other tests are necessary (just seen Oswald's post, BTW it's right that "Safe save" was set in my settings). > Is it reproducible for non 0 byte files? Yes it is. > Could this be a kernel issue? I would say no, since I face this behaviour for years (kernels 2.4.x, up to 2.6.11).
Change History
comment:3 Changed 15 years ago by angel_il
- severity set to no branch
- Milestone changed from 4.7 to 4.7.0-pre2
comment:8 Changed 13 years ago by andrew_b
- Branch state set to no branch
- Milestone changed from 4.7 to Future Releases
Note: See
TracTickets for help on using
tickets.
F9 -> options -> save mode
Bug reproduced with any switch, with the exception of "quick save"