site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com I need to read and/or write from/to files in both fileop scope and vnode scope listeners. EINVAL ENOENT ENOSPC #define ENOSPC 28 /* No space left on device */ I don't want to hook the operations, I want to use them for read or write from/to files. -- Terry _______________________________________________ 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... On Oct 12, 2007, at 3:37 AM, Liviu Andron wrote: On 10/11/07, Jernej Azarija <Jernej.Azarija@hermes-softlab.com> wrote: 1) The recommended way from the technical documentation is to read/ write in kernel, but all the mailing lists discussions say to do it in user space. In userspace? It depends on what you need to accomplish. I'm actually unaware of any technical documentation from Apple that recommends reading or writing files from within the kernel. If you can point me at the documentation for this, I can grab the other members of the CoreOS kernel team, and we can go beat the author up. 8-). - for files with paths longer than MATXPAHTLEN (1024) , which can be created with Finder: - vn_getpath returns error 28 (KERN_INVALID_POLICY) - the callback for OPEN/CLOSE actions is called with empty path (arg1) or it's not called at all Use the supplied path as said. You'll only have to play about transfering the path to userspace. In the vnode listener you have no path. Please read all the message. KERN_INVALID_POLICY is a Mach error return code that generally only every gets seen when you attempt to select an unsupported scheduling policy for a mach task or mach thread. vn_getpath() on the other hand is a BSD function that only returns the result of a build_path(). Its possible return codes are: and the results of vnode_getattr() and of VFS_GET(). Since you are seeing 28, you are seeing: ...which means that the buffer you have supplied to contain the path information you are requesting is too small. Use a correctly sized buffer, and the problem will go away. Most likely,you are only reserving sufficient space for the terminal path component, rather than the entire path to the file. 4) Another possible solution seems to be using VNOP_READ/ VNOP_WRITE in kernel space and transfer data to daemon If you only need to hook open/close, use KAUTH_SCOPE_FILEOP. It's not reasonable to hook VNODE operations - at last from the performance view. This is strongly discouraged, if you are talking about reading or writing files from the kernel. This email sent to site_archiver@lists.apple.com