Date: Tue, 22 Feb 2011 11:31:12 -0500
From: Andrew Duane <aduane@juniper.net>
To: Garrett Cooper <gcooper@freebsd.org>, Alexander Best <arundel@freebsd.org>
Cc: "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject: RE: seeking into /dev/{null,zero}
Message-ID: <AC6674AB7BC78549BB231821ABF7A9AE970EA06474@EMBX01-WF.jnpr.net>
In-Reply-To: <AANLkTi=TCXhy9pvzKPsqtmX89JyB4CDnEuP2-jeF60_N@mail.gmail.com>
References: <20110222141112.GA98964@freebsd.org>, <AANLkTi=TCXhy9pvzKPsqtmX89JyB4CDnEuP2-jeF60_N@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I thought seeking past EOF was valid; writing something creates a file with=
a hole in it. I always assumed that was standard semantics.
As for /dev/zero and /dev/null, you could easily ask "who cares about the f=
ile position?" But I think some programs might want to seek around and chec=
k values, and those shouldn't change behaviour if someone uses /dev/null as=
a test file. It seems pretty trivial to update it, so why not make it beha=
ve the same.
--
Andrew Duane Juniper Networks
978-589-0551 10 Technology Park Dr
aduane@juniper.net Westford, MA 01886-3418
________________________________________
From: owner-freebsd-hackers@freebsd.org [owner-freebsd-hackers@freebsd.org]=
On Behalf Of Garrett Cooper [gcooper@freebsd.org]
Sent: Tuesday, February 22, 2011 11:22 AM
To: Alexander Best
Cc: freebsd-hackers@freebsd.org
Subject: Re: seeking into /dev/{null,zero}
On Tue, Feb 22, 2011 at 6:11 AM, Alexander Best <arundel@freebsd.org> wrote=
:
> hi there,
>
> there's a PR [1] regarding seeking into /dev/null and /dev/zero. i just w=
anted
> to ask what the overall opinion is on this matter. technically it's quite=
easy
> to seek into those files upon fwrite(3) and fread(3). the point is, if th=
e file
> position should be repositioned according the the amount of bytes read or
> written.
>
> the zero(4) and null(4) manual pages claim that both devices act as "ordi=
nary"
> files. right now only reading from /dev/zero will seek into the file. wri=
ting
> to /dev/zero and reading/writing to /dev/null will *not* adjust the file
> position.
lseek on CURRENT (and its assorted functions) is funky. Try this as an exam=
ple:
1. Create a zero character file.
2. lseek with SEEK_SET to byte 1.
2. will always return 1.
My Fedora Linux 13 VM on the other hand actually reports the error
when you try and seek outside the bounds of the file descriptor (this
makes more sense IMO because it accurately reflects reality). This is
an extension to the POSIX spec though as the spec doesn't say whether
or not seeking past the bounds of the descriptor is legal or illegal.
So what I'm trying to say is that the seek family functions in general
don't report helpful data except with success.
Found this when trying to write testcases for lseek(2) the night before las=
t.
I'll get back to you about the POSIXness of those /dev's in the most
recent spec once I get access back to the OpenGroup download section
-_-...
Thanks,
-Garrett
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AC6674AB7BC78549BB231821ABF7A9AE970EA06474>