There's a lot of layers there, a lot of them being abstraction layers so that different cd-rw will have the same interface. It's also kind of interesting to see this kind of abstraction in C instead of C++, basically instead of using a class with overloaded member functions, you use a struct that contains pointers to all of the functions. And then you just make calls on the pointers. From what I can see, it's the same thing, only you have to do everything explicitly. But this is besides the point.
By assuming I was using a scsi compatible drive (which I'm pretty sure almost everything is.)
I found the command:
scsi_load_unload(scgp, load)
in cdrecord/scsi_cdr.c
Basically, this function sets up the scsi command, and then calls scg_cmd(), which I'm guessing is the generic libscg command for sending a SCSI command on the bus. If I understand it correctly, libscg is an attempt at abstracting the scsi bus.
Anyway, there is some conflicts as far as what exact command is sent (some of it depends on what the drive is).
But as far as I can tell, nowhere in cdrecord does he actually attempt to establish if the drive is open or closed. He just gives it a load command at the beginning before doing anything. So maybe I need to look into the SCSI specification or something. I'm pretty much at a loss here.
I could keep track of this stuff myself, but what happens when someone comes along and hits the eject button. It's not very helpful if I keep all the drives locked so that someone can't do that.
Right now my work-around is a configurable parameter that says "eject/don't eject after finishing." Worst case I just tell the people which drive there stuff is in, and I expect them to open the drive. It's not as nice as leaving the drive open waiting for them, but I really don't want to open/close the drives all the time.
Does anyone know if there is a nice SCSI command instead of "load/unload" for SCSI sense loaded?
I'm not even sure load/unload is what I really want. But it's probably the closest.
I haven't really tracked anything into the scg library. Because things seem to get _really_ ugly in there. Not that the code is terrible, but scg_cmd is a generic command function, and I think it's more knowing what commands are in SCSI rather than anything I can get from the code.
So in essense, no luck yet.
I might try the code for mount/eject.
That's the next thing to look in I guess.
My current set of commands is:
1. ps -ef | grep cdrecord | grep dev | sed -e "s/.*dev=\([^ ]*\).*/\1/"
This returns a list of the devices in all cdrecord processes. It's just a first check to see if cdrecord is writing to any drives, because I'll definitely not want to touch them. [In my experience cdrecord doesn't like you to do too much while it's writing, or it will fail]
2. mount
This returns a list of all the currently mounted drives. If someone has mounted a drive, I already know the drive is unavailable for burning.
3. cdrecord -atip dev=%s
Get cdrecord to return if there is media in the drive. One interesting thing: if you have cdrecord burning a cd, don't try to query a drive. It doesn't like it a lot (see point 1). It will happily give you the information, while killing the other process (at least most of the time.)
4. mount -r -t iso9660 /dev/%s tmp
Mount the drive in a temporary location. This command requires that I run the program as root, but I pretty much need to run it that way for some other stuff I want to do. So not a big deal.
This can return a few things,
'already mounted' - (but I should have checked for that already),
'special device' - the device specified doesn't exist,
'no medium' - there's nothing in the drive [but cdrecord should have given us that],
nothing - this means that it mounted, so I can't use the disk,
'wrong fs type' - this is the one I look for because it says there is a disk, but at least it's not an iso9660, someone could have burned an ext or vfat on there, but I doubt it.
Any suggestions/additions/comments?
One last thing that I thought of... Automount. Somehow it knows when you put in a cd. Worst case, I just create my own 'automount' program that just monitors the status of the drives. And then my program queries it to see what's up. [Of course, for now, I'm just not going to eject the drives :)].
John
=:->
Miguel Figueiredo wrote:
Tell the list if you find anything more interesting than the eject circus ;)
On Wednesday 11 December 2002 19:28, you wrote:
While I think you're right, this should work. It might look kind of
funny when there are a bunch of
finished jobs. Imaging all 4 drives have media that has been used.
Then every minute each drive will reload and then eject again after
some time.
But you're right, it should work. Even if it looks funny. :)
Might be a little bit of stress on the drive tray loading mechanism.
But you're right, it's a good start. I don't think these will get used
all that much that it will matter, and I can decrease the update time to
once every 5 minutes, which shouldn't hurt too badly.
Actually, I just thought of something. If you try to mount a drive with
nothing in it, it gives the error "No medium found", while if you have
blank media it gives: "I could not determine the filesystem type..."
Now I just have to figure out if there is a way to check that the cd is
ejected. Maybe eject will help.
I haven't found anything yet, but it might have promise.
John
=:->
Miguel Figueiredo wrote:
Try like this:
First check media. If it does not have media eject cd.
If it as media, try to mount the fs. If the fs has data, eject cd.
If the media has no data, burn.
Maybe it will work for your purposes,
Miguel
On Wednesday 11 December 2002 19:02, you wrote:
Thanks for the reply. That helps quite a bit.
Do you know how to tell cdrecord not to reload the media (if the cd tray
is open)? Because it would be nice for my purposes to eject the cd so
that it's obvious that something is done, but then still be able to
query everything to see if there is an available drive.
There might not be a flag for this (unfortunately). And I really would
prefer not having to customize cdrecord for my project.
Thanks,
John
=:->
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
