site_archiver@lists.apple.com Delivered-To: darwin-kernel@lists.apple.com Hi, Hi folks, Correct. UFS, ZFS, and others, however, 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 11 Dec 2007, at 00:00, Terry Lambert wrote: On Dec 8, 2007, at 1:51 AM, Anton Altaparmakov wrote: 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? HFS/HFS+ do not support sparse files. 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! Which FS are you talking about? For UFS, I see zero filled pages being returned, which is per the spec.. Are you sure this is not a bug specific to the FS you were testing on? The FS is more or less required to fake this up for any sparse areas, and if it doesn't, it's broken (not to mention a security issue, if it's returning random data from the disk). You misunderstood. Read the fcntl man page, the bit about F_LOG2PHYS. That returns a structure: struct log2phys { u_int32_t l2p_flags; /* unused so far */ off_t l2p_contigbytes; /* unused so far */ off_t l2p_devoffset; /* bytes into device */ }; And the l2p_devoffset contains random junk when F_LOG2PHYS is called for a sparse block. The bug is in the fcntl F_LOG2PHYS implementation in the kernel. If you want the gory details I described it in the Radar I filed: <rdar://problem/5637597>. This email sent to site_archiver@lists.apple.com