Re: [GNOME VFS] Re: Daemons [Was: gob inside gnome-vfs ...]
- From: Maciej Stachowiak <mjs noisehavoc org>
- To: Seth Nickell <snickell stanford edu>
- Cc: Maciej Stachowiak <mjs noisehavoc org>, Michael Meeks <michael ximian com>, Jeff Waugh <jdub perkypants org>, vfs <gnome-vfs ximian com>, gnome-hackers gnome org
- Subject: Re: [GNOME VFS] Re: Daemons [Was: gob inside gnome-vfs ...]
- Date: Sun, 30 Jun 2002 23:39:08 -0700
On 29Jun2002 03:00AM (-0700), Seth Nickell wrote:
>
> If you change the second paragraph of an AbiWord document and then run
> an XML tool on the document that indents the file would it be acceptable
> for one of these changes to be lost 5 seconds later? To me, the answer
> is unclear, but probably "no".
Sounds plausible to me, but this problem is harder to solve.
> I'm claiming that this problem of having multiple processes accessing
> the file at once is primarily a result of an engineering choice made
> with Nautilus, namely to structure Nautilus out of a multitude of
> in-process components that do not synchronize with each other for access
> to resources.
What do you think of my hypothetical but not completely implausible
example of multiple apps changing metadata at the same time? Apps
don't do this now, but if they did, it would be fairly likely to do
something to a file in the file manager and in some other app close
together in time.
> I think we may be miscommunicating here. I definitely prefer to have
> locking of metadata done in GnomeVFS. It seems safer and saner. What I
> don't understand is how you can want locking of metadata and not find it
> reasonable for files?
Now you're really confusing me. I never said anything about the
desirability of synchronizing access to file data. I thought this
discussion started when I offhandedly mentioned how gnome-vfs might
want a daemon for metadata, and you questioned why this was even
necessary.
POSIX provides locking calls for the filesystem, so it's reasonable
for gnome-vfs to expose this too.
The key way in which metadata is different is that metadata has a
well-known structure, so the correct synchronization strategy is
obvious and can be a built-in part of the API.
But files are just bags of bytes, so locking strategy needs to be
determined per-application. Making all open calls implicitly grab an
exclusive lock, for example, would not work since in some cases
parallel access to the file is safe and indeed required for correct
operation. This is why an API for access to file data can't do much
more than provide locking calls to the application, while a metadata
API can (and should, IMO) take care of all the synchronization issues.
Regards,
Maciej
[Date Prev][
Date Next] [Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]