Date: Wed, 23 Feb 2011 23:36:12 +0000
From: Alexander Best <arundel@freebsd.org>
To: Garrett Cooper <yanegomi@gmail.com>
Cc: freebsd-hackers@freebsd.org, John Baldwin <jhb@FreeBSD.org>, Garrett Cooper <gcooper@freebsd.org>
Subject: Re: seeking into /dev/{null,zero}
Message-ID: <20110223233612.GA46124@freebsd.org>
In-Reply-To: <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com>
References: <20110222141112.GA98964@freebsd.org> <AC6674AB7BC78549BB231821ABF7A9AE970EA06474@EMBX01-WF.jnpr.net> <AANLkTimwOVub6XxZqgCmHPnLbekJrEbYQBzxUr%2BUrcR5@mail.gmail.com> <201102221251.33717.jhb@freebsd.org> <3A287E45-A369-4C7A-BA8E-A205679AC0BC@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <aduane@juniper.net> wrote:
> >>> I thought seeking past EOF was valid; writing something creates a file
> > with a hole in it. I always assumed that was standard semantics.
> >>
> >> That'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)). SEEK_HOLE and SEEK_DATA are different,
> > they are just used to discover sparse regions within a file.
> >
> > From the manpage:
> >
> > The lseek() system call allows the file offset to be set beyond the end
> > of the existing end-of-file of the file. If data is later written at
> > this point, subsequent reads of the data in the gap return bytes of zeros
> > (until data is actually written into the gap).
>
> You're correct. Linux (Fedora 13) isn't POSIX compliant (this 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 point, subsequent reads of data in the gap shall return bytes with the value 0 until data is actually written into the gap.
so except for reading from /dev/zero freebsd also isn't posix compliant, right?
will this patch fix writing to /dev/{zero,null}?
diff --git a/sys/dev/null/null.c b/sys/dev/null/null.c
index 3005c19..aa9fa87 100644
--- a/sys/dev/null/null.c
+++ b/sys/dev/null/null.c
@@ -71,6 +71,7 @@ static void *zbuf;
static int
null_write(struct cdev *dev __unused, struct uio *uio, int flags __unused)
{
+ uio->uio_offset += uio->uio_resid;
uio->uio_resid = 0;
return (0);
cheers.
alex
>
> Thanks!
> -Garrett
--
a13x
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110223233612.GA46124>