site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Thread-index: AcbWCQ7yIQuJPmVgTJexA8FkeveCCQ== 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 (Darwin-kernel@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-kernel/site_archiver%40lists.a... This email sent to site_archiver@lists.apple.com