On Wed, 9 Mar 2005, Alan Cox wrote: > On Mer, 2005-03-09 at 21:58, Kai Makisara wrote: > > While waiting for the application to be fixed, it was decided to restore > > the old behaviour of the tape drivers. > > Which means tar won't get fixed 8(
Bet that's true. > > > I don't think implementing proper read-only lseek for tapes is worth the > > trouble (reliable tracking of the current location is tricky). Purist > > kernels can refuse lseeks. Pragmatic kernels can allow lseeks until > > refusing those won't break common applications. > > The problem is the existing behaviour code isn't just 'not useful' its > badly broken. No locking, no overflow checks, updates the wrong variable > etc. It is asking for nasty accidents with critical user data. In other words, it should work correctly or not at all. At the least this should be a config option, like UNSAFE_TAPE_POSITIONING or some such. And show the option if the build includes BROKEN features. That should put the decision where it belongs and clarify the possible failures. Caould you live with that, Alan? -- bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
