Changes between Initial Version and Version 11 of Ticket #12


Ignore:
Timestamp:
01/11/14 15:37:39 (10 years ago)
Author:
ossi
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #12

    • Property Status changed from new to closed
    • Property Severity changed from to no branch
    • Property Version changed from to master
    • Property Branch state changed from to no branch
    • Property Resolution changed from to fixed

  • Ticket #12 – Description

    initial v11  
    77||Release:||4.6.0||Operating System:||GNU/Linux|| 
    88 
    9 Discussion: 
     9Original submission: 
    1010{{{ 
    11 Mon 16 May 2005 04:39:27 PM UTC, comment #6: 
     11Open a file by symlink to edit, when close to save changes, MC erase 
     12symlink and make a new file. (Erase the symlink) 
     13}}} 
    1214 
     15Comment 1 by wwp <wwp> at Sun 15 May 2005 10:41:59 PM UTC: 
     16{{{ 
     17I do my best to avoid this behaviour in mc for years :-\ (now w/  
     184.6.1-pre4a). I hope it's not by design that mc replaces an edited  
     19symlink w/ the target file when saving/editing it! 
     20}}} 
     21 
     22Comment 2 by Leonard den Ottolander <leonardjo> at Mon 16 May 2005 02:59:24 PM UTC: 
     23{{{ 
     24? Could you provide a little more info (platform, example)? 
     25 
     26$ mcedit foo 
     27$ ln -s foo bar 
     28$ mcedit bar 
     29 
     30just edits foo for me (also tried this with 4.6.0). Or am I missing  
     31your point? 
     32}}} 
     33 
     34Comment 3 by wwp <wwp> at Mon 16 May 2005 03:12:51 PM UTC: 
     35{{{ 
     36GNU/Linux x86, FC3 running mc 4.6.1-pre4 from the sources (was: SuSE 
     378.x, mc 4.6.x from the sources and older mc versions): 
     38 
     39$ rm -f foo bar; touch foo; ln -s foo bar; ls -l foo bar 
     40 
     41lrwxrwxrwx 1 wwp users 3 May 16 17:08 bar -> foo 
     42-rw-r--r-- 1 wwp users 0 May 16 17:08 foo 
     43 
     44$ mcedit bar 
     45(press F2 then F10) 
     46 
     47$ ls -l foo bar 
     48 
     49   1. -rw-r--r-- 1 wwp users 0 May 16 17:09 bar 
     50   2. -rw-r--r-- 1 wwp users 0 May 16 17:08 foo 
     51 
     52as you see, bar is no longer a symlink but a regular file. 
     53}}} 
     54 
     55Comment 4 by Leonard den Ottolander <leonardjo> at Mon 16 May 2005 04:11:23 PM UTC: 
     56{{{ 
     57Weird. I cannot reproduce this on FC1 with MC_4_6_1_PRE from a  
     58couple of days ago. Where did you get this pre4 so I can compare? 
     59 
     60Can you reproduce this with mc-4.6.1-0.14.FC3 (pre3 with patches) or 
     61latest MC_4_6_1_PRE? Is it reproducible for non 0 byte files? Could  
     62this be a kernel issue? 
     63}}} 
     64 
     65Comment 5 by Oswald Buddenhagen <ossi> at Mon 16 May 2005 04:27:32 PM UTC: 
     66{{{ 
     67F9 -> options -> save mode -> switch to "quick save" 
     68and everything is fine ... 
     69 
     70it might be worth consideration, though, to make the "safe save" and 
     71"do backups" modes follow symlinks. 
     72}}} 
     73 
     74Comment 6 by Anonymous at Mon 16 May 2005 04:39:27 PM UTC: 
     75{{{ 
    1376> Weird. I cannot reproduce this on FC1 with MC_4_6_1_PRE from a  
    1477couple of days ago. Where did you get this pre4 so I can compare? 
    … …  
    37100I would say no, since I face this behaviour for years (kernels  
    381012.4.x, up to 2.6.11). 
    39         Anonymous 
    40 Mon 16 May 2005 04:27:32 PM UTC, comment #5: 
    41  
    42 F9 -> options -> save mode -> switch to "quick save" 
    43 and everything is fine ... 
    44  
    45 it might be worth consideration, though, to make the "safe save" and 
    46 "do backups" modes follow symlinks. 
    47         Oswald Buddenhagen <ossi> 
    48 Mon 16 May 2005 04:11:23 PM UTC, comment #4: 
    49  
    50 Weird. I cannot reproduce this on FC1 with MC_4_6_1_PRE from a  
    51 couple of days ago. Where did you get this pre4 so I can compare? 
    52  
    53 Can you reproduce this with mc-4.6.1-0.14.FC3 (pre3 with patches) or 
    54 latest MC_4_6_1_PRE? Is it reproducible for non 0 byte files? Could  
    55 this be a kernel issue? 
    56         Leonard den Ottolander <leonardjo> 
    57 Project Member 
    58 Mon 16 May 2005 03:12:51 PM UTC, comment #3: 
    59  
    60 GNU/Linux x86, FC3 running mc 4.6.1-pre4 from the sources (was: SuSE 
    61 8.x, mc 4.6.x from the sources and older mc versions): 
    62  
    63 $ rm -f foo bar; touch foo; ln -s foo bar; ls -l foo bar 
    64  
    65 lrwxrwxrwx 1 wwp users 3 May 16 17:08 bar -> foo 
    66 -rw-r--r-- 1 wwp users 0 May 16 17:08 foo 
    67  
    68 $ mcedit bar 
    69 (press F2 then F10) 
    70  
    71 $ ls -l foo bar 
    72  
    73    1. -rw-r--r-- 1 wwp users 0 May 16 17:09 bar 
    74    2. -rw-r--r-- 1 wwp users 0 May 16 17:08 foo 
    75  
    76 as you see, bar is no longer a symlink but a regular file. 
    77         wwp <wwp> 
    78 Mon 16 May 2005 02:59:24 PM UTC, comment #2: 
    79  
    80 ? Could you provide a little more info (platform, example)? 
    81  
    82 $ mcedit foo 
    83 $ ln -s foo bar 
    84 $ mcedit bar 
    85  
    86 just edits foo for me (also tried this with 4.6.0). Or am I missing  
    87 your point? 
    88         Leonard den Ottolander <leonardjo> 
    89 Project Member 
    90 Sun 15 May 2005 10:41:59 PM UTC, comment #1: 
    91  
    92 I do my best to avoid this behaviour in mc for years :-\ (now w/  
    93 4.6.1-pre4a). I hope it's not by design that mc replaces an edited  
    94 symlink w/ the target file when saving/editing it! 
    95         wwp <wwp> 
    96 Sun 15 May 2005 10:19:33 PM UTC, original submission: 
    97  
    98 Open a file by symlink to edit, when close to save changes, MC erase 
    99 symlink and make a new file. (Erase the symlink) 
    100102}}}