2008.08.19 05:17 "[Tiff] Regarding DICONDE and its Specification", by Harsha

2008.08.23 15:08 "Re: [Tiff] creating sparse files......", by Rogier Wolff

On Fri, Aug 22, 2008 at 01:11:22PM -0500, Bob Friesenhahn wrote:

While libtiff is a pretty boring open source project, libtiff itself is one of the top three image format libraries in the world (the other two are libjpeg and libpng) so any included enhancement for holey files should be very well proven on many types of systems (even Microsoft Windows), or be a compile time option.

Not all Unix systems seem to support creating holes.

Wrong. All Unix systems support the POSIX api that i'm using. It's then up to the operating system to actually write stuff to the disk in a way that it can get back again. Unix will in fact (on it's native filesystem) usually create holes.

For example, Apple OS-X's HFS+ does not support holes.

Weird. So, will my suggested code fail? No.

Windows FAT type filesystems (still very much in use in millions of systems/devices) do not support holes.

Correct. But will my code fail? No. It does skip the copying of "zeroes" from userspace into the kernel. Wether this will in fact increase or decrease perfomance when all things are added up, I don't know.

It is unlikely that the ISO9660 filesystem (used on CDs) supports holes.

Correct. Iso9660 does not support holes. Files are contiguous (i.e. not fragmented) due to the design of the filesystem.

It is likely that some popular filesystems will fail to seek past the end of the file or will return random bytes (or parts of some previously deleted file) for the uninitialized portions.

It is likely that you don't know that the posix specifications are pretty clear about this.

If I program

        main (int argc, char **argv)
        {
                int a;
                int b;
                a = 3;
                b = 5;
                printf ("%d\n", a+b);
        }

the output should be "8". This is because I used standard features of a standard programming language. Opening and writing files goes a bit further. But the functions I used (and the results it is supposed to generate) are very much standardised, just like the results of the program above.

        Roger.

--

** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**    Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233    **

*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