Messages in this thread | | | From | "H. Peter Anvin" <> | Subject | Re: lseek() on an iso9660 file | Date | 7 Jan 2002 09:48:35 -0800 |
| |
Followup to: <Pine.LNX.3.95.1020107091316.18091A-100000@chaos.analogic.com> By author: "Richard B. Johnson" <root@chaos.analogic.com> In newsgroup: linux.dev.kernel > > Using Linux 2.4.1 I discovered a problem with lseek on CDROM files > (iso9660). I just installed 2.4.17 and found the same problem. > > The problem: > > (1) A portion of the file, existing on a CDROM, is read and its the > contents are written to an output file on writable media. > > (2) The current input file-position is obtained using > pos = lseek(fd, 0, SEEK_CUR); The value returned is exactly > the expected value. > > (3) The rest of the CDROM file is read and written to the output file. > > (4) The file-position of the CDROM file is then set back to the saved > position using lseek(fd, pos, SEEK_SET); The value returned is > exactly the expected value. > > (5) The CDROM file is then read and its contents are observed to be > scrambled in some strange manner in which word-length groups of > bytes from near the end of the file are interleaved with the > correct bytes. Basically, the file ends up being about twice > as long as the original, with every-other two-byte interval > being filled with bytes from near the end of the file. >
a) How long is the file? b) What is the offset? c) What particular iso9660 options (RockRidge, Joliet, zisofs...) does your disk use? d) Mount options?
This seems to be a rather serious bug, so I'd like to get to the bottom with it.
-hpa
-- <hpa@transmeta.com> at work, <hpa@zytor.com> in private! "Unix gives you enough rope to shoot yourself in the foot." http://www.zytor.com/~hpa/puzzle.txt <amsp@zytor.com> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |