Am 19.02.2010, 06:03 Uhr, schrieb Tim Kientzle <kient...@freebsd.org>:
Joerg Sonnenberger wrote:
On Thu, Feb 18, 2010 at 07:34:59PM +0100, Juergen Lock wrote:
Ok here is a new version of the patch with these things fixed and the
Linux case added: (Linux case not tested yet, and yes I did this on
stable/8.)
Why the check at all? Shouldn't devices that don't allow seek fail
that?
E.g. for devices, just try to seek ahead and fallback to normal reading?
That was the initial implementation in libarchive, but
I had a number of reports of that not working for
tape drives. I recently dug out and connected an
old DDS drive I had in the closet, so I should
probably try again and see if I misunderstood
something along the way.
I'd already written this in a private email to Tim before I came across
this continued discussion on -hackers@, I'll paste a modified version of
my own part:
I strongly believe that someone should really fix lseek() in FreeBSD
outside GEOM. There is precedence, namely
<http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/60313> and it was never
properly fixed. The PR was closed because the actual reported problem on
da(4) no longer occurred since FreeBSD 5 after the GEOM migration, and my
issue was with da(4) on FreeBSD 4.
Now I'm learning that the very same bug persists through -CURRENT nearly a
decade later: after lseek devices such as sa(4) will return "garbage" (i.
e. from the unchanged offset) rather than failing.
It should be sorted out before 8.1.
Am I naive if I expect lseek to return (off_t)-1 with errno == ESPIPE on
non-seekable devices?
I'll concede that sa(4) is neither socket nor pipe nor fifo in the
strict sense, but all share the non-seekability.
If lseek() can't know the device isn't seekable, subsequent I/O operations
should return EIO along with a proper kernel log message for the first
occasion per process, but that would not help applications or libarchive
for that matter - they will need a canonical way to find out if a device
is seekable. Unfortunately FreeBSD maps many physical block devices that
are unbuffered to character special device nodes, so the obvious way of
calling [f]stat() and then checking S_ISBLK(st.st_mode) will return FALSE
even for devices that can seek.
--
Matthias Andree
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
