On Friday 10 February 2006 12:02, you wrote: > Jan Engelhardt <[email protected]> wrote: > > > > Right. The question was rather like this: > > Say we have our non-stable /dev/sr0 mapping to /dev/sg0, and it has got BTL > > 1,1,0. Now, if the user starts `cdrecord -dev=1,1,0`, > > `ls -l /proc/$(pidof -s cdrecord)/fd/` should show (and in fact did when I > > used ide-scsi back then) /dev/sg0, right? > > > > If so, what's wrong with just opening /dev/sg0 directly (as per user > > request, i.e. cdrecord -dev=/dev/sg0) and sending the scsi commands down > > the fd? > > As I did write _many_ times, this was done by the program "cdwrite" on Linux > in 1995 and as cdwrite did not check whether if actually got a CD writer, > cdwrite did destroy many hard disk drives just _because_ the /dev/sg* > is non-stable. > > People did not believe this and did write shell scripts with e.g. /dev/sg0 > inside and later suffered from the non-stable /dev/sg* <-> device relation. I am sure they used udev, back in 1995... -- Greetings Michael.
Attachment:
pgpLcFtT5qsz2.pgp
Description: PGP signature
- References:
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- From: Luke-Jr <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: Jan Engelhardt <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest)
- From: Joerg Schilling <[email protected]>
- Re: CD writing in future Linux (stirring up a hornets' nest) (was: Rationale for RLIMIT_MEMLOCK?)
- Prev by Date: Re: disabling libata
- Next by Date: Re: msync() behaviour broken for MS_ASYNC, revert patch?
- Previous by thread: Re: CD writing in future Linux (stirring up a hornets' nest)
- Next by thread: Re: CD writing in future Linux (stirring up a hornets' nest)
- Index(es):
 |