On Fri, 27 Feb 2004, Dave Rehring wrote:
What I want to do is, when the user double-clicks on a file in
FileSystemA/VolumeA that I'm writing is:
FYI, you can not tell an fopen() call from POSIX from a double click from the Finder in a VFS file system.
-copy the selected file to a folder pre-selected by the end-user on VolumeB
-have the OS directly access the file on VolumeB as if there was no VolumeA
This sounds simular to the null file system. It simply takes one part of the file system, and puts a copy some where else. However, this approch uses a layered file system and Apple hightly suggests not using layered file systems. But it might be worth the risk in it breaking depending on your goals. It's a little tricky to do this since copying an entire file from within a VFS stack can be non-trivial.
From looking at the WebDAV source in Darwin, it appears that it kind of does
this, except it 'happens' at the wrong spot. It downloads the file into
/tmp, but applications don't directly access it. They still go through the
WebDAV filesystem, which accesses the file in /tmp. I need to instead have
applications directly access the file [so if they double-click on a file
twice, two copies of the file would be in the local folder for example].
You will need to do something simular to webdev in the fact that there's a user daemon doing a lot of the work.
I was thinking of trying to track down the vnode of the file on VolumeB
[after I copy the file from VolumeA to VolumeB] and returning that vnode
instead of one from VolumeA.
Does this sound like a reasonable thing to do, or would the OS get confused
about this sort of thing?
This is a very nullfs like thing to do, you'd cover the real vnode with one from nullfs, and have nullfs redirct the operations to the appropriate file by swaping around vnodes. If you're only planning on supporting HFS/HFS+, I might suggest just copying outright the HFS+ source, convert it to a kext, and make it override the normal HFS+ matching and add whatever bits to make it work there, which would avoid the layering problem. --- Marek Kozubal marek@portents.com _______________________________________________ darwin-kernel mailing list | darwin-kernel@lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-kernel Do not post admin requests to the list. They will be ignored.