Packet Writing in Windows Vista!

================================================== ==
Mike Richter's Pussyfooting on Packet Writing (Lose)
================================================== ==

Mike Richter (cRoxio ****) crapped:

few people recommend packet writing (effected by DirectCD) for
general use. Though it is acceptable on write-once media (CD-R),
it is unreliable or worse on erasables (CD-RW).

Only unreliable? Why pussyfooting around, Mikey? The word is "lose":

======================
From: Mike Richter (cRoxio ****)
Date: 6/19/03

most of those who have written fixed-length packets
have either stopped doing so altogether or,
as I do, use the format only for test.

The format is bad - it loses data.
======================

Then again the supposedly 'bad' format - loses data - MUST be used for
Take Two, supposedly a BACKUP software, to work IDEALLY, no less!!

=======================
From: Mike Richter (Acraptec ****)
Date: 9/1/99
Subject: A note on Take Two

For Take Two to work IDEALLY, your drive MUST support
packet writing and you must have DCD installed...to do it.

You may back up ...to a DCD-formatted erasable.
=====================

----------------------------------------------
Mikey, you are The Slimiest Lying Friggin SOB!
----------------------------------------------
Mike Richter, were you born with
"Scam Artist" emblazoned on your face?
--------------------------------------
(Mike Richter, any Material Connection w/ Roxio?)

Hi smh,

Vista. I found using 2.01 to be reliable. It's well worth the move to
2.01 anyway, some operations are faster.

So the "slow" part is only with udf 1.50 as reported in the below link?

I think we'd need to test CD-RW again to be sure, but I did find certain
operations such as deleting a file much quicker after moving to UDF 2.01
on CD-RW, but as I say, I've pretty much decided to only use DVD-RW and
DVD-RAM now, so I probably won't get round to testing CD-RW. I'm
certainly happy with the speed and reliability (so far) with DVD media.

The dvd-ram I used is, I think, only 1x. It's slow and expensive.

Yup, I had to buy some new ones. I managed to get some 3x DVD-RAM, but
in theory you can get 5x to use with Plextor PX750A.

Just
remember that the hardware-based defect management helps only on
reliable data writing, not on long term archiving. Enjoy the new toy.

Does it work at all, I mean don't you need MRW for that?

--
Gerry_uk

Hi smh,

One sync program I used had some problem with InCD's "Non-Allocatable
Space". Doesn't Live UDF have a special file like that?

I know about the "Non-Allocatable list" or what ever it's called, but
I've never had any problems with it. I just use the basic WinAPI calls.

One thing that's crazy with InCD is that if you use a synch program,
that synch program will have to "access" each file, in order to see if
it needs updated, BUT merely "accessing" the file causes the "last
accessed" date/time stamp to be updated! This causes a serious
performance problem. I wrote to Ahead about it, and got a reply
something like "we value you custom".

Under DirectCD, the Adaptec engineers had spotted this problem and their
software didn't try to change the "last accessed" date/time stamp, clever!

With InCD, sometimes just looking at a file, or hovering the mouse over
it, causes the drive to burst into activity and start writing, for
reasons explained above.

--
Gerry_uk

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

Gerry_uk wrote:

Hi smh,

Vista. I found using 2.01 to be reliable. It's well worth the move to
2.01 anyway, some operations are faster.

So the "slow" part is only with udf 1.50 as reported in the below link?

I think we'd need to test CD-RW again to be sure, but I did find certain
operations such as deleting a file much quicker after moving to UDF 2.01
on CD-RW, but as I say, I've pretty much decided to only use DVD-RW and
DVD-RAM now, so I probably won't get round to testing CD-RW. I'm
certainly happy with the speed and reliability (so far) with DVD media.

The dvd-ram I used is, I think, only 1x. It's slow and expensive.

Yup, I had to buy some new ones. I managed to get some 3x DVD-RAM, but
in theory you can get 5x to use with Plextor PX750A.

Just
remember that the hardware-based defect management helps only on
reliable data writing, not on long term archiving. Enjoy the new toy.

Does it work at all, I mean don't you need MRW for that?

In order to be called DVD-RAM drive, the defect management is performed
by the drive. Bear in mind that the "defect management" is nothing more
than verify the write and then relocate the faulty block data to the
spare area, be it done in software or hardware. (In that perspective,
hardware management is nothing more than putting the software in
firmware.) Also, the defect management does not build any sort of
recovery record.

RAMPRG - RAM Promotion Group:
http://www.ramprg.com/en/a/main.html

.. -------------------------------------------
how HUGE are your BALLS, Adrian Miller?
-------------------------------------------
Only a trashy company like Roxio or Adaptec
let loosed in Usenet this utter trash
-------------------------------------------
Deirdre Straughan (Roxio) is a LIAR
-----------------------------------
Mike Richter is a LIAR
----------------------

Gerry_uk wrote:

One thing that's crazy with InCD is that if you use a synch program,
that synch program will have to "access" each file, in order to see if
it needs updated, BUT merely "accessing" the file causes the "last
accessed" date/time stamp to be updated! This causes a serious
performance problem.

