2003 17:40:52 +0200, wrote:

> > yes, I mean conflict, which will take the volume into a WriteDisconnected
> > mode? Or not necessary?
> 
> As I understand it yes; and then you have to repair the conflict before 
> further changes will be propagated to the server. But I'm still new to coda.

Yes, that's right, I was just double checking it.
(Someone who knows the code can shed some light on this topic?)

> > So I was wondering, wont it be good if the server actually checks if the
> > file is open rw, only when the volume is Connected in diconnected mode this
> > check should be skipped.
> 
> Meaning if it's already opened the second process attempting to open it will 
> fail?

Normally and obviously why? Because there is no sane mechanism which will be able to merge
the content of those N files.

> Of course, that is desirable. But I would personally rather have the full 
> support for disconnected operation on both clients and servers. And as long 
> as that is supported, any file locking functionality is going to be 
> semi-reliable at best, and the question is how useful that would be.

I think it's a good idea since we'll be able to have one less option for a volume to go
WriteDisconnected, due to this fault. Basically the lock should work only and only when
the server is in Connected mode, that means that the in WriteDisconnected mode this
feature wont work (naturally).


Jan any comments?



cheers