From owner-freebsd-hackers@FreeBSD.ORG Thu Feb 24 00:16:36 2011 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8628D1065674; Thu, 24 Feb 2011 00:16:36 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id BE8718FC12; Thu, 24 Feb 2011 00:16:35 +0000 (UTC) Received: by wwb31 with SMTP id 31so20988wwb.31 for ; Wed, 23 Feb 2011 16:16:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YhoVMDsMIWvpNjIg4wiml5vuoYdskUDPOt+gUve9I3U=; b=Ou8KPz1bOUgkCGk5jLn9PdTmbVbCtSK7V2L6WpA6PgjdcCX3IT28qnNKCBqEfnWgKi fuMegLsNrquLXgK1U8YaX29+e7QuAou7gZfk3LI0yykOU0zX7fDGZSkxp+l33d6uWrq9 9s+AMmlpTIOP3JYe8IMY4hNC5s+b7ar9/CcZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=bq5lIEeG90fKpERuaWFpjqCr3Z3x8BH67t86Z09B8de04AdLHElmI5wvnb/XvMi99i oNIi5BsSD3uXjg6IWaWegM1iIoSld0VSDpvjQYy8EWwmW263+LRliXFFG48CfOlx8jbM MVxRuKve6HxhnYMK/VzXEKcisqh1sXuyyTSCQ= MIME-Version: 1.0 Received: by 10.216.1.145 with SMTP id 17mr117010wed.50.1298506442371; Wed, 23 Feb 2011 16:14:02 -0800 (PST) Received: by 10.216.15.74 with HTTP; Wed, 23 Feb 2011 16:14:02 -0800 (PST) In-Reply-To: <20110223235355.GA48790@freebsd.org> References: <20110222141112.GA98964@freebsd.org> <201102221251.33717.jhb@freebsd.org> <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com> <20110223235355.GA48790@freebsd.org> Date: Wed, 23 Feb 2011 16:14:02 -0800 Message-ID: From: Garrett Cooper To: Alexander Best Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org Subject: Re: seeking into /dev/{null,zero} X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2011 00:16:36 -0000 On Wed, Feb 23, 2011 at 3:53 PM, Alexander Best wrote= : > On Wed Feb 23 11, Garrett Cooper wrote: >> On Feb 22, 2011, at 9:51 AM, John Baldwin wrote: >> >> > On Tuesday, February 22, 2011 11:46:05 am Garrett Cooper wrote: >> >> (Please bottom post) >> >> >> >> On Tue, Feb 22, 2011 at 8:31 AM, Andrew Duane wr= ote: >> >>> I thought seeking past EOF was valid; writing something creates a fi= le >> > with a hole in it. I always assumed that was standard semantics. >> >> >> >> =A0 =A0That's with SET_HOLE/SET_DATA though, correct? If so, outside = of >> >> that functionality I would assume relatively standard POSIX semantics= . >> > >> > Err, no, you can always seek past EOF and then call write(2) to extend= a file >> > (it does an implicit ftruncate(2)). =A0SEEK_HOLE and SEEK_DATA are dif= ferent, >> > they are just used to discover sparse regions within a file. > > on the other hand POSIX says: > > "The behavior of lseek() on devices which are incapable of seeking is imp= lementation-defined. > The value of the file offset associated with such a device is undefined." > > ...if we define /dev/{zero,null} as incapable of seeking the current > implementation should be ok. > >> > >> > From the manpage: >> > >> > =A0 =A0 The lseek() system call allows the file offset to be set beyon= d the end >> > =A0 =A0 of the existing end-of-file of the file. =A0If data is later w= ritten at >> > =A0 =A0 this point, subsequent reads of the data in the gap return byt= es of zeros >> > =A0 =A0 (until data is actually written into the gap). >> >> =A0 =A0 =A0 You're correct. Linux (Fedora 13) isn't POSIX compliant (thi= s is from the official POSIX text): >> >> The lseek ( ) function shall allow the file offset to be set beyond the = end of the existing data in the file. If data is later written at this poin= t, subsequent reads of data in the gap shall return bytes with the value 0 = until data is actually written into the gap. Yes, but look at how it's defined by POSIX before you do that (yes, there's a section for null/zero IIRC). Thanks, -Garrett