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

List:       koffice-devel
Subject:    Re: Opening the same file twice
From:       "Friedrich W. H.  Kossebau" <Friedrich.W.H () Kossebau ! de>
Date:       2004-03-10 16:22:21
Message-ID: 200403101722.21452.Friedrich.W.H () Kossebau ! de
[Download RAW message or body]

Am Mittwoch, 10. März 2004 14:20 schrieb David Faure:
> On Wednesday 10 March 2004 15:10, Marc Heyvaert wrote:
> > > 2. You open a file that has already been opened. This is a real life
> > > situation and even more so in linux than in Windows because most of us
> > > work on several desktops. When I do portfolio-updates I sometimes open
> > > 10 of them. In MS-Excel there all on the same desktop, all different
> > > windows inside the same application (I prefer it that way for this type
> > > of work). With KSpread you have 10 windows, but if you shuffle your
> > > work around on your desktops you can easily find yourself editing the
> > > same file twice! Saving it twice and losing half of your work without
> > > being aware of it. So this is a second reason why the read-only feature
> > > could be helpfull.
> > >
> > > As to the way to implement it...there are several ways of doing it. I
> > > think that checking if you have write permission must be possible, so
> > > that covers situation 1. For situation 2 a hack could be to write a
> > > semaphor file to the same directory as the directory of the original
> > > file. This file could have 0 bytes, same name, same extension + an
> > > agreed extra extension. Writing this file will be possible because it
> > > comes after the check for (1) and is only needed in case someone opens
> > > the other file for writing. On File|Close and File|Quit the semaphor
> > > file should be removed.
>
> This would lead to many problems if the application (or the X server, or
> the machine) crashes and you end up with a stale "semaphor" file around.
>
> I think this can be implemented in a more robust way by using DCOP to ask
> "is anyone editing that file already"? All running e.g. KOffice apps would
> be awakened and would answer yes if they do (this can be done nicely using
> DCOP's findObject()).
>
> Of course the DCOP solution has one drawback: it won't detect if two users
> (or the same user on two displays) are editing the same file.
> [This is because there is one dcopserver per user and per display].
> To fix this, the "lock file" solution is the only one (but including the
> PID of the app having the lock, or even better, the DCOP app-id, to be able
> to ping it and see if it's still alive and indeed editing that file).

But how will you know whether the lockfile of another user's app is still 
valid? Can you DCOP across systems? Or will we have to wait for DBUS for 
this? What about files loaded via kio? Perhaps one could use the timestamp of 
the lock file. An app should update it every x minutes, if the timestamp is 
older than 3*x minutes the lock file can be taken as invalid?

> Once that works we might want to extend the solution to all of KDE
> (kate/kwrite/etc. would need this too I suppose).
> Cc'ing the Kate developers, I wonder if they thought about this already.

(isn't it kwrite-devel? I have cc:ed there)

This solution is better than nothing, of course. The pragmatic in us says "go 
for it for now." but the perfectionist says "uhm, oh, but..." and reminds of 
non-kde-apps and the mentioned problem with different users and the danger of 
having the user rely on this feature.

Would it make sense to implement this inside the kio slaves? Each slave then 
could try to use the best solution possible, like using some kind of 
"fcntl()" for local files. It's not that no one has ever cared for this ;)

And I guess we should really try to reach for some standards for the 
consistency problem with files accessed via ftp or alike, where there might 
be no support by the os or the protocol for locking. We are glad we can 
transparently deal with files on different systems. But no one seems to have 
cared for the (theoretical) drawbacks. Perhaps because nobody cared for them 
on local systems, too?
Would freedesktop.org be an appropriate place for such a standard?

Friedrich
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

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