seeking into /dev/{null,zero}

Andrew Duane aduane at juniper.net
Tue Feb 22 16:35:46 UTC 2011


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 file position?" But I think some programs might want to seek around and check 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 behave the same.

--
Andrew Duane             Juniper Networks
978-589-0551              10 Technology Park Dr
aduane at juniper.net      Westford, MA  01886-3418

________________________________________
From: owner-freebsd-hackers at freebsd.org [owner-freebsd-hackers at freebsd.org] On Behalf Of Garrett Cooper [gcooper at freebsd.org]
Sent: Tuesday, February 22, 2011 11:22 AM
To: Alexander Best
Cc: freebsd-hackers at freebsd.org
Subject: Re: seeking into /dev/{null,zero}

On Tue, Feb 22, 2011 at 6:11 AM, Alexander Best <arundel at freebsd.org> wrote:
> hi there,
>
> there's a PR [1] regarding seeking into /dev/null and /dev/zero. i just wanted
> 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 the 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 "ordinary"
> files. right now only reading from /dev/zero will seek into the file. writing
> 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 example:

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 last.

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 at freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"


More information about the freebsd-hackers mailing list