Return-Path: <tiff-bounces@lists.maptools.org>
Delivered-To: info@awaresystems.be
Received: (qmail 16822 invoked from network); 23 Aug 2008 15:13:24 -0000
Received: from janet.telenet-ops.be ([195.130.136.6])
          (envelope-sender <tiff-bounces@lists.maptools.org>)
          by angelia.telenet-ops.be (qmail-ldap-1.03) with SMTP
          for <info@awaresystems.be>; 23 Aug 2008 15:13:24 -0000
Received: from zimbu.telenet-ops.be (zimbu.telenet-ops.be [195.130.136.11])
	by janet.telenet-ops.be (8.13.1/8.13.1) with ESMTP id m7NFDOSU030268
	for <info@awaresystems.be>; Sat, 23 Aug 2008 17:13:24 +0200
Received: from localhost (localhost.localdomain [127.0.0.1])
	by zimbu.telenet-ops.be (Postfix) with SMTP id 538B540003
	for <info@awaresystems.be>; Sat, 23 Aug 2008 17:13:24 +0200 (CEST)
Received: from crotus.telenet-ops.be (crotus.telenet-ops.be [195.130.132.38])
	by zimbu.telenet-ops.be (Postfix) with ESMTP id 445E640002
	for <info@awaresystems.be>; Sat, 23 Aug 2008 17:13:24 +0200 (CEST)
Received: from duke.maptools.org (r153.dmsolutions.ca [209.217.116.153])
	by crotus.telenet-ops.be (Postfix) with ESMTP id C6303D
	for <info@awaresystems.be>; Sat, 23 Aug 2008 17:13:23 +0200 (CEST)
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id m7NF8ak6023390;
	Sat, 23 Aug 2008 11:11:02 -0400
Received: from abra2.bitwizard.nl (dtp.xs4all.nl [80.101.171.8])
	by duke.maptools.org (8.12.11/8.12.10) with SMTP id m7NF8WmM023387
	for <tiff@lists.maptools.org>; Sat, 23 Aug 2008 11:08:33 -0400
Received: (qmail 17438 invoked by uid 1000); 23 Aug 2008 17:08:31 +0200
Date: Sat, 23 Aug 2008 17:08:31 +0200
From: Rogier Wolff <R.E.Wolff@bitwizard.nl>
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
Subject: Re: [Tiff] creating sparse files......
Message-ID: <20080823150831.GE18815@bitwizard.nl>
References: <20080822085634.GA21294@bitwizard.nl>
	<Pine.SOC.4.64.0808220936280.1110@freddy.simplesystems.org>
	<20080822162748.GB29030@bitwizard.nl>
	<Pine.SOC.4.64.0808221131320.1110@freddy.simplesystems.org>
	<20080822165232.GE29030@bitwizard.nl>
	<Pine.SOC.4.64.0808221249090.1110@freddy.simplesystems.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.SOC.4.64.0808221249090.1110@freddy.simplesystems.org>
Organization: BitWizard.nl
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: tiff@lists.maptools.org, Rogier Wolff <R.E.Wolff@bitwizard.nl>
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-SpamCatcher-Score: 50 [XX]

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
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
