site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi, Hi folks, HFS/HFS+ do not support sparse files. The main question is WHY are you trying to do what you are trying to do? Best regards, Anton -- Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @) Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK Linux NTFS maintainer, http://www.linux-ntfs.org/ _______________________________________________ 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 8 Dec 2007, at 09:33, Damir Dezeljin wrote: I have an non strictly kernel related question; however, I guess you'll be able to point me to the right resources. I developed a KEXT and I though of using sparse files functionality in user space for implementing some internal logic. I tried creating a sparse file using the same set of commands I usually use on Linux, but I found out I just create a normal file: ---- ftruncate(fd, 0); ftruncate(fd, 4*1024*1024*1024); ---- Now I'm wondering if sparse files are supported on the default file system used on OS 10.4 desktop (as I know, the HFS is used)? If yes, what I'm doing wrong? Additionally I'm wondering if is it possible to get some kind of 'holes table' as it's on Windows -> so, let suppose the sparse file has some data on an offset of 1 GB, some on 1.7 GB and so on. As far as I know, this isn't possible on Linux, but I'm sure it is on Windows. As there is no sparse support this is not relevant. You can get allocation information using the fcntl F_LOG2PHYS (see the fcntl man page) but that is quite a cumbersome interface. Also note that it will (at least on Leopard have not checked Tiger) return RANDOM JUNK for file systems supporting sparse files. Radar is down for maintenance at the moment or I would file a bug report immediately! Finally, even on HFS/HFS+ the information obtained is only a snapshot of this point in time. As soon as the call returns this information may not be accurate any more as HFS/HFS+ perform automatic online defragmentation and if that happens right after an fcntl F_LOG2PHYS call then the file will no longer be there at all. Is it possible to access above mentioned information from a KEXT? No you cannot do this from within a KEXT. (At least not in any supported way.) This email sent to site_archiver@lists.apple.com
participants (1)
-
Anton Altaparmakov