Amit -
I agree with what you're saying here, but I also agree with
Thierry that there should be a way for users to somehow propagate
changes that happened remotely into their user-space file system.
Currently [as of MacFUSE 1.5] there is no functional way for a user-
space file system developer to actually accomplish this.
We attempted to use fuse_purge_path_np in 1.3.1 and 1.5.1 and we'd
always get a segmentation fault somewhere in
ino = fuse_lookup_inode_by_path_np(path);
Perhaps it was our testing was improper - but we'd tried basic
flushing of a hardcoded pathname from within our filesystem and it
always segfaulted out. Nevertheless, even if it did work, in 1.5.1
fuse_internal_ioctl_avfi doesn't touch ubc_setsize or call
FUSE_KNOTE() for WRITE/EXTEND/ATTRIB
The updated code in SVN [1.6.1]for fuse_purge_np seems to be working
great and the new fuse_internal_ioctl_avfi has much more logic.
It performs a purge that notes that a file extension has happened -
which is definitely something we'd needed. Thanks for the effort with
the new plumbing down there. We would really love to incorporate some
of this functionality into ExpanDrive without the cost of turning on
nolocalcaches - it is debilitatingly slow for us.
We have the facilities in our cache to easily notice when the file has
been modified on the server and until we can call on the new purge
capabilities in 1.6.1, we're lacking the ability to provide any
semblance of coherence. I was wondering if you had any mental picture
of what else was needed to build up to a 1.6 release to the public and
if there was a rough gauge of timing on it.
Thanks
-Jeff
In 1.5 fuse_purge_path_np We'd used the
> Now, MacFUSE actually does allow a user-space file system to purge
> individual files' buffer cache in the kernel. The user-space file
> system still needs to figure out when something gets updated on the
> "remote" side, and then needs to tell MacFUSE about it. Unlike your
> GUI ssh client example, this isn't exactly simple or even desirable
> always: you are not just "refreshing" a window's view; you are
> changing system-wide information. The file in question may be open
> multiple times; it may be in the process of being read from or written
> to; it could be locked; and so on. The remote "update" could be of
> many types too: besides simply being written to, the file could have
> just been deleted; it could have been recreated; it could even have
> been reincarnated with a different type (was a file, now is a
> directory). Reconciling all of this in a real file system is quite
> involved, not just for MacFUSE, but also for the user-space file
> system. There isn't always a good resolution even. SFTP isn't a real
> file system protocol, and such reconciliation isn't implemented in
> sshfs.
>
> Amit
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"macfuse-devel" group.
To post to this group, send email to macfuse-devel@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/macfuse-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
