PDA

View Full Version : access another system's dvd or cd drive



mshanmuga
10-09-2005, 08:21 PM
I have another knoppix system which is connected to the lan and has a DVD RW drive. I want to run k3b from my system
but access the other system's DVD device. How do I do it?
Also similarly how to access another windows XP system's DVD/CD drive.
Thanks

Harry Kuhman
10-09-2005, 08:41 PM
I want to run k3b from my system but access the other system's DVD device. How do I do it?
Meaning that you want to write to the drive on the other system? You don't.

mshanmuga
10-10-2005, 03:21 AM
I want to run k3b from my system but access the other system's DVD device. How do I do it?
Meaning that you want to write to the drive on the other system? You don't.
I thought in linux one can share the devices like sharing the file system.

Harry Kuhman
10-10-2005, 05:27 AM
I thought in linux one can share the devices like sharing the file system.
Sharing files is a different matter than writing to a CD or DVD. Linux is, of course, open source, so if someone thought it was a really good idea to have someone on one computer be able to write to the write once media on another computer, it certainly would not be imposiable to write some sort of network aware burning tool with the existing programs as a starting point. But most people would find no need for such a tool and even find it dangerous for one computer to be able to write to another's CD drive. And, of course, you would need access at some pont to put the blank media in anyway. Of course, you certainly can transfer files from one system to another, and you could use remote access to access the computer with the burner and fire up a copy of burning software there. You likely could even use remote access to run the burning software and burn from source files that were not on the same system as the burner (although I would avoid doing that myself, no need to add network latency issues to CD burning issues). But for someone on one computer to be able to write to and potentially destroy previous information on a different system's CD burner is not a good design choice for most users.

Cuddles
10-17-2005, 02:38 PM
mshanmuga,

I tend to agree with Harry on this subject...

If I wanted to do what you are asking to be doing, my thinking would be, network over to the DVD RW system, place the files I want to burn on its local drives, from my system, then, fire off the burning software from the other system, locally, and burn the files I placed on that system, locally.

As Harry said, adding in network communication issues, not to mention the whole "different systems" stuff, can make for a very unreliable burn... What if System A is faster than System B, System B has the burner in it, or, System A is slower? In either case, the burner, and the burned media is going to suffer, possibly.

I have two Kanotix systems, both are networked together, one has a printer, the other "networks" over to it for its printer. I also have file sharing between the two systems; each system can copy, move, and delete files on the other system, through the network, as long as they are "priviledged" approved users to do so, and, they have the "rights" to do these things. I also have root users "common" on both systems, so a root on one system is a root of the other system, thus, root has, not only GOD priviledges on the "local" system, but, also on the networked system "remotely".

Your thinking of "sharing" is a valid one, but, devices that write, or, in this case, re-write, may not be a valid thing to do, through remote access... Consider the following, as an example: I am burning a audio CD on my system, the other system fires off a burn ALSO to my burning device, and begins to burn something else onto my already burning media... What do you think the consequences would be? This conclusion is already covered when you look at the whole setting up of "sharing" hard drives... Especially the /home areas. ( A file in use on the remote system could be deleted or changed "without" the local system being aware of it, and the conclusion they state, is dissaster. ) This also holds true with system files. As for "global" files, like your letter to your mom, this isnt that bad an issue, but, something that the system relies on, or a user needs for there running of there own account, then, this could be a problem.

"File" sharing is one thing, but, system "resource" sharing, or "device" sharing, is something completely different. I dont even think Windows has gotten to the point where two people, or systems, can share a DVD at the same time, only one can access, and use, a device at one time. Printers, are a different story, they use a "spool queue" to allow more than one "user" to print. The spool queue manages who is using the printer, from where, and when the print job completes, the queue moves on to the next job, for another print, either from the same user, or a completely different one. For your "theory" of burning to work, you would need something like a "burning queue", something that watches over, schedules, and runs jobs to a specific burning device... and, again, as Harry said, you would still need someone "locally" to change the media for each of these jobs.

Not sure if this has helped,
Ms. Cuddles

Markus
10-17-2005, 05:01 PM
Have also a look at "man cdrecord". A snippet:

To access remote SCSI devices, you need to prepend the SCSI device name
by a remote device indicator. The remote device indicator is either
REMOTE:user@host: or REMOTE:host:
A valid remote SCSI device name may be: REMOTE:user@host: to allow
remote SCSI bus scanning or REMOTE:user@host:1,0,0 to access the SCSI
device at host connected to SCSI bus # 1,target 0 lun 0

ckamin
10-18-2005, 08:56 AM
Have also a look at "man cdrecord". A snippet:
What a great reminder Markus! Where there is a will, there is a man file to show the way.

I can hear all those "coasters" being put into production as I write this. That's entirely OK, since I have found some new uses for them, courtesy of this forum. Send me a note when you get a good stack and I'll give you an address to send them to. :wink: