On Fri, 18 Feb 2005 15:23:44 EST, Bill Davidsen said:
I'll try to build a truth table for this, I'm now working with some non-iso data sets, so I'm a bit more interested. I would expect read() to only try to read one sector, so I'll just do a quick and dirty to get the size from the command line, seek and read.
I haven't had a problem using dd to date, as long as I know how long the data set was, but I'll try to have results tonight.
The problem is that often you don't know exactly how long the data set is (think "backup burned to CD/RW") - there's a *lot* of code that does stuff like
while (actual=read(fd,buffer,65536) > 0) { ... }
with the realistic expectation that the last read might return less than 64k, in which case 'actual' will tell us how much was read. Instead, we just get an error on the read.
Note that 'dd' does this - that's why you get messages like '12343+1 blocks read'. We *really* want to get to a point where 'dd' will work *without* having to tell it a 'bs=' and 'count=' to get the size right....
I think I already had a pretty good grasp on that, in my previous post on this I noted: "The last time I looked at this, the issue was that the user software did a large read and the ide-cd didn't properly return a small data block with no error, but rather returned an error with no data. If you get the size of the ISO image, you can read that with any program which doesn't try to read MORE than that."
It sounds as if (a) the problem with ide-cd is going to get fixed, and (b) ide-scsi may not remain depreciated. A win-win if I ever saw one.
-- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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/