Whatever operation you are performing, you should not go by the accessed
time. You should go by the modified time. And don't understand how
changes in the accessed time affect "performance".

Under DirectCD, the Adaptec engineers had spotted this problem and their
software didn't try to change the "last accessed" date/time stamp, clever!

=====================
From: "Marc"
Date: 12/14/01
Subject: Wrong file dates

I recently backed up a lot of data from my P2 and P3
to CD-R discs using Roxio Direct CD.

Now I noticed that all my PCs indicate that the Created and
Modified dates of the files on the CD-R discs are the date
and time that they were burned

=====================
From: PasserBy
Date: 9/27/02
Subject: Copy file to CDRW: file date NOT preserved!

Copying a file to CDRW formatted using DirectCD, the file's
timestamp is lost. The file timestamp becomes that of the
copy operation.

=====================
From: Joe Pyles
Date: 2/28/03
Subject: Roxio ECDC 6

Someone help me here, is it true that nobody gives a **** that
Roxio can't get the timestamps right?

For over 2 years they have been saying
that they are going to fix it
=======================

Hi smh,

In order to be called DVD-RAM drive, the defect management is performed
by the drive. Bear in mind that the "defect management" is nothing more
than verify the write and then relocate the faulty block data to the
spare area, be it done in software or hardware. (In that perspective,
hardware management is nothing more than putting the software in
firmware.) Also, the defect management does not build any sort of
recovery record.

OK, that explains a lot!

RAMPRG - RAM Promotion Group:
http://www.ramprg.com/en/a/main.html

This looks interesting, but it wants Flash plug-in, is there a text-only
version?

--
Gerry_uk

Hi smh,

The post from "Marc" is not related to what I'm talking about. He's
talking about when the files get burned with a time stamp that is the
time the file was written to disk, instead of the original time on the
source media.

it needs updated, BUT merely "accessing" the file causes the "last
accessed" date/time stamp to be updated! This causes a serious
performance problem.

Whatever operation you are performing, you should not go by the accessed
time. You should go by the modified time.

I know, obviously I don't use this time-stamp. See below..

And don't understand how
changes in the accessed time affect "performance".

OK, here's how it works. Windows has at least two time stamps,
LastModified, LastAccessed. The only one we care about is LastModified
_but_ when ever you "look" at a file in Windows the LastAccessed stamp
gets updated to reflect the time you "last accessed" the file.

On a fixed disk volume, this is not an issue because it's very fast and
is cached anyway. On a CD-RW it's a problem. Let's say you insert your
packet writable CD-RW into a Windows computer and look at 400 photos
(e.g. using a Thumbs Viewer program), Every file read by the photo
viewing program will suddenly cause a WRITE operation on the CD-RW
drive, causing the laser to fire-up. Bad, bad, bad. You only performed
READ operations on the disk, but you ended up doing 400 write operations
and that's bad for performance (reading and writing at the same time).

Under DirectCD, the Adaptec engineers had spotted this problem and their
software didn't try to change the "last accessed" date/time stamp, clever!

--
Gerry_uk

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

Gerry_uk wrote:

Hi smh,

The post from "Marc" is not related to what I'm talking about. He's
talking about when the files get burned with a time stamp that is the
time the file was written to disk, instead of the original time on the
source media.

(There is no time stamp called "original".)

You are correct that "Marc" - in fact all three posts - is not talking
about the unimportant accessed time, but about the all important
modified time -- which should not be changed to that of creation/copy
time.

it needs updated, BUT merely "accessing" the file causes the "last
accessed" date/time stamp to be updated! This causes a serious
performance problem.

Whatever operation you are performing, you should not go by the accessed
time. You should go by the modified time.

I know, obviously I don't use this time-stamp. See below..

And don't understand how
changes in the accessed time affect "performance".

OK, here's how it works. Windows has at least two time stamps,
LastModified, LastAccessed.

Whatever happened to the "original" time?

The only one we care about is LastModified

Wouldn't have known that's the case when you sort of discredit the
Marc's post because it does not talk about the accessed time you are
harping about.

_but_ when ever you "look" at a file in Windows the LastAccessed stamp
gets updated to reflect the time you "last accessed" the file.

On a fixed disk volume, this is not an issue because it's very fast and
is cached anyway. On a CD-RW it's a problem. Let's say you insert your
packet writable CD-RW into a Windows computer and look at 400 photos
(e.g. using a Thumbs Viewer program), Every file read by the photo
viewing program will suddenly cause a WRITE operation on the CD-RW
drive, causing the laser to fire-up. Bad, bad, bad. You only performed
READ operations on the disk, but you ended up doing 400 write operations
and that's bad for performance (reading and writing at the same time).

Those write operations are done in idle period so as not to interfere
with any pending operation.

Under DirectCD, the Adaptec engineers had spotted this problem and their
software didn't try to change the "last accessed" date/time stamp, clever!

