I am writing a kernel extention for Mac os, and i need to delete a tmp file created by
vnode_open(),but i can not find out how to delete a file and list all files in a dir.
http://developer.apple.com/library/mac/#documentation/Darwin/Reference/KernelIOKitFramework/vnode_h/index.html
Thanks!
It is better to create user-space daemon and to communicate with it using mach RPC.
The method of deletion of file in kext (that i'm aware of) depends on the version of kernel because it requires lookup of the offset of v_op (vnode operations vector. It is not visible from kernel extensions) within vnode structure. The vnode structure may change from kernel to kernel. And even if one finds vnop_remove_desc and vnop_rmdir_desc i think using it may be dangerous due to possible changes of the logic of using these callbacks.
Related
I have a library that has a file based interface (it only accept file names/paths).
Since the operations are time critical i would like to load the file to memory.
Is there a way to create create in-memory files that have a file path that is resolvable with the normal file access routines?
For example many programs still work if they get some win32 device path or an UNC path instead of a 'classic' windows path.
or maybe if that is not the case maybe a softlink can be used to map it into 'normal' filesystem.
One obvious way would be to use some ramdisk software but this would require further manual steps and also requires to tell the program the ramdisks letter.
I have a working OSX kernel extension which I would like to be automatically loaded at boot time as early as possible. The kext is using KAUTH for monitoring access on a specific path so it seems to me there won't be anything that will request it to be loaded into the kernel. In this case, copying it in /Library/Extensions (at least since Yosemite this is the recommended path for third-party extensions) won't solve my problem.
Is there a possibility to achieve this, whether or not by modifying the code or through some auxiliary configuration?
I already read about using a launchd daemon to use kextload in order to load the extension, as specified in this question, but in my case, I want it to be loaded as early as possible.
Update:
I am using a "generic" kernel extension (linked against BSD library) and not an I/O Kit based one.
I want my extension to be loaded before launchd is started.
You don't explicitly state it in the question, but I infer from the context that you're using a "generic" kernel extension (in contrast to an I/O kit based one)? These are only loaded either because another kext depends on them, or because they are explicitly loaded via kextutil/kextload or the KextManager API.
Contrast this to I/O Kit kexts, which are loaded on-demand when one of their personality dictionaries matches a registered service in the IO registry. This is usually for driving specific devices, but various non-hardware-dependent system services use the mechanism to match the 'IOResources' nub (documentation) which turns up during early boot so any kexts listing it as a provider for a personality also get loaded on boot.
So the solution would be to modify your kext to provide an IOService which matches the IOResources nub. The service itself doesn't really need to do anything if your userspace component already uses another interface to communicate with the kext.
If you don't want to change the kext's code itself, you could possibly create a dummy kext which does this, but declares your main kext as a dependency. This latter method isn't particularly elegant, but should work if for some reason modifying the existing kext is not possible. (Although you'll likely need to modify the info.plist)
If the kext is derived from IOKit and resides in /Library/Extensions clear the cache and it will be automatically loaded at boot. You clear the cache by calling
kextcache -f -update-volume /
The title pretty much says it, on Windows, can I somehow simulate multiple working directories in a multithreaded application by using something similar to openat?
See also this question.
Yes there is, and it's called NtCreateFile() (https://msdn.microsoft.com/en-us/library/bb432380(v=vs.85).aspx) :)
openat() takes an open fd to a base directory from which path operations start. Similarly, you can supply a HANDLE to the ObjectAttributes.RootDirectory of NtCreateFile() to have whatever that directory's path is to be used as a base for relative path operations.
If going direct to the NT kernel API is too much for you and you want to remain within Win32, you can retrieve the current path of the base directory HANDLE easily enough (see https://msdn.microsoft.com/en-us/library/windows/desktop/aa366789(v=vs.85).aspx). If you open the directory without FILE_SHARE_DELETE permissions, nobody will be able to rename it and therefore the path retrieved will never move so long as you keep the HANDLE open.
You then stitch together the retrieved path with the relative path using normal string concatenation.
The NT kernel API approach is the only solution on Windows which allows the base directory HANDLE to be arbitrarily renamed by third party processes and that not cause races in your code. i.e. it's the only equivalent to POSIX openat(). I agree it's very unfortunate that Win32 doesn't make available this facility - in fact, Win32 doesn't make available atomic renames which is a very useful POSIX facility indeed to let you avoid lock files and is something the NT kernel API provides too.
Is there any way to create a block device via user space in OSX (10.8+), without 3rd party libraries (FUSE, etc)?
I am trying to create a userspace tool. The idea is the user supplies a file to the tool and the tool creates a virtual interface. Whenever the interface is written to, the tool applies an operation to the data and then writes to the original file. Whenever the interface is read from, the tool reads from the original file and applies the inverse operation.
I don't necessarily need a block device. The tool needs to create some kind of virtual interface that can be treated as a file, i.e. it can be opened and saved to by another application.
I looked at the userspace routines of the I/O Kit, but nothing seemed aplicable, as creating a virtual USB/FireWire/MMC/SCSI device seems excessive.
The closest thing I can think of without going into kernel space is a fifo or named pipe - this is essentially a pipe with a file name. Unfortunately, being a pipe, you can't seek, etc. - you can just open the fifo for reading in one process and for writing in another. You create these either with the mkfifo command line utility or the mkfifo() C function.
There are also UNIX domain sockets, which are similar to IP sockets but again are identified by a file name, not a networking construct. These can be read and written from both ends, but again no seeking.
As for actually implementing the ops functions for a vnode (the in-kernel representation of a file in OSX) I believe you do have to drop to the kernel. Note that the I/O kit isn't strictly necessary for creating a block device - if the BSD device nodes are sufficient, and you don't need support for hardware or ejecting volumes etc. you can simply create a node with bdevsw_add(), supplying the ops vector as a parameter. (for an I/O Kit based storage device, the IOMediaBSDClient does this automatically, along with creating the character device with cdevsw_add_with_bdev()) Another, rather more elaborate option is to implement your own file system.
I have a big collection of folders for projects I'm working on. I've been trying to find a better way to sort them all for a long time and I want to write an app that creates groups based on whatever criteria I say, such as "folders from 2011" or "folders containing a x type of file" etc.
This is fairly straightforward, and wouldn't present much of a problem to code using its own UI in winForms or WPF or something. But I think it would be far better if I could make these folders appear to be part of the filesystem, so other apps (like existing file explorers) can see them.
Is this possible? Would it cause problems I haven't considered? How do I go about doing it if it is possible?
One way I thought of doing it would be to have the app monitor the filesystem and create folder shortcuts every time there's a change, but I'm curious about whether its possible to actually present a fake filesystem to explorer through a 'gateway' folder
EDIT: Ok it's obviously possible since http://www.virtualfolder.net/ can do it, and now that I think of it so can TrueCrypt, although it would be nice if it didn't have to appear as a separate drive. So the question becomes, how do I implement it?
You can create a Shell Namespace Extension that gathers the file information you want and displays it within Windows Explorer any way you wish. You can choose where your extension is located, whether as its own top-level node, a child of another system virtual folder/extension, or as a child of a file system folder.
Writing a SNE is not trivial, but it is a lot easier then writing a lower-level file system driver, and it does not require special driver-oriented compilers. Any compiler that supports developing COM objects will work.
This is accomplished using filesystem drivers or filesystem filter drivers. First let you create a virtual filesystem and mount it to a drive letter and also to a folder on NTFS drive (folder must exist but its contents are "replaced" with a virtual filesystem directory tree). Filesystem filter drivers let you introduce virtual files and folders in existing folders without replacing them.
VirtualFolder uses filesystem driver as it creates a drive letter.
Both types of drivers are written in C and work in kernel-mode. Writing them requires deep knowledge of Windows internals and experience with driver development (since filesystem drivers are one of the most complicated driver types).
We offer several products related to virtual storage. One of them, Callback File System, is a filesystem driver. It calls your user-mode code to perform actual filesystem functions. Another product, CallbackFilter, is an FS filter driver (and it also calls your user-mode code). However, current version of CallbackFilter doesn't let you introduce virtual files and folders (this would be implemented in the next release).
There's also Pismo File Mount product available, they use filter driver techniques. You can check with them if what you need can be accomplished.
From what I gather you are looking for a way to present the results of predefined file queries to appear as though they are located at a specific location in the file system. If that is correct you may want to look into Hard Links and Junctions. There are limits on what you can do with these file system services. However it is really straight forward to implement.