Re: Switching disks when accessing a filesystem
Re: Switching disks when accessing a filesystem
- Subject: Re: Switching disks when accessing a filesystem
- From: Marek Kozubal <email@hidden>
- Date: Mon, 1 Mar 2004 17:01:50 -0500 (EST)
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
email@hidden
_______________________________________________
darwin-kernel mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/darwin-kernel
Do not post admin requests to the list. They will be ignored.