Jerry W Barrington wrote:

smh wrote:

======================================
Mike Richter, were you born with
"Scam Artist" emblazoned on your face?
======================================

http://groups.google.com/groups?selm...mindspring.com
(Messages 10, 12 -- 34, 54 -- 69)

a lot of rant snipped

Is this only a rant, not libel?

===========================================
Mike Richter is a LIAR (directcd/eject)(ii)
===========================================

=================================
From: (Videoman)
Subject: What is Responsible for Packet Writing Instability?
Date: 6/28/01

Mike Richter (Lying Scum) wrote:

There is an inherent problem in UDF, particularly with fixed-length
packets, which is the source of most of the problems reported. It is
that the directory information for the disc is held and modified in
RAM between loading the disc and ejecting it. Anything which precludes
a complete, valid package being written back risks the whole disc.

In other words, lack of true transactional semantics during the
crucial data transfer and filesystem update to the disc, creates the
highly non-zero possibility of severe data loss. It's not a question
of if, only a question of when. The more you use it, the worse your
odds become.

Because the information must be read and organized at insertion,
loading a complex disc is slow. Reading and writing are slow and
complex because the packets are *not* contiguous. If you stack up
writes and have concurrent file activity, there's a real chance that
the Windows filesystem will balk and fail to complete the write.
Again, a more complex disc and insufficient RAM increase the odds of
failure in my experience.

It's not the windows filesystem, it's the packet-writing software.

The most common cause of failure is the directory not being written
back correctly. That can happen on a system crash or power glitch;
a forced manual ejection; or simply a fault in the write of the
directory. Once a bad directory is written, not much can be done to
recover files. DCD 5 Scandisc, ISOBuster and CD-R Diagnostic are all
able to do something toward retrieving data from such a disc.

Of course, if the software was written _correctly_, none of this would
be an issue.

Most of the above is independent of the program used. In any case, if
compression is used, it increases the odds of failure and reduces the
chance of recovery - and usually doesn't improve storage
significantly. DCD has gradually decreased sensitivity to the
filesystem problems, but they're still there if you write a lot of
files concurrently. Again, that's essentially a Windows file
management issue.

The problems are all DCD's. Don't start to blame Windows for this one,
Mike.

I've used tape-as-a-removable-disk software, that _did_ implement
transactional semantics, and I never had the types of problems that
DirectCD exhibits. It's simply a matter that Roxio doesn't have a clue
how to code reliable software, in which a customer's precious data is
on the line.

Does the critical Windows hard-disk FAT16/FAT32 filesystem store the
entire FAT into RAM at startup, and only write out the changes again
at shutdown? NO! It updates it immediately, when there is a disk
update, to minimize the crucial window where data could be lost.

If the penalty for updating this often is too high (as it often is for
CD-RW media, both for speed and longevity reasons), then the proper
thing to do would be to maintain a write-buffer on the HD, with some
sort of logging filesystem, so that if there were an error on the disc
media, that the data could be easily recovered, and the entire disc
wouldn't be corrupted. I hope the new Mt. Rainier specification
addresses this problem, and buggy POS software like DirectCD becomes
the way of the past.
=================================

[No response from Mikey, but IT would go on spewing the above
cockamamie.]

--------------------------------------
Mike Richter, were you born with
"Scam Artist" emblazoned on your face?
--------------------------------------
(Mike Richter, any Material Connection w/ Roxio?)