Generally if you need to read/write to files from a KEXT in mass, you use the IOKit messages or sockets or sysctl depending on what you're doing to a user daemon to do file IO. Probably not suitable in this instance; i'm sitting a little too low-level to try this. As a basic background to where i'm coming from- I've converted Apple's HFS+ code to compile with C++ and made the necessary modifications to run as a KEXT; now i'm trying to create some additional "system" files. I'm baffled why you converted this to C++, file systems are not IOKit objects, and are generally C only entities. KEXTs support C++. I like C++. In this particular case, the one thing which caused me to convert it to C++ is the ability to then namespace the whole KEXT. Having namespace conflicts between Apple's in-kernel HFS+ and my kext built from [originally] the same source was Not Fun. That's fixed now. You could do this in straight C with a bit of work, however i'm mainly playing and learning and this technique suited me. Apple's existing system files (extents tree, etc) are treated rather specially by the filesystem and I don't want to go down the same path- instead I would like to open a file in much the same way as a userland process would (except using the vfs directly since i'm in a KEXT.) This is generally considered a bad thing to do. The locking issues are complex in a file system and you can easily bypass a lot of the locking rules by accessing these functions out of context. Its incredably easy to leave a vnode locked somewhere and not have the system panic till much later on. Yes, i realise. That's pretty much what i'm looking for information on. What are you trying to accomplish anyways? If you really are trying to add another file to the "special" area of HFS+ in CNID's 2 though 15 then I'd imagine you'd probably have to make your own HFS+ file system and build that into a new kernel, or try to make it a loadable file system and put it at a higher priority for HFS in the filesystem bundles. Either way this can get quite annoying pretty quickly. I've got my own HFS+ file system, it's a runtime loaded kext, it works. I'm now trying to make some modifications. I require additional storage space for extra data that the modifications will require. This storage space is equivalent to the extents-tree and other system files. I could take the exact same approach that apple does for the extents tree, journalling files, etc, however I don't see any way of doing that without breaking compatability with the on-disk HFS format. There appears to be a preset number of system files which have their extents stored in the master blocks. I didn't see any [compatible] way of extending that, therefore i'm trying to open a "normal" file after the end of the normal HFS+ mount sequence. If there is some 'hfs-compatible' technique for extending the number of actual system files (the ones with their extents stored in the master block) then please let me know and i'll go do that and save myself the hassle.. thx, chris _______________________________________________ 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.