"98 Guy" wrote in message ...
File copy test - Windows 98

-------------------------
Hardware Details:

8--------------------------------------------


Size: 405 gb (435,633,783 bytes) 441,899,741,184
Contains: 3,010,665 Files, 199,119 Folder

Screen capture of file-properties dialog box:

http://www.fileden.com/files/2007/5/.../file-test.jpg

Based on the size (135 gb) and time-stamps of the Super-x directories,
I calculated that the file-copy rate was effectively 11.5 mb per
second (it took 3.5 hours to copy the contents of Super-1 to Super-2).

chkdsk c:

487,431,968 kilobytes total disk space
52,323,392 kilobytes free

4096 bytes in each allocation unit
121,857,992 total allocation units on disk
13,080,848 available allocation units on disk


Something here does not make sense to me.
Here is a clip from your post in response to one of mine a few weeks ago.

...............................
For volumes larger than 64 gb, the cluster size remains at 32kb, but
the cluster count is allowed to exceed 2 million. Microsoft has
stated that the max cluster count is 4.177 million, which would result
in a volume size of 137 gb given a cluster size of 32 kb, which is
another way of arriving at the technical limitation of ESDI_506.PDR.
...............................

Are you using some third party vfat driver?
Or some other formatting program?

8----------------------

If anyone out there is not satisfied that my test methodology was not
sufficient to correctly test win-98 for a file-count limitation or a
directory-size limitation that may arise given current modern large
hard drives available today, please speak up and describe an alternate
test method.

I don't think there is a specific directory size (number of entries)
limitation, except in the root directory.
The directory entries would not know the total file size within the
directory - that must be computed.

I think the methodology is reasonable, but I have two concerns.
First, we know that windoze places files somewhat arbitrarily on the hard
drive, although fat32 is more 'front to back' then ntfs.
I would like to see a scandisk map (possibly using norton defrag, not
practical using scandisk) to show that the 'back' of the hard drive is
empty, and some proof that scandisk can read and write those sectors.
A reboot in between would be a good idea, since windows caches a bunch of
file data as it creates files and folders, which it may not be able to find
after a reboot.

As I recall, the problem is not in creating the files, it is in using them
Second, I would like to see some files written to the back of the hard
drive and successfully read, updated and re-read.

It would be interesting to see the comparison of file size actually written
to file space taken up.


As a comment, I don't believe that creating a set of zero-byte files
will necessarily accomplish or test windows-98 with the same level of
"stress" as the test I describe here.

I agree with that.

Some of this of academic interest only, as win98 and fat32 have so many
other limitations.

For the record, I had to switch to xp because
a) a few programs I need are not available in win98, and
b) I have video files which exceed the 2 gig/4 gig fat32 limit.

I still run 98 one some of the machines here, as there are some programs
which will not run properly in xp

Stuart