VFS write operations
VFS write operations
- Subject: VFS write operations
- From: "Michael Welch" <email@hidden>
- Date: Mon, 11 Sep 2006 18:16:22 -0700
- Thread-topic: VFS write operations
Hello -
I'm writing a VFS (on 10.4) which provides a view of files available in
some repository somewhere but may not actually reside on the local disk,
fetching as necessary (think webdavfs). When I see read/write requests
to one of my vnodes, I pass the operation along with
VNOP_READ/VNOP_WRITE, substituting my vnode with one for a cache file on
disk.
I've hit a wall when it comes to adding write support.
>From the terminal, I can read (e.g. $cat filename), write $echo "foo" >
filename), and append ($echo "foo" >> filename). All seems well.
Then I try to write from a simple app like TextEdit... here's where the
fun begins. I open a file in TextEdit (it can read just fine), make
some changes, and hit save. From what I can decipher, TextEdit performs
the following steps (with the corresponding VNOP's going through my
VFS):
1) Open the existing file, read a whole slew of attributes (permissions,
file size, timestamps, etc.), and then close the file.
2) Repeat (1) for the parent dir, it's parent, etc. up to the root of
the file system.
3) Create a temporary file, open it, and write the data.
4) Read some attributes on the temp file (only uid, gid, flags, fileid,
and fsid) and close it.
5) Delete the temp file.
6) Report that the file could not be saved (duh - you just deleted it!).
My best (only) guess is that it's unhappy with the attributes it sees -
but what I return in those attributes are the same values specified
during file creation time (except size, which is updated at write time).
Stepping through I've verified that the temp file is created in the same
directory as my cache file and the data is in fact written to it after
step 3. The attributes look right.
So writing a file from TextEdit fails. However - if the file size is
zero, the save succeeds (that is, if the new size is zero, regardless of
what the old size was). Instead of (4) and (5), it does what you'd
pretty much expect - delete the original file and rename the temp file
back into place.
I see similar behavior in other apps - only the command line stuff seems
to work correctly. I've been staring at this for several days, and I
can't seem to find where this could be going wrong.
There are probably a lot more details necessary to solve the problem,
but before I go any further, does anybody out there have some ideas?
What additional info do you need to proceed?
Thanks,
- Mike
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-kernel mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden