[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwrite-devel
Subject:    [Bug 76942] file saving, consider vi like save to new file, unlink old,
From:       Johannes Sixt <johannes.sixt () telecom ! at>
Date:       2005-12-20 23:00:08
Message-ID: 20051220230008.29710.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=76942         




------- Additional Comments From johannes.sixt telecom at  2005-12-21 00:00 -------
> As far as #12 is concerned, I don't understand. Why not doing simply: 
> 1. Save to temporary 
> 2. Rename foo to foo~ 
> 3. Rename temporary to foo 

Because between 2. and 3. there is a tiny window where foo does not exist. My \
proposal is just good practice, but not a big deal, though.

The following aspect is much, _MUCH_ more important:

> If a file is hard linked, I expect any modification in it to be visible in all \
> links

Frankly, this indicates that you have used the wrong tool for the task: If you want \
to propagate changes to other file(names), symlinks are the tool of choice.

Power users use cp -al to copy project trees (like the kernel sources, for example). \
                They precisely do _NOT_ want to propagate any changes to the other \
                links. This way:
- cp -al is _fast_
- you have two conceptually independent trees that take up only little more space \
                than just one tree
- you have super-fast diff -r

IOW: This is a good thing to have.
_______________________________________________
KWrite-Devel mailing list
KWrite-Devel@kde.org
https://mail.kde.org/mailman/listinfo/kwrite-devel


[prev in list] [next in list] [prev in thread] [next in thread]