LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
August 2008
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2008.08.23 15:08 "Re: 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