On 12/05/2016 01:37 PM, Andy Paterson wrote:
On Monday 05 Dec 2016 12:27:37 Samuel Sieb wrote:
On 12/05/2016 12:14 PM, Andy Paterson wrote:
Its tiresome reading this kind of "gui mindness"
Who is talking about a gui? Everyone in this thread has been talking
about command line tools. There have been mentions of the gui tools and
those are certainly the best method if you're running a graphical desktop.
Device drivers have a limited number of entry points open, close, read,
write & ioctl.
Without knowing anything about the internals of the cd drivers I can
confidentally assume that all cdrecord does is use a few driver specific
ioctls to put the driver (& device) into an appropriate mode then issues
write(2) system calls - which is pretty much all dd will do.
So if the device is in the correct mode dd will do fine.
Assuming you are correct, then what are you going to use to make sure
that the driver and device are in the correct state before you use dd?
Since you already have to run something else before dd, then why not
just run that something else that can do the entire write in one step?
Also, I'm sure that dd is not going to run the finalizing step on the CD.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Exactly! I think original posters problem is that when he previously got dd to
"work" its because the device was in the right mode in the first place!
So its not dd that isn't working any more it's that he isn't finding the
device in the right state any more.
Sorry to have to say this, but "right mod" "not right mode" is BULL.
As long as the media is blank and in undamaged condition, then
the media is in the "right mode" for writing to it. PERIOD.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
