mcedit file locking
Oswald Buddenhagen
ossi at kde.org
Tue Mar 25 15:10:03 UTC 2003
On Tue, Mar 25, 2003 at 01:59:12AM -0500, Pavel Roskin wrote:
> 3) System-wide locks using fcntl() or (if not supported) flock().
>
i'd go with that one.
> Pro: No stale locks. Works in non-writable directories. Locking between
> users.
>
and it's simple (except the #ifdef for fcntl vs. flock). the other
variants get hairy once you try to get around the stale lock problem.
> Con: not 100% portable, but should work on most modern systems.
>
and it's halfways broken over nfs - at least one of the variants. check
out the man page.
> Locks affect other software.
>
that's a) not exactly a downside, if you ask me and b) usually not true,
as the locks are only advisory, not mandatory, so "the other"
application has to use locking itself to notice what we do.
one thing to note is, that cooledit would need to keep the file open all
the time. dunno if it does currently.
> Should the lock be held for the whole time when the file is being edited
>
yes. that was my point in the initial request. i want a warning like "this
file is already being edited. still want to open it? (No/yes)".
> or just for the time when it's being saved?
>
that helps against corrupting the file if two instances try to write out
at once, but is otherwise useless.
> Do we want the locks to affect other software?
> Do we want locks to be shared between users?
>
it would not hurt. i don't care much, personally.
> With all that complexity I feel that we probably should postpone the issue
> or find a popular editor that used locking already and implement locking
> in a compatible way.
>
hmm, and what if multiple popular editors use different approaches? :}
greetings
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.
More information about the mc-devel
mailing list