That's exactly the type of thing I was thinking of doing. (It will go one
better than the old Netscape in that if there is a lock file because of a
previous crash, or whatever, then it will allow you to take over the lock
if you want to, rather than having to delete it at the operating system
level.)
Wayne
On Tue, 18 Sep 2007, Brian Smith wrote:
> On Tue, 18 Sep 2007, Rasmus Fogh wrote:
>
> > Locking the files would not be that easy to set up. In version 1.1 we
> > can have several Project.xml all pointing to the same set of data. This
> > would make sense if e.g. you were working on different constraint lists
> > and wanted the 'currentConstraintStore' to point to different files.
>
> OK. Looks like things are definitely going to get more complicated.
>
> > Proper handling of concurrent access requires a database. Anything we
> > could do in a file implementation would have to be simple and limited,
> > otherwise we would end inventing our own DB system.
>
> Don't even think of going there!
>
> > I would like a more precise list of the kind of situation people want us
> > to deal with.
>
> It should be rare that two users try to modify the disk copy of a project
> at the same time. In most situations filesystem permissions should
> prevent this from happening.
>
> More likely is that one user accidentally/intentionally opens two copies
> of the same project. Under such circumstances, it would be nice to warn
> the user of the dangerous waters they have entered - you might not want to
> disable functionality because who knows precisely why the second copy had
> been opened.
>
> If we accept the argument for a warning, how could it be implemented? A
> simplistic way to do this would be to create a file called e.g. "lock" in
> the project specific directory on opening a project and remove it on
> closing. It could even contain the python process' PID for validation.
> Then another analysis process opening the same project would know to issue
> the warning. If the lock had not been removed (e.g. due to a previous
> crash), it would be easy for the user to find & remove it and reopen the
> project. There's probably cleverer/more portable ways of doing this.
>
> Brian
>
> --
> Dr. Brian O. Smith ---------------------- B Smith at bio gla ac uk
> Division of Biochemistry & Molecular Biology,
> Institute Biomedical & Life Sciences,
> Joseph Black Building, University of Glasgow, Glasgow G12 8QQ, UK.
> Tel: 0141 330 5167/6459/3089 Fax: 0141 330 8640
>
|