You access a file, but the access time is not changed. And you call that
"clever". I call it a bug.

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

Gerry_uk wrote:

RAMPRG - RAM Promotion Group:
http://www.ramprg.com/en/a/main.html

This looks interesting, but it wants Flash plug-in, is there a text-only
version?

You are not missing much. All it shows is the read/verify/replace
operations.

BTW, it's obvious that you are still very much interested in packing
writing and its problems. Wonder why then you still have not asked
Mikey about the "problems" Mikey spewed?

================================================== ======================
Gerry_uk (Mikey S-Licker) slurped:

Maybe you can enlighten us with the "truth" as you see
it as opposed to "who said what" in some dim and distant past?

If you are so interested in finding out the "truth" about UDF/Fixed, why
didn't you ask Mikey what are the "problems" when Mikey crapped that on
you?

======================
From: Mike Richter (The Slimiest Lying Friggin ****)
Date: 9/9/06

Gerry_uk wrote:
snip

I've not used packets on DVD, so have no comment on whether
the problems of fixed-length packets on CD carry over.
======================
[Is (9/9/06) some dim and distant past, Gerry?]

But I have been asking. Here's the third one I asked:

================================================== ========
Mike Richter crapped (9/9/06):

I've not used packets on DVD, so have no comment on whether
the problems of fixed-length packets on CD carry over.

Is it now only "problems", not even "the most fragile and least reliable
format"? Is the word 'format' no longer in your vocabulary, Mikey?

================================================== ============
Mike Richter - The Slimiest Friggin SOB (udf/fixed)(pussyfoot)
================================================== ============

Mike Richter crapped (5/4/06):

I have used UDF for many years, but yesterday I had my first
corruption. I am now wondering whether to bother with UDF at all
.
.
First, your problem is not with UDF

Second, fixed-length packets are
the most fragile and least reliable format

(Do you dig the "format" out of your asshole, Mikey?)

Why are you pussyfooting around with "the least reliable", Mikey?
Is the word "unreliable" no longer in your vocabulary, Mikey?

======================
From: Mike Richter
Date: 4/9/01

Fixed-length packets are notoriously unreliable
=====================

BTW, does "the least reliable" logically translate to "unreliable"?
..

----------------------------------------------
Mikey, you are The Slimiest Lying Friggin SOB!
----------------------------------------------
Mike Richter, were you born with
"Scam Artist" emblazoned on your face?
--------------------------------------
(Mike Richter, any Material Connection w/ Roxio?)

Hi smh,

The writing of the LastAccessed timestamp is not done in "idle" time, it
starts as soon as you perform file read operations on the disk. Updating
accessed time on removable media is pointless, it's not a "bug" to turn
off this behavior, it's a good idea! Actually, the LastAccessed time is
pointless even on fixed disks; as soon as an Audit guy tries to look at
the timestamp, it will suddenly be updated because _he_ has just tried
to look at it.

smh wrote:
. --------------------------------------
Mike Richter, were you born with
"Scam Artist" emblazoned on your face?
--------------------------------------

Gerry_uk wrote:
Hi smh,

The post from "Marc" is not related to what I'm talking about. He's
talking about when the files get burned with a time stamp that is the
time the file was written to disk, instead of the original time on the
source media.

(There is no time stamp called "original".)

You are correct that "Marc" - in fact all three posts - is not talking
about the unimportant accessed time, but about the all important
modified time -- which should not be changed to that of creation/copy
time.

it needs updated, BUT merely "accessing" the file causes the "last
accessed" date/time stamp to be updated! This causes a serious
performance problem.
Whatever operation you are performing, you should not go by the accessed
time. You should go by the modified time.
I know, obviously I don't use this time-stamp. See below..

And don't understand how
changes in the accessed time affect "performance".
OK, here's how it works. Windows has at least two time stamps,
LastModified, LastAccessed.

Whatever happened to the "original" time?

The only one we care about is LastModified

Wouldn't have known that's the case when you sort of discredit the
Marc's post because it does not talk about the accessed time you are
harping about.

_but_ when ever you "look" at a file in Windows the LastAccessed stamp
gets updated to reflect the time you "last accessed" the file.

On a fixed disk volume, this is not an issue because it's very fast and
is cached anyway. On a CD-RW it's a problem. Let's say you insert your
packet writable CD-RW into a Windows computer and look at 400 photos
(e.g. using a Thumbs Viewer program), Every file read by the photo
viewing program will suddenly cause a WRITE operation on the CD-RW
drive, causing the laser to fire-up. Bad, bad, bad. You only performed
READ operations on the disk, but you ended up doing 400 write operations
and that's bad for performance (reading and writing at the same time).

Those write operations are done in idle period so as not to interfere
with any pending operation.

Under DirectCD, the Adaptec engineers had spotted this problem and their
software didn't try to change the "last accessed" date/time stamp, clever!

You access a file, but the access time is not changed. And you call that
"clever". I call it a bug.


--
Gerry_uk