Alan Cox <[email protected]> wrote:
> On Maw, 2005-03-08 at 17:25, Linux Kernel Mailing List wrote:
>> ChangeSet 1.2030, 2005/03/08 09:25:05-08:00, [email protected]
>> [PATCH] make st seekable again
>>
>> Apparently `tar' errors out if it cannot perform lseek() against a tape.
>> Work around that in-kernel.
>
> Unfortunately this isn't a good idea. Allowing tar to read the tape
> position makes sense, allowing it to zero the position might but you
> have to do major surgery on the driver first because
>
> 1. It doesn't use ppos
> 2. It doesn't do locking on the ppos at all
>
> Also allowing apps to randomly seek and report "ok" when they are
> backing up to tape and might really need to see the error is not what
> I'd call stable, professional or quality code.
Can the lseek be restricted to seek from 0 to 0 (or even * to 0 aka rewind)?
This would re-enable tar and probably other applications depending on this
API while not giving them false positives.
On Thu, Mar 10, 2005 at 01:43:57AM +0100, Bodo Eggert wrote:
> Can the lseek be restricted to seek from 0 to 0 (or even * to 0 aka rewind)?
> This would re-enable tar and probably other applications depending on this
> API while not giving them false positives.
This would be good only if we also agree to spit out warning messages every
time the trick is used, so that people know they are relying on a buggy
application. Just like tcpdump and AF_PACKET.
willy