Jump to content

Terrible RDX Performance


Recommended Posts

Not really, the driver can eject the cartridge just fine when the window is closed. There is also no awkward caching going on. They have set that up correctly.

 

My hunch is HP (or whoever wrote it) dropped the ball with their driver... But I can't really prove that. It's just weird behaviour. Maybe it's by design, in which case it's a really bad design. If one ejects a cartridge one should expect it to eject. If it can't eject it should provide a system message with a reason why it can't comply.

Link to comment
Share on other sites

Respectfully, it sounds like you haven't written tape/disk drivers. When you are at that low of a level, you really can't throw up an error message. Best that the driver can do is to check whether the filesystem is busy/mounted before unlocking the door for the eject. That's why door locks were put there for tape/disk/floppy cartridges - to prevent unexpected manual ejection.

Link to comment
Share on other sites

That's all correct what you say, but it seems very odd the system can't eject a cartridge where the only thing that happened is to open it in Windows Explorer.

 

There is nothing written to the cartridge at all, it even happens when it is write protected (it has a tab for that, just like a tape). There is only one dependency and that's the open window of the OS itself. That shouldn't cause a busy/locked state.

 

Btw, my colleague says If you use Windows' eject function, while the window is open, it does produce a system message, claiming it can't eject the media as it appears to be in use (having a window showing its contents is considered 'in use'). So if this is the case, the RDX driver should generate the same message.

 

Frankly, this is the first hard disk system I've used with an eject button, running Windows. This might be something that Windows just needs to do. I wonder if OSX would handle this the same. Can't check that now. But I recall Apple Classic OS having no trouble ejecting Syquest, MO's and Jaz cartridges when ejecting them from the OS.

 

How it works now feels counter intuitive, but I can live with it. However there still remains the problem of Retrospect ejecting the cartridge. If you don't know this is the way RDX behaves you'll find it strange.

 

Indeed I haven't written a driver in my live (and never will) but that doesn't mean a system shouldn't work intuitive. Nor should the system dictate the function. That, in my book, is just bad industrial design. But you are right, maybe I shouldn't have addressed the driver's programmer but Microsoft itself for bad architecture where they forgot the needs of the regular user and his/hers human shortcomings.

 

On the other hand, without them, we might still have got refrigerator size $100.000 computers with IBM embossed on the front. But yeah, I guess complaining is something we humans are good at. ;)

Link to comment
Share on other sites

The problem is twofold:

 

(1) down in the bowels of the operating system (any operating system, whether Windows, unix, etc.), the driver has no handle to a window into which to put an error message.

 

(2) even if it could put up an error message, the driver has no clue as to what user or window or program should receive that error message. All it knows is that the eject button was pressed, and the OS tells the driver that the device is in use and can't be ejected.

 

The best that a driver can do is to log an error in an error log, just like it would for a read or write error. The difference with a read or write error is that a program is waiting on the read or write syscall to return with status. That's not the case with an unexpected press of an eject button - there's no program / user, waiting on results, to inform about the eject attempt.

 

Russ

Link to comment
Share on other sites

I'm not totally convinced.

 

Try the same with a CD and the drive will eject the media just fine.

 

Maybe the difference is the CD/DVD drive features a hardware eject function and this isn't implemented in the driver as opposed to having a software eject function. Drawback will be the OS doesn't know the media is ejected.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...