dvfs locking

[Waldo Bastian]

On Friday 04 March 2005 20:11, Sean Middleditch wrote:
> Locking is one of the more complex issues when dealing with file
> storage, and probably the one issue I'm personally very ignorant about.
>
> I'm wondering, first of all, do we need it, and why?  Do normal desktop
> apps (and I only care about desktop apps, not GCC or Apache or some
> whatever) normally lock the documents they're working on?  Is the
> locking simply because they want to atomically write the file, or to
> prevent modification while the document is in use?  Is the prevention of
> modification due to trying to handle concurrent editing, versioning, or
> because apps only keep portions of the document in memory and don't want
> their "cache" changing under them?

I think it would be really neat to have support in applicatons for a document 
server where multiple people can access and modify documents. In such a 
scenario you want to have some sort of locking support in your applications 
to make sure that people don't overwrite each other changes.

WebDAV seems to be designed with such a scenario in mind.

I'm not aware of any KDE application that does any form of locking on its 
documents. We do locking on config files to ensure atomic "read-update-write" 
cycles there. Most KDE applications use atomic writes (write+rename) to write 
their documents. Some applications check modification dates before writing 
back changes.

> It's not so much weather D-VFS will do locking or not, but how it will
> do it.  If desktop apps do locking for atomic writes, then it makes a
> hell of a lot more sense to just make write operations atomic if it's at
> all possible and not requires applications to explicitly lock and unlock
> the file during a write.  If applications use locking for versioning
> purpose, where that's only even available on a limited number of
> protocols/filesystems, it would make more sense to add a versioning API
> versus making apps do a bunch of the details manually.
>
> Do keep in mind that locking is not a supportable feature on many
> protocols, so any case where locking would be used will still have to be
> optional in all applications, since it isn't even emulatable on many
> protocols.
>
> Looking forward to your feedback and wisdom, everyone.  ;-)

I think some "write if file has not changed or fail otherwise" semantic could 
be useful. That way you can ensure the integrity of a "read-update-write" 
cycle. (Is that what you mean with versioning API?)

Cheers,
Waldo
-- 
bastian at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050305/fac98195/attachment.pgp