From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Halcrow Subject: Re: [PATCH] eCryptfs: Delay writing 0's after llseek until write Date: Tue, 22 May 2007 09:51:25 -0500 Message-ID: <20070522145124.GA3616@us.ibm.com> References: <20070521230021.GD3621@us.ibm.com> <20070521210708.67d365dc.akpm@linux-foundation.org> Reply-To: Michael Halcrow Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: LKML , linux-fsdevel@vger.kernel.org To: Andrew Morton Return-path: Received: from e35.co.us.ibm.com ([32.97.110.153]:49906 "EHLO e35.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759449AbXEVOvy (ORCPT ); Tue, 22 May 2007 10:51:54 -0400 Content-Disposition: inline In-Reply-To: <20070521210708.67d365dc.akpm@linux-foundation.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, May 21, 2007 at 09:07:08PM -0700, Andrew Morton wrote: > On Mon, 21 May 2007 18:00:21 -0500 Michael Halcrow wrote: > > > Delay writing 0's out in eCryptfs after a seek past the end of the > > file until data is actually written. > > a) why? http://www.opengroup.org/onlinepubs/009695399/functions/lseek.html ``The lseek() function shall not, by itself, extend the size of a file.'' > b) what is the impact upon a user of them not having this patch? Applications that lseek() past the end of the file without writing will experience unexpected behavior. Mike