Virtual Machine and NTFS
mm
planned to run it from a Virtual Machine under winxpsp3
Is it okay to have all the harddrive partitions NTFS, even though
win98 can't normally read NTFS?
Thanks
Much Less important:
Is Connectix Virtual PC for Windows, version 5, okay? Or is it
obsolete by now. It lists XP on the box, but I wonder if it will have
USB support with version 5.
Paul
I'm using VirtualPC 2007, which is a free download from Microsoft.
There was an original file, and an SP1 file, and since they're both
about the same size, I expect the SP1 file is standalone and ready to go.
(I probably installed them sequentially, but it likely isn't necessary.)
"Microsoft Virtual PC 2007 SP1"
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=28C97D22-6EB8-4A09-A7F7-F6C7A1F000B5
You can install Win98 inside the Virtual Machine and use FAT32
if you want. The virtual environment emulates a "hard drive", so
even Linux EXT2/EXT3/EXT4 or DOS is possible. It's up to your installer CD
or floppies, to do the formatting etc. (Or alternately, you can even run
multiple different installer CDs, like run a GParted CD in the
virtual environment, set up partitions perhaps, reboot the VM,
then run the Win98 installer CD and so on.)
A 512MB RAM setting, is the best choice for Win98, before you
do the install. You can change the RAM setting later, as long
as the VM is shut down first so you can make the change.
VPC2007 is very flexible. The only thing it isn't good at, is support
for Linux via the add-ons pack. Add-ons are provided for
Windows OSes, so the desktop integration is seamless (drag
and drop into a VPC window works). But for Linux, only a couple
OSes have support, and I didn't have any luck doing anything
with the provided files. So I don't know if the limited support
for Linux is helping any actual users or not. Getting files
across to Linux in there, is a PITA. Normally, I keep
file sharing turned off in WinXP, so I don't really want
to go the SAMBA route in Linux just so I can transfer files.
I have used SAMBA, to transfer files across, but that messes
up some other things.
In any case, I don't want to spoil your fun. Start experimenting!
You can't break anything. You can run out of disk space or
RAM of course.
And if you need to "drag a real environment" into the virtual world,
there is this. My WinXP is on a ~70GB partition, and using this
tool, it copies just the files into a VHD. The resulting file when
I did it, was about 46GB. When you run a virtual machine, using
that VHD file, of course the emulated hardware doesn't match,
and in the case of WinXP, you'd be facing activation. The implication
for you is, you may be able to copy your existing Win98 image across,
application programs and all. I haven't tried that with Win98 (I
don't have a working install any more of that). So if you really
want to be heroic, you can give this a shot. You'll need to store
the output from this tool on an NTFS partition (due to the file size),
but the emulated machine inside can be FAT32. So if your Win98
is installed on a FAT32 partition, this tool can still make a
VHD from it. This tool copies the MBR of the real disk, onto
the virtual VHD, but only so that the boot sequence inside
the virtual environment will work properly.
http://technet.microsoft.com/en-ca/sysinternals/ee656415.aspx
BTW - if you have a multi-core processor, VPC2007 emulates a single
core inside the virtual environment. The disk2vhd tool has a "HAL
change" option, which is how I could move my WinXP image on a dual
core processor, inside the single core environment, and still
have it boot properly. When I did my experiment, I wasn't expecting
to have a working WinXP (I don't have two license keys for that
purpose). What I did want though, is to be able to use other tools,
like an offline virus scanner - in other words, I wanted a
realistic set of files for test purposes. While WinXP did boot,
of course it gave me a 72 hour deadline to activate, so such a
move from real to virtual, would only have lasted that long if
I intended to work in it.
Paul
philo
> Hi! I"m moving to a new machine that probably won't run win98, so I
> planned to run it from a Virtual Machine under winxpsp3
>
> Is it okay to have all the harddrive partitions NTFS, even though
> win98 can't normally read NTFS?
>
It should work just fine.
If there are any problems they will not be due to the drive being NTFS
at any rate
<snip>
mm
Great, thank you. Now I have all the parts to fix up my friends old
2.4 gig Dell for myself. I think I'll like the increased speed.
>
><snip>
J. P. Gilliver (John)
suggests to me that you are) anyway, received wisdom here seems to be
that you should set it up as FAT anyway: the alleged benefits of NTFS
being largely moot for the single home user, and XP will operate
perfectly happily under FAT.
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
freedom of speech is useless if nobody can hear you.
-- David Harris -- Author, Pegasus Mail Dunedin, May 2002.
philo
>
>>>
>>>
>>> It should work just fine.
>>>
>>> If there are any problems they will not be due to the drive being NTFS
>>> at any rate
>>
>> Great, thank you. Now I have all the parts to fix up my friends old
>> 2.4 gig Dell for myself. I think I'll like the increased speed.
>>>
>>> <snip>
>>
> If you're actually starting from scratch (which "have all the parts"
> suggests to me that you are) anyway, received wisdom here seems to be
> that you should set it up as FAT anyway: the alleged benefits of NTFS
> being largely moot for the single home user, and XP will operate
> perfectly happily under FAT.
I beg to differ.
First off, on a large partition fat32 has very poor cluster size as
compared to NTFS. Additionally , since many people are now storing
movies and such with large files sizes, fat32 cannot handle any files
over 4 gigs .
Additionally, XP is *deliberately* crippled in that it cannot create a
fat32 partition larger than 32 gigs. If one wanted to install XP on a
fat32 partition larger than 32 gigs, though it's possible to do...
it's not possible to do from the XP installer.
Though for a home user, the security features of NTFS may not be needed,
what's extremely important is the fault tolerance of NTFS.
I do a lot of computer repair work and have seen entire fat32 file
systems hosed by a bad shut down. The user, in attempt to fix things has
typically run scandisk and *sometimes* has ended up with a drive full of
.chk files.
OTOH:
I've seen some rather dramatic file system recoveries under NTFS running
chkdsk /f or chkdsk /r .
Note: I am not saying a bad shut down will always destroy a fat32
installed OS...nor am I saying that NTFS is infallible. What I am saying
is that NTFS is considerably more resilient.
The thing some people find convenient about fat32 is that the system can
easily be accessed by a win98 boot floppy. However an NTFS drive can
still be accessed from the repair console...or from a live Linux cd
glee
news:x35I+S9e...@soft255.demon.co.uk...
> In message <en5kb6pi2echl4pej...@4ax.com>, mm
> <NOPSAM...@bigfoot.com> writes:
>>On Sat, 16 Oct 2010 07:16:58 -0500, philo <ph...@privacy.net> wrote:
>>
>>>On 10/16/2010 12:33 AM, mm wrote:
>>>> Hi! I"m moving to a new machine that probably won't run win98, so
>>>> I
>>>> planned to run it from a Virtual Machine under winxpsp3
>>>>
>>>> Is it okay to have all the harddrive partitions NTFS, even though
>>>> win98 can't normally read NTFS?
>>>>
>>>
>>>
>>>
>>>It should work just fine.
>>>
>>>If there are any problems they will not be due to the drive being
>>>NTFS
>>>at any rate
>>
>>Great, thank you. Now I have all the parts to fix up my friends old
>>2.4 gig Dell for myself. I think I'll like the increased speed.
>>>
>>><snip>
>>
> If you're actually starting from scratch (which "have all the parts"
> suggests to me that you are) anyway, received wisdom here seems to be
> that you should set it up as FAT anyway: the alleged benefits of NTFS
> being largely moot for the single home user, and XP will operate
> perfectly happily under FAT.
I too must beg to differ, for many of the same reasons as philo. There
are other reasons besides security to use NTFS in this scenario.
Also, if you use FAT32, you will have to limit Virtual PC's VHD files'
size to 4GB....another shortcoming.
--
Glen Ventura
MS MVP Oct. 2002 - Sept. 2009
CompTIA A+
http://dts-l.net/
glee
news:en5kb6pi2echl4pej...@4ax.com...
Are you using XPSP3 Home or Pro Edition as the host OS?
If you find the old Connectix version 5 does not do all you want, try
the newer free version, Virtual PC 2007:
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=04D26402-3199-48A3-AFA2-2DC0B40A73B6&displaylang=en
Philo is wrong
> > If you're actually starting from scratch (which "have all the
> > parts" suggests to me that you are) anyway, received wisdom
> > here seems to be that you should set it up as FAT anyway:
> > the alleged benefits of NTFS being largely moot for the
> > single home user, and XP will operate perfectly happily
> > under FAT.
>
> I beg to differ.
>
> First off, on a large partition fat32 has very poor cluster
> size as compared to NTFS.
That is myth #1.
I have formatted a 500 gb SATA drive as single partition FAT32 using 4
kb cluster size (the default cluster size for NTFS) and have installed
and run Windows 98se from such a drive. That drive had 120 million
clusters, and is not compatible with certain drive diagnostic and
optimization tools (like the windows me version of scandisk). The DOS
version of scandisk does run and function properly, however.
You must use third-party drive preparation software to create a FAT32
volume with non-standard cluster size, because Microsoft intentionally
forces format.com to scale up the cluster size along with the volume
size so as to maintain about a max of 2 million clusters. There is no
technical reason for doing this, but it established the concept in the
minds of many that FAT32 has this problem where it must use large
cluster sizes as volumes get bigger.
All that said, it should be noted that maintaining a small cluster size
(say 4 kb) on a relatively large volume (say, anything larger than 32
gb) is not really useful from a file-layout perspective. For those that
have large drives (250 gb or larger) and that create large partitions
just to store large media files, the use of 32kb clusters is more
optimal than 4 kb.
> Additionally , since many people are now storing movies and such
> with large files sizes, fat32 cannot handle any files over 4 gigs.
While that is true, it rarely comes up as a realistic or practical
limitation for FAT32. The most common multimedia format in common use
is the DVD .VOB file, which self-limit themselves to be 1 gb.
The only file type that I ever see exceed the 4 gb size are virtual
machine image files, which you will not see on a win-9x machine but you
would see on an XP (or higher) PC running VM Ware, Microsoft Virtual PC,
etc. But 4 gb should be enough to contain a modest image of a virtual
windows-98 machine.
> Additionally, XP is *deliberately* crippled in that it cannot create
> a fat32 partition larger than 32 gigs.
That is true, but it's not a limitation of FAT32 (I thought this was a
list of bad things about FAT32).
There is plenty of third-party software that allows you to create FAT32
volumes larger than 32 gb on a win-2k/XP/etc machine, and one can always
boot an MS-DOS floppy with format and fdisk and create such a volume
that way.
> If one wanted to install XP on a fat32 partition larger than
> 32 gigs, though it's possible to do... it's not possible to
> do from the XP installer.
If a the desired FAT32 partition has already been created before
starting the installation of XP, then XP will install itself onto that
partition, even if the partition is larger than 32 gb.
> Though for a home user, the security features of NTFS may not be
> needed, what's extremely important is the fault tolerance of NTFS.
Given modern drives that for the past 5 to 8 years have had their own
ability to detect and re-map bad sectors and their own internal caching,
the need for the transaction journalling performed by NTFS has been
greatly reduced. And for the typical home or SOHO PC that is not a
server, NTFS is more of a liability than a benefit.
NTFS is a proprietary format and is not fully documented. It's
directory structure is stored in a distrubuted way across the drive,
mixed in with user data. An NTFS volume can be hosed in such a way as
to render recovery practically impossible, and most NTFS recovery
software is very expensive. FAT32 file structure is simple and
file-chain reconstruction is trivial and can restore any volume that at
first look appears to be completely trashed.
The extra sophistication and transaction journalling performed by NTFS
reduces it's overall performance compared to FAT32. So for those who
want to optimize the over-all speed of their PC's, FAT32 is a faster
file system than NTFS.
> I do a lot of computer repair work and have seen entire fat32
> file systems hosed by a bad shut down. The user, in attempt to
> fix things has typically run scandisk and *sometimes* has ended
> up with a drive full of .chk files.
That's another common myth about FAT32 - that the appearance of many
.chk files must mean that it's inferior to NTFS.
While it might look untidy, the mere existance of those .chk files don't
mean anything about how compentent or capable FAT32 is, and it's not
hard to just delete them and get on with your business.
You did not say in your example if the user's drive and OS was operable
and functional despite the existance of those .chk files.
> What I am saying is that NTFS is considerably more resilient.
What you don't understand about NTFS is that it will silently delete
user-data to restore it's own integrity as a way to cope with a failed
transaction, while FAT32 will create lost or orphaned clusters that are
recoverable but who's existance is not itself a liability to the user or
the file system.
> The thing some people find convenient about fat32 is that the
> system can easily be accessed by a win98 boot floppy.
Or, if you've installed DOS first on an FAT32 drive, and then install XP
as a second OS, you can have a choice at boot-up to run DOS or XP.
> However an NTFS drive can still be accessed from the repair
> console...
The repair console is garbage and does not compare in any way to the
utility and capability of a real DOS-type command environment.
philo
> philo wrote:
>
<snip>
I'm snipping most of this as I don't want to get into a big argument
here and yes, you've made some valid points but I will respond to the
following as it's important:
>
> While it might look untidy, the mere existance of those .chk files don't
> mean anything about how compentent or capable FAT32 is, and it's not
> hard to just delete them and get on with your business.
>
> You did not say in your example if the user's drive and OS was operable
> and functional despite the existance of those .chk files.
>
In some cases, after running scandisk,
there were a lot of .chk files but the operating system and data are
intact...the .chk files can simply be deleted
However in *some* situations I've seen all or most data on the drive
converted to .chk files and a data recovery of any type would be close
to impossible.
The likelihood of a "repair" turning that catastrophic on an NTFS file
system is considerably less...though of course not impossible.
As I've mentioned, I've seen some nearly miraculous recoveries on NTFS
systems...one I recall vividly was on a drive that had physically gone
into failure and had severe read/write errors.
Though it was tedious I ended up retrieving 99% of the data...
and that was due to NTFS' MFT which is of course lacking on fat32
Hot-Text
size of the Hard Drive!
Philo that's way they say you are wrong
XP FAT32 system and NTFS repair the same
Philo that's way they say you are wrong
And after running scandisk, if their a lot of .chk files it's time to get
and New Hard Drive and Xcopy the old Hard Drive it!
Philo that's way they say you are wrong
And you have a Linux i686; and reading the Newsgroups from a Thunderbird
Philo that's way they say you are wrong
Hot-Text
And can help you out
"mm" <NOPSAM...@bigfoot.com> wrote in message
news:rddib61mstpocphcu...@4ax.com...
Paul
I think what I'm seeing here, is Virtual PC will make multiple files when
the virtual disk goes above 4GB. If you create a virtual machine on a
FAT32 partition, and the virtual machine stores 12GB of files, you'll
see three VHD files on disk. If the same virtual machine was started
on an NTFS partition, then you'd see a single 12GB file.
The upper limit on virtual volume size, could be 128GB. If that was
stored on a FAT32 partition, that would take 32 VHDs.
Paul
philo
>
*plonk*
Hot-Text
"philo" <ph...@privacy.net> wrote in message
news:UKSdnRZseqgV3CbR...@ntd.net...
Bill in Co
wrong", one wonders if it would be worth it. Are you "98guy" in disguise?
:-)
Patok
> mm wrote:
>> Hi! I"m moving to a new machine that probably won't run win98, so I
>> planned to run it from a Virtual Machine under winxpsp3
>>
>> Is it okay to have all the harddrive partitions NTFS, even though
>> win98 can't normally read NTFS?
>>
>> Thanks
>>
>> Much Less important: Is Connectix Virtual PC for Windows, version 5,
>> okay? Or is it
>> obsolete by now. It lists XP on the box, but I wonder if it will have
>> USB support with version 5.
>
> I'm using VirtualPC 2007, which is a free download from Microsoft.
> There was an original file, and an SP1 file, and since they're both
> about the same size, I expect the SP1 file is standalone and ready to go.
> (I probably installed them sequentially, but it likely isn't necessary.)
>
> "Microsoft Virtual PC 2007 SP1"
> http://www.microsoft.com/downloads/en/details.aspx?FamilyID=28C97D22-6EB8-4A09-A7F7-F6C7A1F000B5
Thanks for the heads-up. I had assumed (and you know how that turns out) :)
that the MVPC is only for Windows 7 (because of the name). I need to have some
Linux running because of some compilers, but couldn't install Ubuntu because of
Wubi and Grub issues in the latest version, which are solvable in principle, but
require too much effort. I have run VmWare before with no problems - is VPC 2007
similar in performance and functionality? I'll give it a try.
--
You'd be crazy to e-mail me with the crazy. But leave the div alone.
--
Whoever bans a book, shall be banished. Whoever burns a book, shall burn.
Paul
I run Ubuntu 10.04 in a VPC2007 virtual machine. The virtual machine
only emulates one core of my dual core processor. There is no
desktop integration - I can't drag and drop a file from Windows
into the Linux desktop. I also had to "jump through hoops" to set the
emulated screen resolution. Using an Nvidia "xorgconfig" utility,
I generated a half decent xorg.conf and used that so I could get
more than 800x600 resolution. Currently, I'm at 1600x1200, but
I can't drop the screen size to anything smaller (screen gets messed
up). I've left it alone, because at least I can see plenty of desktop
space now :-(
If you want to share files, the best way would be with Windows file
sharing (and Linux SAMBA). I don't like to leave file sharing
turned on, but if you need to copy files bad enough, that
is the easiest thing to do. There is also FTP, if you happen
to have an FTPD you can use.
Other than that, it works. To "get the cursor out of the Ubuntu window",
you press "right-Alt" key, and move the cursor out. If there were
proper VPC "add-ins" for the popular Linux distros, things might be
different. Microsoft does offer some, but only for the more
"commercial" versions of Linux (SUSE?).
These never helped me, with any experiments I was doing, but
you never know - someone must use this stuff.
Paul
glee
news:iaSdnVxFUMN01CbR...@earthlink.com...
> We could get into a debate on this, but with someone posing as "Philo
> is wrong", one wonders if it would be worth it. Are you "98guy" in
> disguise? :-)
I'd say that's quite likely, if not outright obvious. A 500GB SATA
drive as a single 4KB-cluster FAT32 partition, running Win98? Who else
do we know that does this and recommends it? ;-)
--
Wrong is Philo
> We could get into a debate on this, but with someone posing
> as "Philo is wrong", one wonders if it would be worth it.
You should have just continued the debate, because of course it's going
to be worth it. Do you actually have any ammunition to counter the
points I raised?
> Are you "98guy" in disguise?
> :-)
Affirmative.
philo also top-poasted:
> In some cases, after running scandisk,
>
> there were a lot of .chk files but the operating system and data
> are intact...the .chk files can simply be deleted
Yup - that's usually the case.
> However in *some* situations I've seen all or most data on the
> drive converted to .chk files and a data recovery of any type
> would be close to impossible.
I've also seen NT servers destroy 14 days worth of IIS log files because
of a power failure. You would think that once a file is closed, that
it's secure and wouldn't be touched by journal recovery, but that's
exactly what happened when real data got replaced by nulls in those
files after the next boot-up.
I have probably over 200 years worth of FAT32 hard-drive usage
experience (if you add up all the years of service of various FAT32
drives that I've installed, maintained, touched in one way or another,
etc) over the past dozen years.
The single most frequent cause of having to really pull out the
sophisticated tools to recover a FAT32 drive is not because of the
design of FAT32 or an issue with the OS itself (which for me is
win-95/98). The reason is the inherent stability or design or proper
functionality of the drive itself.
And this is perhaps why a lot of people frown on FAT32 (and on win-9x in
general) is because of the caliber of hardware that was available during
their heyday. Back during 1995 through I'll say 2002, hard drives were
shit when it came to reliability and stability, and NTFS was designed to
do things like journalling and dynamic bad-sector remapping because that
stuff wasn't done in the drive.
A simple OS like Win-9x running FAT32 could tolerate flaky drive
operation (even if it meant leaving a trail of .chk files) but a flaky
drive running on an NT-based PC in a server role can really cause
problems for an organization.
So again, let's review:
There were huge changes in PC hardware and hard drives during the 1995 -
2002 timeframe. The amount of ram installed in the average PC,
stability of drivers for new chipsets, video cards, etc. Designers were
still learning how to make a stable AGP interface on the motherboard and
the video card. Hard drives were shit in terms of performance and
reliability. Win-9x and FAT32 got a bad-rap during that time frame
because of the shitty hardware and pathetic computer specs they were
faced with using.
Hard drives in the range of 1 to 10 gb were the most problematic, and
they date to that era. Once the 20 and (more like) the 40 gb drives
began to appear, that marked a new era in hard drive reliability and
sophistication and the benefits of NTFS from an error-correction
standpoint became irrelavent.
The low point for me was that I had to recover an 8 gb FAT32 drive that
had no discernable file-system on it (for what-ever reason). I used
"Lost and Found" which was able to rebuild all of the files on that
drive to blank slaved recovery drive using chain reconstruction. That
was 9 or 10 years ago.
Those days are long gone since all of my win-98 machines got 80 gb
drives running on 512 mb, P4 2.5 ghz machines 6 years ago.
I'll say this again: NTFS will sacrifice user-data in order to maintain
file-system integrity as it recovers from faulty transactions or
unexpected shutdown events, but FAT32 can tolerate many faulty
transactions without needing to do anything to maintain file-system
usability and accessibility.
If you haven't had much exposure to FAT-32 as implimented on a 40 gb or
larger drive during the past 6 years, then you really don't have enough
relevent experience to say that FAT32 is inferior to NTFS in terms of
real-world operational usefulness, stability or data integrity.
NTFS is not needed for home or soho computers, it has no true bootable
command shell environment, it's a proprietary design and recovery tools
are far more expensive compared to FAT32, it has several design elements
that add rarely used features but which aid malware installation and
operation (root-kits, hidden streams, etc), it does not lend itself for
use on flash or solid-state drives, (I could go on).
> The likelihood of a "repair" turning that catastrophic on an
> NTFS file system is considerably less...though of course not
> impossible.
The way that the directory structure is designed and stored on an NTFS
volume is far more complex, distributed and "delicate" as compared to
FAT32. Which is why it's like a living thing - always looking out for
itself, healing itself, etc. Those activities place additional burdens
on the hard drive (additional transactions) which themselves take a toll
on the drive mechanics. And they certainly cause a reduction in
file-system performance. FAT32 has no such dynamic overhead - it's a
true static structure.
> As I've mentioned, I've seen some nearly miraculous recoveries on
> NTFS systems...one I recall vividly was on a drive that had
> physically gone into failure and had severe read/write errors.
And I've held failing FAT32 drives in my hand as they were powered up
and operating, as I manipulate the drive into various positions and
angles as I try to coax a read operation to be successful - sometimes
giving the drive a jolt or knock with my other hand to tease that last
cluster to be read from it as I copied an important file from it to
another drive.
And it worked.
After which I naturally retired that drive - never to be used again in
any of my computers.
That was years ago, and I've never since had to do anything like that.
If it was an NTFS drive, I'm sure that the file system would have nuked
that sector if not the entire file and made it impossible for me to
recover it.
> Though it was tedious I ended up retrieving 99% of the data...
> and that was due to NTFS' MFT which is of course lacking on
> fat32
FAT32 has 2 FAT structures (two complete copies of the FAT tables) and
even if they are completely destroyed, the simple way that files are
laid out on a FAT32 drive means that it is still possible to reconstruct
the files and get them back - something that can't be done on NTFS.
glee
news:i9g05p$6o3$1...@news.eternal-september.org...
I've been told VirtualBox is better than VPC for running Linux in a VM.
philo
200 years of experience...
ok you win, my computer experience only goes back to 1968.
Sheesh
I didn't even know they had computers 200 years ago.
damn
I sure missed that one.
Philo Surrenders
> > I have probably over 200 years worth of FAT32 hard-drive usage
> > experience
This is how Philo surrenders an argument. Watch:
> 200 years of experience...
> ok you win, my computer experience only goes back to 1968.
Because he didn't quote the rest of my statement:
> > (if you add up all the years of service of various FAT32
> > drives that I've installed, maintained, touched in one way
> > or another, etc) over the past dozen years.
> Sheesh
>
> I didn't even know they had computers 200 years ago.
So this is how you bail on an argument?
Or do you really not understand that 200 years could mean 5 years worth
of experience with 40 hard drives?
> damn
>
> I sure missed that one.
Yes - yes you did.
You old phart.
Tell me, do you miss your bum-buddy MEB?
Bill in Co
> philo top-poasted:
>
>>> I have probably over 200 years worth of FAT32 hard-drive usage
>>> experience
>
> This is how Philo surrenders an argument. Watch:
>
>> 200 years of experience...
>> ok you win, my computer experience only goes back to 1968.
>
> Because he didn't quote the rest of my statement:
>
>>> (if you add up all the years of service of various FAT32
>>> drives that I've installed, maintained, touched in one way
>>> or another, etc) over the past dozen years.
>
>> Sheesh
>>
>> I didn't even know they had computers 200 years ago.
>
> So this is how you bail on an argument?
>
> Or do you really not understand that 200 years could mean 5 years worth
> of experience with 40 hard drives?
Hate to break this to ya, but that's not the same thing. Logic 101.
"200 years of experience" means exactly what it says - literally. You'd
have to back to 1810. I think that was even before the Civil War, just
before my time.
Now, OTOH, saying something like 200 man-hours....or say 200 ma-H, that's
completely different.
Philo Surrenders
> > Or do you really not understand that 200 years could mean 5 years
> > worth of experience with 40 hard drives?
>
> Hate to break this to ya, but that's not the same thing.
Oh, because I didn't say 200 *drive* years?
So you must agree with most else of what I wrote, since this is the only
nit you're picking...
Bill in Co
> "Bill in Co" <surly_cu...@earthlink.net> wrote in message
> news:iaSdnVxFUMN01CbR...@earthlink.com...
>> We could get into a debate on this, but with someone posing as "Philo
>> is wrong", one wonders if it would be worth it. Are you "98guy" in
>> disguise? :-)
>
> I'd say that's quite likely, if not outright obvious. A 500GB SATA
> drive as a single 4KB-cluster FAT32 partition, running Win98? Who else
> do we know that does this and recommends it? ;-)
Maybe I'm forgetting something, but I seem to recall that as the partition
size got bigger, the cluster size also HAD to get larger (up to 32K max) to
keep the maximum allowable number of clusters within the max 16 bit value
(65,536) for FAT32. So how could one possibly have 4 KB clusters on a 500
GB volume with FAT32?
Bill in Co
> Bill in Co wrote top-poasted and unnecessarily full-quoted:
>
>> We could get into a debate on this, but with someone posing
>> as "Philo is wrong", one wonders if it would be worth it.
>
> You should have just continued the debate, because of course it's going
> to be worth it. Do you actually have any ammunition to counter the
> points I raised?
As I said in the other post:
Bill in Co
I don't know how you (or anyone else for that matter) can get used to such
small type (with a 1600x1200 screen resolution). I'm using 800x600 and
love it, and get mad when a couple of programs force me to use 1024x768.
Who needs all that extra real estate (and small type)? :-) But at least
I can see it in the future (1024x768) - but only if I have to.
Hot-Text
Do you see they do not have a Window to look out of, just to see if a dog in
the street!
Now on too 500GB SATA you can't Install windows 98 on a partition no
bigger then 32GB.
But you can Xcopy a 32GB partition with a working windows 98 to a 500GB
SATA .with a FAT32 and it will run and same time Error!
to keep it from Erring you have to do it like the old 3.0 or 95 windows by a
2GB partitions..
With 98 you would have to make a 1 partition 32GB C:\ to install on
and 1 partition 76 GB 4 partitions 100GB to keep it from have ERRING all the
time
that give you 6 partitions and it okay to have 1 partition FAT32 and 5
partitions NTFS, win98 can read NTFS just can't run on it!
or
you can make one 1 partition 32GB and make no more partition on it and 98
will run with no Errors!
or
Glen you know you can run windows 98 in a Virtual Machine. on a 500GB SATA
Partition #1 200GB NTFS for C:\Virtual Machine and partition #2 32GB
FAT32 D:\Windows 98
And the 268 Free GB for a rainy Day.
Partition #1 can be 2GB C:\Virtual Machine
Calculator Calculator Calculator
Use it it go a long ways
Hot-Text
running Win98..
on a 500GB SATA Make it a 32GB partition will give you 468 free GB,
Making that 500GB SATA in to a 32GB SATA if that all you running that all
it is!
Paul
Actually, I'm running Ubuntu right now, in it's windowed world. And comparing
the typeface of the terminal windows I'm working in, they're the exact same
size characters as this Windows thing I'm typing in. So in fact, both
environments (real Windows, virtual Ubuntu), look quite similar. The color
scheme in Ubuntu is different, as are the window decorations, but the text is
just as readable.
I boot another environment occasionally, the Kaspersky offline virus scanner
(which is based on Gentoo), and for whatever reason, the text looks dreadful.
I actually have to open text versions of saved reports from that one, to
be able to read them. Any of the live windows, displaying results, are
unreadable. I think there is something slightly off, about the
resolution setting, but I can't find any tool on that particular
distro, to tell me what resolution is being used. The "xdpyinfo" tool
is missing. As is "xrandr".
So the Linux world can be perfectly normal, or terrible, purely
on somebody's whim.
I could probably fix that Gentoo one, by putting an argument on the
boot command line, to change the video mode, and maybe that would
fix it. But I wouldn't have a clue what I was doing. It
would be something like VGA=0x31A or VGA=792, and then maybe
the text would look better. (As is normal with Linux, you
can spend all day experimenting, and never get anything done.)
Linux kernel video mode numbers
640�480 800�600 1024�768 1280�1024
256 0�301 0�303 0�305 0�307
32k 0�310 0�313 0�316 0�319
64k 0�311 0�314 0�317 0x31A
16M 0�312 0�315 0�318 0x31B
Paul
J. P. Gilliver (John)
<gle...@spamindspring.com> writes:
[]
>Are you using XPSP3 Home or Pro Edition as the host OS?
>
>If you find the old Connectix version 5 does not do all you want, try
>the newer free version, Virtual PC 2007:
>http://www.microsoft.com/downloads/en/details.aspx?FamilyId=04D26402-319
>9-48A3-AFA2-2DC0B40A73B6&displaylang=en
>
That page says:
Supported Operating Systems:Windows Server 2003, Standard Edition
(32-bit x86);Windows Server 2003, Standard x64 Edition;Windows Vista
Business;Windows Vista Business 64-bit edition;Windows Vista
Enterprise;Windows Vista Enterprise 64-bit edition;Windows Vista
Ultimate;Windows Vista Ultimate 64-bit edition;Windows XP Professional
Edition;Windows XP Professional x64 Edition;Windows XP Tablet PC Edition
...
Virtual PC 2007 runs on: Windows Vista™ Business; Windows Vista™
Enterprise; Windows Vista™ Ultimate; Windows Server 2003, Standard
Edition; Windows Server 2003, Standard x64 Edition; Windows XP
Professional; Windows XP Professional x64 Edition; or Windows XP Tablet
PC Edition
under "System Requirements". It's not clear to me, but I think the first
list must be the OSs the virtual machine can run, and the second list
the host OSs it'll run under. But anyway, I see no mention of Home in
either list; are you saying it will and they're just not telling us?
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
freedom of speech is useless if nobody can hear you.
-- David Harris -- Author, Pegasus Mail Dunedin, May 2002.
glee
The second list are the operating systems you can install it on, as a
host machine. I have read elsewhere that it will install and run on XP
Home as well as Pro, but have never tried.
The first list is what operating systems are "supported" to be run as a
virtual system on the host. Other systems can be run....Win98, Linux,
etc...they are just not "supported" , meaning you won't get any help or
support for issues, there may not be Additions available for everything,
or there may only be partial functionality of the unsupported virtual
system.
Philo Pastry
> Maybe I'm forgetting something, but I seem to recall that as the
> partition size got bigger, the cluster size also HAD to get larger
> (up to 32K max) to keep the maximum allowable number of clusters
> within the max 16 bit value (65,536) for FAT32.
> So how could one possibly have 4 KB clusters on a 500 GB volume
> with FAT32?
You should read the following:
http://support.microsoft.com/kb/184006
It contains a mix of truth and fiction.
True:
-------------------
A FAT32-formatted volume *must* contain a minumum of 65,527 clusters.
That's the minimum value - not the max value.
The maximum possible number of clusters on a volume using the FAT32 file
system is 268,435,445. That would equate to a volume size of about
1.099 trillion bytes (1024 gb) using 4kb cluster size.
-------------------
False:
--------------------
You cannot decrease the cluster size on a volume using the FAT32 file
system so that the FAT ends up larger than 16 MB less 64 KB in size.
--------------------
Microsoft claims that the FAT can't exceed 16 mb in size, which equates
to about 4 million clusters given that the FAT uses 4 bytes per cluster.
They say that the FAT can't exceed 16 mb in size because the DOS version
of scandisk is a "16-bit" program that can't read more than 16 mb of
data into memory at once. I showed this was false several years ago by
having DOS scandisk process very large FAT32 volumes of various
configurations, including my 500 gb single-partition FAT32 volume which
had 120 million clusters (4kb cluster size) which would have had a FAT
size of over 450 mb.
Microsoft's statement that you can't end up with a FAT larger than 16 mb
is true - if they mean by using Microsoft's own software tools (like
format.com).
Microsoft's own FAT32 formatting tools are designed to keep the FAT size
at or under 16 mb, which means that a FAT32 volume should max out at 128
gb (32kb cluster size, 4.177 million total clusters). However,
Microsoft's fdisk and format.com will correctly create a FAT32 volume of
up to 512 gb - but not more. This results in about 16 million clusters.
glee
You can force the cluster size....it just means there is a ridiculously
large number of clusters on a drive that size, and among other things,
most drive tools will not work on a drive with that many clusters
(scandisk, defrag, drive diagnostic apps).
Philo Pastry
> You can force the cluster size....it just means there is a
> ridiculously large number of clusters on a drive that size,
> and among other things, most drive tools will not work on a
> drive with that many clusters (scandisk, defrag, drive
> diagnostic apps).
DOS scandisk has no problems scanning volumes with many millions of
clusters (120 million was the most I've tried and it worked).
Windows ME versions of defrag and scandisk (scandskw + diskmaint.dll)
have a cut-off somewhere around 28 to 32 million clusters. The Windows
ME versions of scandisk and defrag are frequently transplanted into
tweaked Win-98 installations.
MS-DOS version of Fdisk (may 2000 update) has a limit of 512 gb (that's
the largest drive that it can correctly partition). There is something
called "Free Fdisk" that can partition larger drives (at least 750 gb,
and probably up to 1 tb). MS-DOS format.com can format volumes of up to
1024 gb (1 tb).
John John - MVP
> "Bill in Co" <surly_cu...@earthlink.net> wrote in message
> news:8dydnYiCvMIcVybR...@earthlink.com...
>> glee wrote:
>>> "Bill in Co" <surly_cu...@earthlink.net> wrote in message
>>> news:iaSdnVxFUMN01CbR...@earthlink.com...
>>>> We could get into a debate on this, but with someone posing as "Philo
>>>> is wrong", one wonders if it would be worth it. Are you "98guy" in
>>>> disguise? :-)
>>>
>>> I'd say that's quite likely, if not outright obvious. A 500GB SATA
>>> drive as a single 4KB-cluster FAT32 partition, running Win98? Who else
>>> do we know that does this and recommends it? ;-)
>>
>> Maybe I'm forgetting something, but I seem to recall that as the
>> partition size got bigger, the cluster size also HAD to get larger (up
>> to 32K max) to keep the maximum allowable number of clusters within
>> the max 16 bit value (65,536) for FAT32. So how could one possibly
>> have 4 KB clusters on a 500 GB volume with FAT32?
>
> You can force the cluster size....it just means there is a ridiculously
> large number of clusters on a drive that size, and among other things,
> most drive tools will not work on a drive with that many clusters
> (scandisk, defrag, drive diagnostic apps).
Not to mention that it will result in a ridiculously big FAT of about
500MB! Anyone who understands how the FAT is read in a linear fashion
understands the folly of such a formatting scheme! This formatting
scheme effectively ensures that much the disk structure will be paged
out, what an incredible hit on disk performance! The disk is already
the single biggest performance bottleneck on any computer and this silly
formatting scheme will make it an even bigger bottleneck. Good thing
98Guy isn't handing out car advice, he would have us fill the bumpers
with lead while claiming that the added ballast makes cars go faster
while consuming less fuel...
John
John John - MVP
>> Additionally , since many people are now storing movies and such
>> with large files sizes, fat32 cannot handle any files over 4 gigs.
>
> While that is true, it rarely comes up as a realistic or practical
> limitation for FAT32. The most common multimedia format in common use
> is the DVD .VOB file, which self-limit themselves to be 1 gb.
People working with video editing and multimedia files often run across
this 4GB file limitations. Backup/imaging utilities also often run into
problems caused by this file size limitation, it is a very practical
limitation of FAT32 and one that users often experience, people often
post asking about this problem.
> The only file type that I ever see exceed the 4 gb size are virtual
> machine image files, which you will not see on a win-9x machine but you
> would see on an XP (or higher) PC running VM Ware, Microsoft Virtual PC,
> etc. But 4 gb should be enough to contain a modest image of a virtual
> windows-98 machine.
>
>> Additionally, XP is *deliberately* crippled in that it cannot create
>> a fat32 partition larger than 32 gigs.
Windows XP cannot format partitions larger than 32GB to FAT32 because
the increasing size of the FAT for bigger volumes makes these volumes
less efficient and for performance reasons Microsoft decided to draw the
line at 32GB for FAT32 volumes.
> [snip...]
>
> The extra sophistication and transaction journalling performed by NTFS
> reduces it's overall performance compared to FAT32. So for those who
> want to optimize the over-all speed of their PC's, FAT32 is a faster
> file system than NTFS.
That is not completely true. FAT32 is generally faster on smaller
volumes but on larger volumes NTFS is faster. This is why Microsoft
decided to put a limit of 32GB on the size of volumes which can be
formatted to FAT32 on Windows 2000 and later NT operating systems, the
size of the FAT on larger volumes is a hindrance on performance and
Microsoft decided that 32GB was an acceptable cut off point for FAT32
volumes.
>> I do a lot of computer repair work and have seen entire fat32
>> file systems hosed by a bad shut down. The user, in attempt to
>> fix things has typically run scandisk and *sometimes* has ended
>> up with a drive full of .chk files.
>
> That's another common myth about FAT32 - that the appearance of many
> .chk files must mean that it's inferior to NTFS.
>
> While it might look untidy, the mere existance of those .chk files don't
> mean anything about how compentent or capable FAT32 is, and it's not
> hard to just delete them and get on with your business.
>
> You did not say in your example if the user's drive and OS was operable
> and functional despite the existance of those .chk files.
These .chk files are lost file segments that the scandisk utility could
not recover, damaged data! That the operating system remains "operable"
is a laughable excuse if user data is lost! Open a user file on a FAT32
drive then while the user is making changes to his file yank the plug on
the machine and tell us how well (or not) the user data survives such an
event!
>> What I am saying is that NTFS is considerably more resilient.
>
> What you don't understand about NTFS is that it will silently delete
> user-data to restore it's own integrity as a way to cope with a failed
> transaction, while FAT32 will create lost or orphaned clusters that are
> recoverable but who's existance is not itself a liability to the user or
> the file system.
Citations please...
John
J. P. Gilliver (John)
<gle...@spamindspring.com> writes:
[]
>The second list are the operating systems you can install it on, as a
>host machine. I have read elsewhere that it will install and run on XP
>Home as well as Pro, but have never tried.
That's what I thought. (Anyone else know?)
>
>The first list is what operating systems are "supported" to be run as a
>virtual system on the host. Other systems can be run....Win98, Linux,
>etc...they are just not "supported" , meaning you won't get any help or
>support for issues, there may not be Additions available for
>everything, or there may only be partial functionality of the
>unsupported virtual system.
Yes, I thought so too (-:. [What's an "Addition" in this context?]
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
"The people here are more educated and intelligent. Even stupid people in
Britain are smarter than Americans." Madonna, in RT 30 June-6July 2001 (page
32)
Hot-Text
System Requirements
Supported Operating
Systems:Windows 2000 Service Pack 4
;Windows Server 2003,
Standard Edition (32-bit x86);
Windows XP Service Pack 2
Processor: Athlon®, Duron®, Celeron®, Pentium® II, Pentium III, or Pentium 4
Processor speed: 400 MHz minimum (1 GHz or higher recommended)
RAM: Add the RAM requirement for the host operating system that you will be
using
to the requirement for the guest operating system that you will be using.
If you will be using multiple guest operating systems simultaneously,
total the requirements for all the guest operating systems that you need to
run simultaneously.
Available disk space: To determine the hard disk space required,
add the requirement for each guest operating system that will be installed.
Virtual PC 2004 SP1 runs on:
Windows 2000 Professional SP4,
Windows XP Professional,
and Windows XP Tablet PC Edition.
Hot-Text
Philo Pastry
> > What you don't understand about NTFS is that it will silently
> > delete user-data to restore it's own integrity as a way to cope
> > with a failed transaction, while FAT32 will create lost or
> > orphaned clusters that are recoverable but who's existance is
> > not itself a liability to the user or the file system.
>
> Citations please...
http://cquirke.blogspot.com/2006/01/bad-file-system-or-incompetent-os.html
I'll repeat it below.
I'll be waiting for your response.
-------------------
14 January 2006
Bad File System or Incompetent OS?
"Use NTFS instead of FAT32, it's a better file system", goes the
knee-jerk. NTFS is a better file system, but not in a sense that every
norm in FAT32 has been improved; depending on how you use your PC and
what infrastructure you have, FATxx may still be a better choice. All
that is discussed here.
The assertion is often made that NTFS is "more robust" than FAT32, and
that FAT32 "always has errors and gets corrupted" in XP. There are two
apparent aspects to this; NTFS's transaction rollback capability, and
inherent file system robustness. But there's a third, hidden factor as
well.
Transaction Rollback
A blind spot is that the only thing expected to go wrong with file
systems is the interruption of sane write operations. All of the
strategies and defaults in Scandisk and ChkDsk/AutoChk (and automated
handling of "dirty" file system states) are based on this.
When sane file system writes are interrupted in FATxx, you are either
left with a length mismatch between FAT chaining and directory entry (in
which case the file data will be truncated) or a FAT chain that has no
directory entry (in which case the file data may be recovered as a "lost
cluster chain" .chk file). It's very rare that the FAT will be
mismatched (the benign "mismatched FAT", and the only case where blind
one-FAT-over-the-other is safe). After repair, you are left with a sane
file system, and the data you were writing is flagged and logged as
damaged (therefore repaired) and you know you should treat that data
with suspicion.
When sane file system writes are interrupted in NTFS, transaction
rollback "undoes" the operation. This assures file system sanity without
having to "repair" it (in essence, the repair is automated and hidden
from you). It also means that all data that was being written is
smoothly and seamlessly lost. The small print in the articles on
Transaction Rollback make it clear that only the metadata is preserved;
"user data" (i.e. the actual content of the file) is not preserved.
Inherent Robustness
What happens when other things cause file system corruption, such as
insane writes to disk structures, arbitrary sectors written to the wrong
addresses, physically unrecoverable bad sectors, unintentional power
interruptions, or malicious malware payloads a la Witty? (Witty worm,
March 2004). That is the true test of file system robustness, and
survivability pivots on four things; redundant information,
documentation, OS accessibility, and data recovery tools.
FATxx redundancy includes the comparison of file data length as defined
in directory entry vs. FAT cluster chaining, and the dual FATs to
protect chaining information that cannot be deduced should this
information be lost. Redundancy is required not only to guide repair,
but to detect errors in the first place - each cluster address should
appear only once within the FAT and collected directory entries, i.e.
each cluster should be part of the chain of one file or the start of the
data of one file, so it is easy to detect anomalies such as cross-links
and lost cluster chains.
NTFS redundancy isn't quite as clear-cut, extending as it does to
duplication of the first 5 records in the Master File Table (MFT). It's
not clear what redundancy there is for anything else, nor are there
tools that can harness this in a user-controlled way.
FATxx is a well-documented standard, and there are plenty of repair
tools available for it. It can be read from a large number of OSs, many
of which are safe for at-risk volumes, i.e. they will not initiate
writes to the at-risk volume of their own accord. Many OSs will tolerate
an utterly deranged FATxx volume simply because unless you initiate an
action on that volume, the OS will simply ignore it. Such OSs can be
used to safely platform your recovery tools, which include
interactively-controllable file system repair tools such as Scandisk.
NTFS is undocumented at the raw bytes level because it is proprietary
and subject to change. This is an unavoidable side-effect of deploying
OS features and security down into the file system (essential if such
security is to be effective), but it does make it hard for tools
vendors. There is no interactive NTFS repair tool such as Scandisk, and
what data recovery tools there are, are mainly of the "trust me, I'll do
it for you" kind. There's no equivalent of Norton DiskEdit, i.e. a raw
sector editor with an understanding of NTFS structure.
More to the point, accessibility is fragile with NTFS. Almost all OSs
depend on NTFS.SYS to access NTFS, whether these be XP (including Safe
Command Only), the bootable XP CD (including Recovery Console), Bart PE
CDR, MS WinPE, Linux that uses the "capture" approach to shelling
NTFS.SYS, or SystemInternals' "Pro" (writable) feeware NTFS drivers for
DOS mode and Win9x GUI.
This came to light when a particular NTFS volume started crashing
NTFS.SYS with STOP 0x24 errors in every context tested (I didn't test
Linux or feeware DOS/Win9x drivers). For starters, that makes ChkDsk
impossible to run, washing out MS's advice to "run ChkDsk /F" to fix the
issue, possible causes of which are sanguinely described as including
"too many files" and "too much file system fragmentation".
The only access I could acquire was BING (www.bootitng.com) to test the
file system as a side-effect of imaging it off and resizing it (it
passes with no errors), and two DOS mode tactics; the LFN-unaware
ReadNTFS utility that allows files and subtrees to be copied off, one at
a time, and full LFN access by loading first an LFN TSR, then the
freeware (read-only) NTFS TSR. Unfortunately, XCopy doesn't see LFNs via
the LFN TSR, and Odi's LFN Tools don't work through drivers such as the
NTFS TSR, so files had to be copied one directory level at a time.
FATxx concentrates all "raw" file system structure at the front of the
disk, making it possible to backup and drop in variations of this
structure while leaving file contents undisturbed. For example, if the
FATs are botched, you can drop in alternate FATs (i.e. using different
repair strategies) and copy off the data under each. It also means the
state of the file system can be snapshotted in quite a small footprint.
In contrast, NTFS sprawls its file system structure all over the place,
mixed in with the data space. This may remove the performance impact of
"back to base" head travel, but it means the whole volume has to be
raw-imaged off to preserve the file system state. This is one of several
compelling arguments in favor of small volumes, if planning for
survivability.
OS Competence
From reading the above, one wonders if NTFS really is more survivable or
robust that FATxx. One also wonders why NTFS advocates are having such
bad mileage with FATxx, given there's little inherent in the file system
structural design to account for this. The answer may lie here.
We know XP is incompetent in managing FAT32 volumes over 32G in size, in
that it is unable to format them. (see below). If you do trick XP into
formatting a volume larger than 32G as FAT32, it fails in the dirtiest,
most destructive way possible; it begins the format (thus irreversibly
clobbering whatever was there before), grinds away for ages, and then
dies with an error when it gets to 32G. This standard of coding is so
bad as to look like a deliberate attempt to create the impression that
FATxx is inherently "bad".
But try this on a FATxx volume; run ChkDsk on it from an XP command
prompt and see how long it takes, then right-click the volume and go
Properties, Tools and "check the file system for errors" and note how
long that takes. Yep, the second process is magically quick; so quick,
it may not even have time to recalculate free space (count all FAT
entries of zero) and compare that to the free space value cached in the
FAT32 boot record.
Now test what this implies; deliberately hand-craft errors in a FATxx
file system, do the right-click "check for errors", note that it finds
none, then get out to DOS mode and do a Scandisk and see what that
finds. Riiight... perhaps the reason FATxx "always has errors" in XP is
because XP's tools are too brain-dead to fix them?
My strategy has always been to build on FATxx rather than NTFS, and
retain a Win9x DOS mode as an alternate boot via Boot.ini - so when I
want to check and fix file system errors, I use DOS mode Scandisk,
rather than XP's AutoChk/ChkDsk (I suppress AutoChk). Maybe that's why
I'm not seeing the "FATxx always has errors" problem? Unfortunately, DOS
mode and Scandisk can't be trusted > 137G, so there's one more reason to
prefer small volumes.
---------------
While the author quite correctly observes the XP can't format a FAT32
volume larger than 32gb, it's been my experience that when a FAT32
volume (or drive) of any size is pre-formatted and then presented to XP,
that XP has no problems mounting and using the volume / drive, and XP
can even be installed on and operate from such a volume / drive.
The author also mentions the 137 gb volume size issue that is associated
with FAT32, but that association is false. It originates from the fact
that the 32-bit protected mode driver (ESDI_506.PDR) used by win-98 has
a "flaw" that prevents it from correctly addressing sectors beyond the
137 gb point on the drive. There are several work-around for this
(third party replacement for that driver, the use of SATA raid mode,
etc) but that issue is relavent only to win-98 and how it handles large
FAT32 volumes, not how XP handles large FAT32 volumes.
John John - MVP
> John John - MVP wrote:
>
>>> What you don't understand about NTFS is that it will silently
>>> delete user-data to restore it's own integrity as a way to cope
>>> with a failed transaction, while FAT32 will create lost or
>>> orphaned clusters that are recoverable but who's existance is
>>> not itself a liability to the user or the file system.
>>
>> Citations please...
>
> http://cquirke.blogspot.com/2006/01/bad-file-system-or-incompetent-os.html
>
> I'll repeat it below.
... Snip the long stuff.
How absurd, it appears that some don't understand file system atomicity!
John
Buffalo
Philo Surrenders wrote:
> philo top-poasted:
>
>>> I have probably over 200 years worth of FAT32 hard-drive usage
>>> experience
>
> This is how Philo surrenders an argument. Watch:
>
>> 200 years of experience...
>> ok you win, my computer experience only goes back to 1968.
>
> Because he didn't quote the rest of my statement:
>
>>> (if you add up all the years of service of various FAT32
>>> drives that I've installed, maintained, touched in one way
>>> or another, etc) over the past dozen years.
How stupid!!
You truely should just keep quiet and leave with any dignity that may
possibly remain.
Buffalo
Philo Pastry
>>> Citations please...
>>
>>http://cquirke.blogspot.com/2006/01/bad-file-system-or-incompetent-os.html
>>
>> I'll repeat it below.
>
> How absurd, it appears that some don't understand file system
> atomicity!
And with your arm-waving dismissal, you concede the debate and surrender
your position.
Don't think that other people don't notice how you just baled out of
this argument.
Atomicity does not equal superiority, btw.
If you had any real insight into this issue or a defendable position you
would counter the points that Quirke makes, one by one. But you have
neither.
Philo Pastry
> People working with video editing and multimedia files often run
> across this 4GB file limitations. Backup/imaging utilities also
> often run into problems caused by this file size limitation,
About 3 years ago I installed XP on a 250 gb FAT-32 partitioned hard
drive and installed Adobe Premier CS3. It had no problems creating
large video files that spanned the 4 gb file-size limit of FAT32.
> Windows XP cannot format partitions larger than 32GB to FAT32
> because the increasing size of the FAT for bigger volumes makes
> these volumes less efficient (bla bla bla)
Other than saying that this behavior was "by design", Microsoft has
never said *why* they gave the NT line of OS's the handicap of not being
able to create FAT32 volumes larger than 32 gb.
It's a fallacy that the entire FAT must be loaded into memory by any OS
(win-9x/XP, etc) for the OS to access the volume.
Go ahead and cite some performance statistics that show that performance
of random-size file read/write operations go down as the FAT size (# of
clusters) goes up.
Remember, we are not talking about cluster size here. FAT32 cluster
size (and hence small file storage efficiency) can be exactly the same
as NTFS regardless the size of the volume.
John John - MVP
You don't understand a thing that Chris wrote about in his blog!
Let's address your blatant lie:
"What you don't understand about NTFS is that it will silently delete
user-data to restore it's own integrity as a way to cope with a failed
transaction..."
It is you who doesn't understand anything about how NTFS works so you
spread lies and nonsence! NTFS DOES NOT silently delete user data to
replace it to restore it's own integrity and C. Quirke does not in
anyway say that in his blog. What is being described is journaling and
it is perfectly normal NTFS behaviour, this journaling ensures atomicity
of the write operations. You on the other hand seem to think that it is
preferable to have the file system keep incomplete or corrupt write
operations and then have scandisk run at boot time so that it may /try/
to recover lost clusters or so that it may save damaged file segments in
.chk files so that you may then /try/ to fix the file. There is no
saying if one of the segments pieced together by scandisk doesn't
contain zeros to make up for the data that was lost in the segment
during the failed write operation, Chris mentions in his blog how data
which was recovered by Scandisk should be treated as suspicious. The
NTFS method is to use journaling instead to guarantee atomicity of the
write operation, to guarantee that the write is complete and free of
errors. I prefer the later and I am sure that most reading here would
prefer to keep the previous good version of the file that experienced a
write failure rather than have a the file system keep a newer copy of
the file when it is incomplete or corrupt! Keeping the older version of
a file when atomicity cannot be guaranteed is not silently deleting
user-data to so that NTFS can restore it's own integrity, it's a way of
ensuring the integrity of the user data rather than saving garbage!
John
mm
<G6...@soft255.demon.co.uk> wrote:
>In message <en5kb6pi2echl4pej...@4ax.com>, mm
><NOPSAM...@bigfoot.com> writes:
>>On Sat, 16 Oct 2010 07:16:58 -0500, philo <ph...@privacy.net> wrote:
>>
>>>On 10/16/2010 12:33 AM, mm wrote:
>>>> Hi! I"m moving to a new machine that probably won't run win98, so I
>>>> planned to run it from a Virtual Machine under winxpsp3
>>>>
>>>> Is it okay to have all the harddrive partitions NTFS, even though
>>>> win98 can't normally read NTFS?
>>>>
>>>
>>>
>>>
>>>It should work just fine.
>>>
>>>If there are any problems they will not be due to the drive being NTFS
>>>at any rate
>>
>>Great, thank you. Now I have all the parts to fix up my friends old
>>2.4 gig Dell for myself. I think I'll like the increased speed.
>>>
>>><snip>
>>
>If you're actually starting from scratch (which "have all the parts"
>suggests to me that you are) anyway, received wisdom here seems to be
I had everything but the harddrive, so yeah, I'm starting from scratch
on that. Thanks. There is a lot of thread to read. Been very busy,
but I'll have time soon, I think. I plan to get back to you.
>that you should set it up as FAT anyway: the alleged benefits of NTFS
>being largely moot for the single home user, and XP will operate
>perfectly happily under FAT.
John John - MVP
> John John - MVP wrote:
>
>> People working with video editing and multimedia files often run
>> across this 4GB file limitations. Backup/imaging utilities also
>> often run into problems caused by this file size limitation,
>
> About 3 years ago I installed XP on a 250 gb FAT-32 partitioned hard
> drive and installed Adobe Premier CS3. It had no problems creating
> large video files that spanned the 4 gb file-size limit of FAT32.
>
>> Windows XP cannot format partitions larger than 32GB to FAT32
>> because the increasing size of the FAT for bigger volumes makes
>> these volumes less efficient (bla bla bla)
>
> Other than saying that this behavior was "by design", Microsoft has
> never said *why* they gave the NT line of OS's the handicap of not being
> able to create FAT32 volumes larger than 32 gb.
Raymond Chen talks about this here:
Windows Confidential A Brief and Incomplete History of FAT32
http://technet.microsoft.com/en-us/magazine/2006.07.windowsconfidential.aspx
>
> It's a fallacy that the entire FAT must be loaded into memory by any OS
> (win-9x/XP, etc) for the OS to access the volume.
Of course it's a fallacy and no one here said that the entire FAT had to
be loaded in memory, what you don't understand is that the FAT is
extensively accessed during disk operations and having it cached in the
RAM is one of the most efficient methods of speeding up disk operations.
You on the other hand seem to think that having the FAT as large as
possible and then page it to disk is a smart thing to do... Why else
would anyone format a 500gb FAT32 volume with 4K clusters? What exactly
do you think that you will gain with this formatting scheme that will be
so great as to dismiss the whopping performance hit provided by a 500MB FAT?
John
Bill in Co
The idea of a having a super large, 500MB FAT, (that often has to be
accessed sequentially, instead of in a B-tree), I find *wholly* repugnant!!
Bill in Co
I well remember those stupid (and almost completely useless) .CHK files. I
don't think I ever found them to be of any real value in real file recovery.
The only "value" I found for them (and I use that term "value" rather
loosely, here), was that you could look at some of them (with QuickView or
whatever) just to see some text entries that possibly got lost or damaged in
some file when this happened. If the tradeoff is between having those .CHK
files (which are essentially useless) , or a more robust NTFS with file
journaling, I'll take the latter.
Philo Pastry
> Let's address your blatant lie:
>
> "What you don't understand about NTFS is that it will silently
> delete user-data to restore it's own integrity as a way to cope
> with a failed transaction..."
>
> It is you who doesn't understand anything about how NTFS works
> so you spread lies and nonsence! NTFS DOES NOT silently delete
> user data to replace it to restore it's own integrity and
> C. Quirke does not in anyway say that in his blog.
Perhaps you have a reading comprehension problem.
This is what Quirk says, and what I've experienced first-hand when I see
IIS log file data being wiped away because of power failures:
-----------
It also means that all data that was being written is smoothly and
seamlessly lost. The small print in the articles on Transaction Rollback
make it clear that only the metadata is preserved; "user data" (i.e. the
actual content of the file) is not preserved.
-----------
Do you understand the difference between metadata and "user data" ?
> What is being described is journaling and it is perfectly normal
> NTFS behaviour, this journaling ensures atomicity of the write
> operations.
Journalling ensures the *complete-ness* of write operations. Partially
completed writes are rolled back to their last complete state. That can
mean that user-data is lost.
> You on the other hand seem to think that it is preferable to
> have the file system keep incomplete or corrupt write operations
> and then have scandisk run at boot time so that it may /try/
> to recover lost clusters or so that it may save damaged file
> segments
In my experience, drive reliability, internal caching and bad-sector
re-mapping have made most of what NTFS does redundant.
The odd thing is - I don't believe I've ever had to resort to scouring
through .chk files for data that was actually part of any sort of user
file that was corrupted. Any time I've come across .chk files, I've
never actually had any use for them.
And I can tell you that I would really be pissed off if I was working on
a file on an NTFS system and it suffered a power failure or some other
sort of interruption and my file got journalled back to some earlier
state just because the file system didn't fully journal it's present
state or last write operation.
I've seen too many examples of NT-server log files that contain actual
and up-to-date data one hour, and because of a power failure the system
comes back up and half the stuff that *was* in the log file is gone.
That's an example of meta-data being preserved at the sake of user data.
> Chris mentions in his blog how data which was recovered by
> Scandisk should be treated as suspicious.
Recovered - as in the creation of .chk files? Like I said, I've never
had a use for them in the first place.
> The NTFS method is to use journaling instead to guarantee
> atomicity of the write operation, to guarantee that the write
> is complete and free of errors.
No. You can still have erroneous write operations under NTFS and FATxx,
and the OS is supposed to retry the operation until the write succeeds.
If the write occurs during a system crash or power failure, there can be
no re-try. Journalling is meant to detect an erroneous write event that
was never corrected / completed and restore the file system to the
previous state before the event, even if some (or most, or all) user
data was in fact written to the drive prior to the failure but was not
journaled. That's where FAT32 will retain the user data, but it will be
lost under NTFS.
And as Quirke says, under FAT you can have a mis-match between the
file-size as recorded in the FAT vs the length of the file-chain, and
for which is easily fixable.
He talks a lot more about the relative complexity of the actual
structure of NTFS compared to FAT32, the lack of proper documentation,
of diagnostic and repair tools, and the idea that the MFT may not be as
recoverable or redundant as the dual FATs of FAT32.
What is especially interesting is that a faulty FAT32 volume can be
mounted and inspected with confidence that it won't be immediately
"attacked" by unknown or uncontrolled read/write operations during it's
mounting as a faulty NTFS volume would be by NTFS.SYS. You basically
have to trust that NTFS.SYS knows what it's doing, and that it knows
best how to recover a faulty NTFS volume, and if it places more value on
file recovery vs file-system integrity (there is a huge difference
between the two).
> I prefer the later and I am sure that most reading here would
> prefer to keep the previous good version of the file that
> experienced a write failure rather than have a the file system
> keep a newer copy of the file when it is incomplete or corrupt!
That depends on how large your "atoms" are in your "atomicity" analogy.
I have been burned and shake my head many times because I've seen data
lost on NTFS volumes because of the interplay between journalling and
write-caching after unexpected system shutdown events.
NTFS is more than journalling. There's the organizational structure or
pattern as to how you store files and directories, and there's the event
or transaction-monitoring and logging operations above that. You could
theoretically have journalling performed on a FAT32 file structure.
But like I said, NTFS is more convoluted and secretive than it needs to
be in the way it stores files on a drive (journalling or no
journalling).
Philo Pastry
> > Other than saying that this behavior was "by design", Microsoft
> > has never said *why* they gave the NT line of OS's the handicap
> > of not being able to create FAT32 volumes larger than 32 gb.
>
> Raymond Chen talks about this here:
>
> Windows Confidential A Brief and Incomplete History of FAT32
=============
For a 32GB FAT32 drive, it takes 4 megabytes of disk I/O to compute the
amount of free space.
============
You do realize how trivial a 4 mb data transfer is, today and even 5, 10
years ago - don't you?
Chen doesn't mention any other file or drive operation as being impacted
by having a large cluster count other than the computation of free space
- which I believe is infrequently performed anyways.
I formatted a 500 gb drive as a single FAT32 volume using 4kb cluser
size just as an excercise to test if Windows 98se could be installed and
function on such a volume, and it did - with the exception that it would
not create a swap file on such a volume.
And as Chen mentions, yes - the *first* directory command on FAT32
volumes with a high cluster-count does take a few minutes (but not
successive directory commands). What I found in my testing that either
in DOS or under Win-98, that the first dir command (or explorer-view) is
instantaneous as long as the number of clusters doesn't exceed 6.3
million. This equates to a FAT size of about 25 mb.
I have installed win-98 on FAT32 volumes of various sizes, formatted
with a range of cluster sizes from 4kb to 32kb resulting in volumes
ranging from 6 to 40 million clusters and have seen no evidence of a
performance hit during file manipulations, copying, searching, etc.
> You on the other hand seem to think that having the FAT as
> large as possible and then page it to disk is a smart thing
> to do...
Other than the first dir command or first explorer session, I have seen
no performance hit under win-9x or even under XP when installed on FAT32
volumes with large FATs.
Hot-Text
my file system!
and Windows 98 is like a old man instead more then FAT32, will be to Big
and all the oil in the world will not make his file system run right!
"Philo Pastry" John John - MVP Win The Debate Hands Down so give up!
Hot-Text
Bill in Co
> John John - MVP wrote:
>
>>> Other than saying that this behavior was "by design", Microsoft
>>> has never said *why* they gave the NT line of OS's the handicap
>>> of not being able to create FAT32 volumes larger than 32 gb.
>>
>> Raymond Chen talks about this here:
>>
>> Windows Confidential A Brief and Incomplete History of FAT32
>
> =============
> For a 32GB FAT32 drive, it takes 4 megabytes of disk I/O to compute the
> amount of free space.
> ============
>
> You do realize how trivial a 4 mb data transfer is, today and even 5, 10
> years ago - don't you?
>
> Chen doesn't mention any other file or drive operation as being impacted
> by having a large cluster count other than the computation of free space
> - which I believe is infrequently performed anyways.
>
> I formatted a 500 gb drive as a single FAT32 volume using 4kb cluser
> size just as an excercise to test if Windows 98se could be installed and
> function on such a volume, and it did - with the exception that it would
> not create a swap file on such a volume.
Well, that's really nice. No swap file? Great. (Plus the other utilities
you said that won't work anymore (like the much faster version of Defrag
from WinME).
> And as Chen mentions, yes - the *first* directory command on FAT32
> volumes with a high cluster-count does take a few minutes (but not
> successive directory commands).
A few *minutes*???? Are you kidding me??? THAT is totally unacceptible.
I get annoyed when XP takes 5 seconds to initially display something that
should be near instantaneous.
With all the things you've mentioned it sure seems like there is a price to
pay. Oh yeah, not the least of which is you can't *ever* have a file
larger than 4 GB (this can be a pit of a PIA for some photo, video, and disk
imaging work)
(All that being said, I do miss the ability to boot up into DOS, if I ever
want to or had to. But that's about the only thing) Well, actually I
can still boot into DOS on my thumb drive, but it's not quite the same thing
as having the good ole DOS fallback option).
> What I found in my testing that either
> in DOS or under Win-98, that the first dir command (or explorer-view) is
> instantaneous as long as the number of clusters doesn't exceed 6.3
> million. This equates to a FAT size of about 25 mb.
Which is a LONG ways from the 500 MB mentioned.
Sunny
"Philo Pastry" <w...@com.com> wrote in message
news:4CBCFBDC...@com.com...
> John John - MVP wrote:
>
>> People working with video editing and multimedia files often run
>> across this 4GB file limitations. Backup/imaging utilities also
>> often run into problems caused by this file size limitation,
>
> About 3 years ago I installed XP on a 250 gb FAT-32 partitioned hard
> drive and installed Adobe Premier CS3. It had no problems creating
> large video files that spanned the 4 gb file-size limit of FAT32.
OK, explain how I get (Using Acronis True Image Backup)
"The incremental backup will exceed the 4Gb limit in your backup file
location"
After I raised a new backup location on a NTFS partion I never get the
above warning.
Hot-Text
"Philo Pastry" <w...@com.com> wrote in message
news:4CBCFBDC...@com.com...
> About 3 years ago I installed XP on a 250 gb FAT-32 partitioned hard
> drive and installed Adobe Premier CS3. It had no problems creating
> large video files that spanned the 4 gb file-size limit of FAT32.
XP install <Hmm that can not be right
it have to be a NTFS for a 250 gb to install
or you do not partition all the Hard Drive
Now I have to see this
Make a Screen Capture
And post it to http://mynews.ath.cx/doc/phUploader.php
Here my Screen Capture
http://mynews.ath.cx/doc/uploads/ntfs.jpg
mm
<Ph...@is.wrong.com> wrote:
>
>What you don't understand about NTFS is that it will silently delete
>user-data to restore it's own integrity as a way to cope with a failed
>transaction, while FAT32 will create lost or orphaned clusters that are
>recoverable but who's existance is not itself a liability to the user or
>the file system.
I'll say this. At first when win98FE crashed, I would find files that
were missing, whole mailboxes of my email program iirc. I would do
chkdsk and in the chk files I would find much of the data that was
missing. At the least I could search it for lost info, and maybe I
was able to rename the files to the original names, even if there was
garbage (prior data) at the end of the cluster or whatever.
I wondered why there was nothing in Windows, afaik, like there is in
mainframes. When one copies a 1000 byte file to a 100 byte file in an
IBM mainframe with languages like Cobol, it gives a 100 byte result,
with the other 900 truncated. That's what I wanted to do here, but I
couldn't find a way to do it.
>> The thing some people find convenient about fat32 is that the
>> system can easily be accessed by a win98 boot floppy.
>
>Or, if you've installed DOS first on an FAT32 drive, and then install XP
>as a second OS, you can have a choice at boot-up to run DOS or XP.
Why not just put all the dos files in the XP partition, and use a dos
boot disk to boot to that? Like with win98. There aren't many DOS
files, and none that I know of will used by XP. Nor will DOS have to
use any XP files, except when trying to fix things.
>> However an NTFS drive can still be accessed from the repair
>> console...
>
>The repair console is garbage and does not compare in any way to the
>utility and capability of a real DOS-type command environment.
I've used it for fixboot and fixmbr, but I thought the set of commands
was small, and I read they don't work in the same way dos commands do.
But I still haven't read most of this thread or formed any
conclusions.
mm
wrote:
>"mm" <NOPSAM...@bigfoot.com> wrote in message
>news:en5kb6pi2echl4pej...@4ax.com...
>> On Sat, 16 Oct 2010 07:16:58 -0500, philo <ph...@privacy.net> wrote:
>>
>>>On 10/16/2010 12:33 AM, mm wrote:
>>>> Hi! I"m moving to a new machine that probably won't run win98, so I
>>>> planned to run it from a Virtual Machine under winxpsp3
>>>>
>>>> Is it okay to have all the harddrive partitions NTFS, even though
>>>> win98 can't normally read NTFS?
>>>>
>>>
>>>
>>>
>>>It should work just fine.
>>>
>>>If there are any problems they will not be due to the drive being NTFS
>>>at any rate
>>
>> Great, thank you. Now I have all the parts to fix up my friends old
>> 2.4 gig Dell for myself. I think I'll like the increased speed.
>>>
>>><snip>
>
>Are you using XPSP3 Home or Pro Edition as the host OS?
Pro, it appears. That was what was on this DELL before the HD failed
and he gave me the computer and the CD's that came with it.
>
>If you find the old Connectix version 5 does not do all you want, try
>the newer free version, Virtual PC 2007:
>http://www.microsoft.com/downloads/en/details.aspx?FamilyId=04D26402-3199-48A3-AFA2-2DC0B40A73B6&displaylang=en
I would rather have newer! Thanks.
I read, probably in the wikip entry for this, that it was free for a
while after MS bought it, but it also gavem me the impression it
wasn't anymore. No time now to go reread it. I'm happy to have the
new version.
Thanks.
mm
wrote:
>"J. P. Gilliver (John)" <G6...@soft255.demon.co.uk> wrote in message
>news:Vm8RqvoKV$uMF...@soft255.demon.co.uk...
>> In message <i9evqu$c01$1...@speranza.aioe.org>, glee
>> <gle...@spamindspring.com> writes:
>> []
>>>Are you using XPSP3 Home or Pro Edition as the host OS?
>>>
>>>If you find the old Connectix version 5 does not do all you want, try
>>>the newer free version, Virtual PC 2007:
>>>http://www.microsoft.com/downloads/en/details.aspx?FamilyId=04D26402-319
>>>9-48A3-AFA2-2DC0B40A73B6&displaylang=en
>>>
>> Thanks for the link.
>>
>> That page says:
>>
>> Supported Operating Systems:Windows Server 2003, Standard Edition
>> (32-bit x86);Windows Server 2003, Standard x64 Edition;Windows Vista
>> Business;Windows Vista Business 64-bit edition;Windows Vista
>> Enterprise;Windows Vista Enterprise 64-bit edition;Windows Vista
>> Ultimate;Windows Vista Ultimate 64-bit edition;Windows XP Professional
>> Edition;Windows XP Professional x64 Edition;Windows XP Tablet PC
>> Edition
>>
>> ...
>>
>> Virtual PC 2007 runs on: Windows Vista� Business; Windows Vista�
>> Enterprise; Windows Vista� Ultimate; Windows Server 2003, Standard
>> Edition; Windows Server 2003, Standard x64 Edition; Windows XP
>> Professional; Windows XP Professional x64 Edition; or Windows XP
>> Tablet PC Edition
>>
>> under "System Requirements". It's not clear to me, but I think the
>> first list must be the OSs the virtual machine can run, and the second
>> list the host OSs it'll run under. But anyway, I see no mention of
>> Home in either list; are you saying it will and they're just not
>> telling us?
>
>The second list are the operating systems you can install it on, as a
>host machine. I have read elsewhere that it will install and run on XP
>Home as well as Pro, but have never tried.
>
>The first list is what operating systems are "supported" to be run as a
>virtual system on the host. Other systems can be run....Win98, Linux,
>etc...they are just not "supported" , meaning you won't get any help or
>support for issues, there may not be Additions available for everything,
>or there may only be partial functionality of the unsupported virtual
>system.
The version I bought, albeit for 3 dollars, Connectix Virtual PC for
Windows version 5, says on the box that it allows as a guest system
DOS, 3.1, ....up to XP home and pro, Linux, Netware, OS/2 and Solaris
8.
It doesn't say anything about supporting them or not, and I figure
that's because Connectix was not an MS company and there was no reason
to think it could support OSes.
But MS has to disclaim support for OSes it no longer supports, or some
crank will sue them, they fear.
As to Host OSes, it lists 2000, NT 4, ME, 98SE, XP Home and XP Pro.
Of course they could have removed functionality, perhaps for very good
reason in V. PC 2007. It might be years before I actually try this,
since I plan to keep the old win98/xp computer in my basement.
Hopefully win98 will work by then. :)
mm
>On Sat, 16 Oct 2010 01:33:28 -0400, mm <NOPSAM...@bigfoot.com>
>wrote:
>
>>Hi! I"m moving to a new machine that probably won't run win98, so I
>>planned to run it from a Virtual Machine under winxpsp3
>>
>>Is it okay to have all the harddrive partitions NTFS, even though
>>win98 can't normally read NTFS?
>>
>>Thanks
>>
>>
>>Much Less important:
>>Is Connectix Virtual PC for Windows, version 5, okay? Or is it
>>obsolete by now. It lists XP on the box, but I wonder if it will have
>>USB support with version 5.
>
>
>Use FAT. Why use NTFS for ANYTHING? If you encounter an error on a
>FAT partition, you can retrieve everything unless the hard drive
>itself fails. If you crash a NTFS partition, kill ALL your data
>goodbye, because there is no way to retrieve anything.
>
>Heck, on a FAT partition, you can just stick in a DOS bootdisk and
>access all your data. Why make life complicated when there is no
>advantage whatsoever to using NTFS.
You know, until just now, I figured there was something like DOS to
access NTFS partitions. It never occurred to me that there wouldn't
be.
Thanks.
> Even if your drive access is a
>tiny bit faster with NTFS, is this worth losing everything? I always
>tell people who format NTFS that they damn well better backup their
>hard drive at least twice every hour, because if a NTFS installation
>fails, IT'S OVER.....
Bill in Co
> On Tue, 19 Oct 2010 02:39:08 -0500, j...@myplace.com wrote:
>
>> On Sat, 16 Oct 2010 01:33:28 -0400, mm <NOPSAM...@bigfoot.com>
>> wrote:
>>
>>> Hi! I"m moving to a new machine that probably won't run win98, so I
>>> planned to run it from a Virtual Machine under winxpsp3
>>>
>>> Is it okay to have all the harddrive partitions NTFS, even though
>>> win98 can't normally read NTFS?
>>>
>>> Thanks
>>>
>>>
>>> Much Less important:
>>> Is Connectix Virtual PC for Windows, version 5, okay? Or is it
>>> obsolete by now. It lists XP on the box, but I wonder if it will have
>>> USB support with version 5.
>>
>>
>> Use FAT. Why use NTFS for ANYTHING? If you encounter an error on a
>> FAT partition, you can retrieve everything unless the hard drive
>> itself fails. If you crash a NTFS partition, kill ALL your data
>> goodbye, because there is no way to retrieve anything.
<rubbish>
>> Heck, on a FAT partition, you can just stick in a DOS bootdisk and
>> access all your data.
Well, at least that statement is true.
>> Why make life complicated when there is no
>> advantage whatsoever to using NTFS.
<sigh> <ignorance is bliss>
> You know, until just now, I figured there was something like DOS to
> access NTFS partitions.
And there is.
> It never occurred to me that there wouldn't be.
>
> Thanks.
In fact, there ARE such utilities. NTFS4DOS, Bart's Boot CD, etc, come to
mind. Research 101. :-)
@nomail.afraid.org FromTheRafters
> You know, until just now, I figured there was something like DOS to
> access NTFS partitions. It never occurred to me that there wouldn't
> be.
While XP's recovery console was severely crippled, it is not so for Vista's
or Windows 7's - and there is also support for NTFS in Linux.
John John - MVP
> John John - MVP wrote:
>
>> Let's address your blatant lie:
>>
>> "What you don't understand about NTFS is that it will silently
>> delete user-data to restore it's own integrity as a way to cope
>> with a failed transaction..."
>>
>> It is you who doesn't understand anything about how NTFS works
>> so you spread lies and nonsence! NTFS DOES NOT silently delete
>> user data to replace it to restore it's own integrity and
>> C. Quirke does not in anyway say that in his blog.
>
> Perhaps you have a reading comprehension problem.
>
> This is what Quirk says, and what I've experienced first-hand when I see
> IIS log file data being wiped away because of power failures:
>
> -----------
> It also means that all data that was being written is smoothly and
> seamlessly lost. The small print in the articles on Transaction Rollback
> make it clear that only the metadata is preserved; "user data" (i.e. the
> actual content of the file) is not preserved.
> -----------
You REALLY don't understand anything! What Chris is saying is that when
writes are interrupted the *NEW* data being written is not kept, not
that what is *already* on the disk (flushed) is discarded or in anyway
deleted! Listen, most of us who have been using NTFS have at one time
or another experienced glitches, crashes or unprotected power failures
while working with files, with NTFS when the computer is rebooted most
of the time it's like nothing happened at all, you might have lost the
work that was being saved at the time of the crash but the file itself
and what was successfully saved and flushed while working will still be
stored on the disk and will still be intact, don't try to lie and twist
the facts, everyone reading here will see right through your lies! Your
statement that NTFS silently deletes user-data to restore it's own
integrity was made in ignorance and to make readers think that any and
all of their files are at risk as NTFS will modify their user data, the
false statement even gives the impression that this will even happen on
files that are not being used.
> Do you understand the difference between metadata and "user data" ?
Oh please, don't try to be smart and to obfuscate the issue by trying to
bring in things that will only end up biting you in the a$$! If you are
so smart about metadata you should already know that some of it is user
defined or user owned! Or do you think that the file system should
sacrifice critical system metadata and risk corrupting the MFT in order
to try save user data which was damaged or lost during a write
operation? Are you saying that the file system should not first and
foremost attempt to guarantee the integrity of of the file system
structure and the safe keeping of all the files on the disk at the
expense of one user file when glitches and failures occur?
>> What is being described is journaling and it is perfectly normal
>> NTFS behaviour, this journaling ensures atomicity of the write
>> operations.
>
> Journalling ensures the *complete-ness* of write operations. Partially
> completed writes are rolled back to their last complete state. That can
> mean that user-data is lost.
It means that the incomplete write was not flushed to the disk and that
the old version of the file will not be updated, what will be lost will
be what was in the RAM when the file system was attempting to commit and
flush it to the disk!
>> You on the other hand seem to think that it is preferable to
>> have the file system keep incomplete or corrupt write operations
>> and then have scandisk run at boot time so that it may /try/
>> to recover lost clusters or so that it may save damaged file
>> segments
>
> In my experience, drive reliability, internal caching and bad-sector
> re-mapping have made most of what NTFS does redundant.
>
> The odd thing is - I don't believe I've ever had to resort to scouring
> through .chk files for data that was actually part of any sort of user
> file that was corrupted. Any time I've come across .chk files, I've
> never actually had any use for them.
>
> And I can tell you that I would really be pissed off if I was working on
> a file on an NTFS system and it suffered a power failure or some other
> sort of interruption and my file got journalled back to some earlier
> state just because the file system didn't fully journal it's present
> state or last write operation.
You still don't understand, the last successful write will be present,
what was successfully saved and flushed while you were working with the
file will be intact.
> I've seen too many examples of NT-server log files that contain actual
> and up-to-date data one hour, and because of a power failure the system
> comes back up and half the stuff that *was* in the log file is gone.
> That's an example of meta-data being preserved at the sake of user data.
You're lying again and the above statement proves beyond the shadow of a
doubt that you have absolutely no experience whatsoever on NT server
systems!
Look, no one is saying that everything NTFS is perfect and that data
loss never occurs with NTFS, that is why smart computer users keep
backups! On the other hand stop lying about things you know nothing of
and stop trying to make us believe that FAT32 is more robust than NTFS,
those who have real life experience know better. FAT32 has some
advantages in certain situations and NTFS has advantages in other
situations, by and large in today's computing environment for most users
the advantages offered by NTFS far outweigh those offered by FAT32.
John
Philo Pastry
> OK, explain how I get (Using Acronis True Image Backup)
> "The incremental backup will exceed the 4Gb limit in your
> backup file location"
Simple. Acronis doesn't have the brains to split it's backup files into
4 gb chunks. Which is a useful feature the user might want even if it
was being written to an NTFS volume.
Philo Pastry
> > I formatted a 500 gb drive as a single FAT32 volume using 4kb
> > cluser size just as an excercise to test if Windows 98se could
> > be installed and function on such a volume, and it did - with
> > the exception that it would not create a swap file on such a
> > volume.
>
> Well, that's really nice. No swap file? Great.
I created a swap file on a second hard drive that had a smaller-sized
volume.
> (Plus the other utilities you said that won't work anymore
> (like the much faster version of Defrag from WinME).
Those utilities will work on volumes that have around 25 to 30 million
clusters. Again, this far exceeds the upper limit of 4.2 million that
microsoft claimed was the max number of clusters for a FAT32 volume.
> > And as Chen mentions, yes - the *first* directory command
> > on FAT32 volumes with a high cluster-count does take a few
> > minutes (but not successive directory commands).
>
> A few *minutes*???? Are you kidding me???
> THAT is totally unacceptible.
Sure, but that's if you've booted the machine into DOS.
I really don't remember if it took that long to view the drive in
explorer under win-98 or not, and there is no such delay to view the
drive under XP. So the delay is not so much the fault of the file
system as it is the overlying OS and the strategy it uses to compute
free space - and whether or not it has to compute free space each and
every time the drive is viewed, or whether it can save that info
somewhere on the drive without having to recompute it periodically.
> With all the things you've mentioned it sure seems like there is
> a price to pay.
When it comes to running XP on a FAT32 drive, the only price is a max
file size of 4 gb. The benefits are a more accessible and portable file
system, more third-party tools and utilities, faster performance,
arguably better / simpler data recoverability (and I don't mean the
creation of .chk files when I say that).
> Oh yeah, not the least of which is you can't *ever* have a file
> larger than 4 GB (this can be a pit of a PIA for some photo,
> video, and disk imaging work)
Like I said earlier, I've seen Adobe Premier CS3 on an XP system running
on a FAT32 drive create large video files by segmenting the output
across multiple 4 gb files automatically.
> > What I found in my testing that either in DOS or under Win-98,
> > that the first dir command (or explorer-view) is instantaneous
> > as long as the number of clusters doesn't exceed 6.3 million.
> > This equates to a FAT size of about 25 mb.
>
> Which is a LONG ways from the 500 MB mentioned.
6.3 million clusters, at 32 kb each, results in a 200 gb volume, which
isin't a LONG way from 500 gb.
If you want the first DOS dir command to be instantaneous, limit the
number of clusters to be 6.3 million (max volume size = 200 gb, 32kb
cluster size). If you can tolerate the first dir to be up to several
minutes, then DOS is compatible with many millions of clusters on a
FAT32 drive - at least 120 million.
If running win-98 and you want all your tools and diagnostic programs to
run, limit the number of clusters to 30 million (max volume size = 980
gb, 32 kb cluster size).
If running XP, I'm not aware of any limit to the number of clusters
affecting the performance of the volume or latency of any drive
operation.
John John - MVP
>
>> People working with video editing and multimedia files often run
>> across this 4GB file limitations. Backup/imaging utilities also
>> often run into problems caused by this file size limitation,
>
> About 3 years ago I installed XP on a 250 gb FAT-32 partitioned hard
> drive and installed Adobe Premier CS3. It had no problems creating
> large video files that spanned the 4 gb file-size limit of FAT32.
Wow! How absolutely unbeleivable! Now you are telling us that you
broke the binary limits of the FAT32 file system! The BS never
stops...what next?
John John - MVP
Splitting a file in multiple segments of less than 4GB and then saying
that you created files greater than 4GB on FAT32 is just you trying to
spread more of your lies and BS! You just never give up with your nonsense!
Philo Pastry
> I'll say this. At first when win98FE crashed, I would find files
> that were missing
Which proves my point.
How long ago does your recollection date to?
Win-98, first edition? So we are talking about 10, 12 years ago?
That's when many people formed their impressions of win-98 and FAT32,
back when you might have had 8 or 16 mb of system ram, and when
motherboards and video cards and drivers and application software were
barely functional for anything beyond 30 minutes of operation.
Microsoft came out with XP when the reliability and performance of PC
hardware took a major improvement turn in late 2002 / early 2003, when
PC's had 256 if not 512 mb of ram and hard drives started to do their
own internal error correction and began to have descent-sized internal
cache buffers.
Of course, millions of home XP-pc's were soon used as botnet trojans
because XP was designed to be used by corporations, managed by IT staff,
behind hardware firewalls and other sophisticated network appliances,
but none of that sank in to most people - because XP was the emporer
with no clothes from 2002 though late 2006 at least.
> > Or, if you've installed DOS first on an FAT32 drive, and then
> > install XP as a second OS, you can have a choice at boot-up to
> > run DOS or XP.
>
> Why not just put all the dos files in the XP partition, and use
> a dos boot disk to boot to that?
Who wants to mess with a dos boot disk?
On some of my XP systems, I start with a large drive, divide it up into
the volumes I want, format all volumes as FAT32 with a custom-selected
cluster size, and then I install DOS 7.1 so that the drive boots into
DOS on C drive. I then install XP onto C as well, and when the system
boots I get a menu asking if I want to boot into DOS or XP. What could
be simpler or more ergonomic than that?
John John - MVP
> You know, until just now, I figured there was something like DOS to
> access NTFS partitions. It never occurred to me that there wouldn't
> be.
You can use a PE disk like UBCD4Win, or a live Linux CD, or you can
mount the disk in another Windows 2000/XP/Vista/7 machine. The DOS over
Recovery Console argument is a non-issue, better methods have long been
available.
John
Philo Pastry
> > I've seen too many examples of NT-server log files that contain
> > actual and up-to-date data one hour, and because of a power
> > failure the system comes back up and half the stuff that *was*
> > in the log file is gone.
>
> You're lying again and the above statement proves beyond the shadow
> of a doubt that you have absolutely no experience whatsoever on
> NT server systems!
We have an NT-4 SERVER running an IIS website.
A log file of web-server hits is created daily. At the end of each day,
the current log file is closed and the next log file is opened.
I can access these log files on our local LAN, and I can even copy an
image of the current log file from the NT4 server to my machine.
Every time there was a power failure, not only would ALL the data in the
current log file be replaced with nulls after the server was rebooted,
but so too was the data in the 14 previous-days log files. Their file
size was not altered or changed - but all the data they contained was
replaced by nulls.
A fine example of NTFS journalling.
Philo Pastry
> > About 3 years ago I installed XP on a 250 gb FAT-32 partitioned
> > hard drive and installed Adobe Premier CS3. It had no problems
> > creating large video files that spanned the 4 gb file-size limit
> > of FAT32.
>
> Wow! How absolutely unbeleivable! Now you are telling us that
> you broke the binary limits of the FAT32 file system!
No. I'm telling you that Adobe CS3 knows how to write to FAT32 volumes
and that it automatically creates output files of 4 gb each as it's
writing to the drive.
Don't be so juvenille about this.
Philo Pastry
> > Simple. Acronis doesn't have the brains to split it's backup
> > files into 4 gb chunks. Which is a useful feature the user
> > might want even if it was being written to an NTFS volume.
>
> Splitting a file in multiple segments of less than 4GB and then
> saying that you created files greater than 4GB on FAT32
I've never said I created files greater than 4 gb on FAT32.
I said that for sufficiently smart programs, they know that they should
truncate their output to 4 gb and simply create a chain of output
files. That way they can effectively deal with the 4 gb file-size
limitation of FAT32.
And I still say there are practical and ergonomic reasons why you'd want
to divide large files into smaller chunks (1 gb, 4 gb, etc) regardless
what the file system is capable of.
John John - MVP
No, this is more of your BS and obfuscation to try to make readers
believe that the 4GB file size limit is a non issue on FAT32 and that
creating multiple segments is your elegant way around the problem!
John
glee
news:jbhvo.4705$NO2...@newsfe08.iad...
Actually, what he said in another later reply (so as to obfuscate the
issue, as usual) was that a feature of Adobe Premier CS3 automatically
saved the large video file as a group of smaller files that were each
under 4GB. This is typical 98 Guy "debating" tactics, to leave out
relevant info till later, to alter his statements, to throw in
irrelevant info to obfuscate.
I've read this argument over and over every time he decides to re-hash
it, and he apparently likes to waste time re-hashing it regularly even
though we've all read it before many times. He likes to argue for the
sake of argument...it's not debating. With his "200 years of computer
experience", he considers himself much more knowledgeable than anyone
here. I believe the correct term for him is "wanker".
--
Glen Ventura
MS MVP Oct. 2002 - Sept. 2009
CompTIA A+
http://dts-l.net/
John John - MVP
Well this is plainly simple, it is a testament to your incompetence and
ineptitude that you would be running an outdated program on an outdated
operating system that runs an old, different and completely outdated
NTFS version! This problem was corrected on Windows 2000...
John
glee
>>>><snip>
>>
>>Are you using XPSP3 Home or Pro Edition as the host OS?
>
> Pro, it appears. That was what was on this DELL before the HD failed
> and he gave me the computer and the CD's that came with it.
>>
>>If you find the old Connectix version 5 does not do all you want, try
>>the newer free version, Virtual PC 2007:
>>http://www.microsoft.com/downloads/en/details.aspx?FamilyId=04D26402-3199-48A3-AFA2-2DC0B40A73B6&displaylang=en
>
> I would rather have newer! Thanks.
>
> I read, probably in the wikip entry for this, that it was free for a
> while after MS bought it, but it also gavem me the impression it
> wasn't anymore. No time now to go reread it. I'm happy to have the
> new version.
>
> Thanks.
It's been free since Microsoft bought it, AFAIK.
glee
news:4CBDA3EB...@123.com...
You're running NT4? Why? Is that the only OS you were able to pirate
at the time?
How did you manage to have a power failure issue on the server in the
first place? No one runs a server without a UPS. A power failure that
lasts longer than the UPS can supply should also not be an issue, since
the system would have done a formal shutdown before that, using simple
software that comes with every UPS.
John John - MVP
He only recently acquired and installed NT4, he was posting on the NT4
groups as "NT Guy" not long ago when he first ever saw or used NT4. As
for him not using a UPS after experiencing problems after his first
power failure that is just more of his 200 years of inexperience
showing. He probably mounted his NT4 disk in a later NT machine not
even knowing how this would affect the NT4 NTFS file system...
John
Hot-Text
It's the Hard Drive going bad, Not the Software win 98 FE .... the Hard
Drive crashed,
To save your win 98 FE and stop the files from missing....
You would need to get a new Hard Drive make one 32 GB partition on it with
a FAT32 system
And Xcopy the 98 FE to the new Hard Drive is the only way to stop the lost
of create!
That How you do the repair to the Hard Drive,
@nomail.afraid.org FromTheRafters
news:i9kagh$1r9$1...@speranza.aioe.org...
> You're running NT4? Why? Is that the only OS you were able to pirate at
> the time?
:oD
> How did you manage to have a power failure issue on the server in the
> first place? No one runs a server without a UPS. A power failure that
> lasts longer than the UPS can supply should also not be an issue, since
> the system would have done a formal shutdown before that, using simple
> software that comes with every UPS.
You're talking to someone who apparently believes that W98 is *more* secure
than NT versions because of its immunity to privilege escalation exploits.
Bill in Co
You didn't mention NTFS4DOS or NTFSDOS Pro (although I think it's getting
harder to find), or Bart's PE Builder CD.
I don't remember all that much about any of these now, since I haven't had
to use any of them for some time now, but perhaps they pale by comparison to
UBCD4Win. ??
Sunny
"Hot-Text" <hot-...@hotmail.com> wrote in message
news:i9kei7$bcs$1...@speranza.aioe.org...
The 32Gb limit can easily be overcome :
http://jacquesbron.com/blog/general/fat-32-formatting-for-external-hard-drives-under-windows/
Sunny
Yes it does, it also called for a new file name to continue.
My decision to have a NTFS partition solved the 4Gb limit and ensued that
the backup files were kept in the same file name.
I have had no trouble with Acronis, except for their version 2010 which
porked my LAN access.
They have provided excellent e-mail support, however I reverted to Version
11 and the LAN became available again.
(They have assured me that the problem has not been reported in their
version 2011)
Hot-Text
be 1,000,000 GB all I care.
I say to you to make one 32 GB partition on it with a FAT32 system
partition partition partition partition partition partition partition
partition partition
Then Xcopy to the 32 GB partitionon the new 1,000,000 GB hard drive!
We tell you all 32 GB partition for win98
We care not of the size of the Hard Drives
Do you know you can only have one partition on a Hard Drive
And one Extended on the same Hard Drive
But you can have Log up to X
Partition C:\
Extended Log1 D:\
Log 2 E:\
Log 3 F
Log 4 G
Log 5 H
Log 6 I
UP TO
Log 23 x:\
"Sunny" <womba...@yahoo.com.au> wrote in message
news:2ipvo.411$tk4...@viwinnwfe02.internal.bigpond.com...
Bill Blanton
> "mm" <NOPSAM...@bigfoot.com> wrote in message
> news:rumqb6dl1epuh9khv...@4ax.com...
>> I read, probably in the wikip entry for this, that it was free for a
>> while after MS bought it, but it also gavem me the impression it
>> wasn't anymore. No time now to go reread it. I'm happy to have the
>> new version.
> It's been free since Microsoft bought it, AFAIK.
Actually, MS put it out as retail for a short period of time after they
bought it. I have the book size box and leaflet size manual to prove it.
I think it sold for around $100 ;-/
Bill Blanton
> In message <i9hhbq$9rg$1...@speranza.aioe.org>, glee
> <gle...@spamindspring.com> writes:
> []
>> The second list are the operating systems you can install it on, as a
>> host machine. I have read elsewhere that it will install and run on XP
>> Home as well as Pro, but have never tried.
>
> That's what I thought. (Anyone else know?)
VPC will run on XP Home, apparently with no problems, but is officially
unsupported.
>> The first list is what operating systems are "supported" to be run as
>> a virtual system on the host. Other systems can be run....Win98,
>> Linux, etc...they are just not "supported" , meaning you won't get any
>> help or support for issues, there may not be Additions available for
>> everything, or there may only be partial functionality of the
>> unsupported virtual system.
>
> Yes, I thought so too (-:. [What's an "Addition" in this context?]
VPC additions is a software package that runs as a service in the
virtual OS, and allows for some host to guest integration.
glee
news:4cbe4858$0$14837$9a6e...@unlimited.newshosting.com...
Ahh...thanks Bill!
mm
wrote:
>you give me a link to info website for hard drives bigger than 32 GB it can
>be 1,000,000 GB all I care.
>I say to you to make one 32 GB partition on it with a FAT32 system
>partition partition partition partition partition partition partition
>partition partition
>Then Xcopy to the 32 GB partitionon the new 1,000,000 GB hard drive!
You should try XXcopy. It's really good.
>We tell you all 32 GB partition for win98
>
>We care not of the size of the Hard Drives
>
>Do you know you can only have one partition on a Hard Drive
I think you can have 4 primary partitions on a hard drive, or 3
primary partitions and one extended one.
>And one Extended on the same Hard Drive
>But you can have Log up to X
Yes, I know that.
boomer
> I think there is something slightly off, about the resolution setting,
> but I can't find any tool on that particular distro, to tell me what
> resolution is being used. The "xdpyinfo" tool is missing. As is
> "xrandr".
You might open a terminal and try "xwininfo". Be sure some portion of
your Linux desktop is visible and click on that when prompted to click
on a window. The information will contain the correct width but the
height doesn't take the panels (taskbars) into account. To get their
heights you can xwininfo again and click on some unused area of each
taskbar.
Paul
The entire set of X tools are missing :-(
That particular environment is dedicated to a fixed function,
and the emphasis is on keeping the boot CD size to a minimum.
So you don't get 700MB of goodies with it. It's got X for
the desktop, but none of the usual tools. So no xwininfo or
xeyes or xclock or the like.
Paul
boomer
In that case, I'd examine /var/log/Xorg.0.log. Also, if xwininfo doesn't
have any dependencies that aren't already there, you might be able to
extract just that one file from the package and copy it to the VM or run
it from a CD or flash drive. I just checked the size and the binary is
only 23k on my system.
Paul
Thanks. I've give /var/log/Xorg.0.log a try, the next time I have it
fired up. There's bound to be some explanation in there, as to what
it's up to.
Paul
J. P. Gilliver (John)
Blanton <bbla...@REMmagicnet.net> writes:
[]
>VPC will run on XP Home, apparently with no problems, but is officially
>unsupported.
>VPC additions is a software package that runs as a service in the
>virtual OS, and allows for some host to guest integration.
>
>
--
J. P. Gilliver. UMRA: 1960/<1985 MB++G.5AL-IS-P--Ch++(p)Ar@T0H+Sh0!:`)DNAf
"Dogs come when they're called.
Cats have answering machines and may get back to you." - Phil Musiak
J. P. Gilliver (John)
writes:
[]
>Use FAT. Why use NTFS for ANYTHING? If you encounter an error on a
>FAT partition, you can retrieve everything unless the hard drive
>itself fails. If you crash a NTFS partition, kill ALL your data
>goodbye, because there is no way to retrieve anything.
>
>Heck, on a FAT partition, you can just stick in a DOS bootdisk and
>access all your data. Why make life complicated when there is no
>advantage whatsoever to using NTFS. Even if your drive access is a
>tiny bit faster with NTFS, is this worth losing everything? I always
>tell people who format NTFS that they damn well better backup their
>hard drive at least twice every hour, because if a NTFS installation
>fails, IT'S OVER.....
>
Although I feel happier in FAT, the above is just not true; I recently
helped someone with a Vista system on which the HD began to fail. When
popped into an external housing, I was able to access most of the
original files, on two different machines (my XP one, and the original
rebuilt onto its new HD from its recovery DVDs). [And yes, the HD was
definitely failing, it wasn't just file system corruption. SMART
etcetera.]
Bill Blanton
> And as Quirke says, under FAT you can have a mis-match between the
> file-size as recorded in the FAT vs the length of the file-chain, and
> for which is easily fixable.
Only easily fixable if the file is not fragmented, or the second FAT has
not been updated, otherwise you'll have to search the disk for any
non-contiguous clusters.
[snip]
> NTFS is more than journalling. There's the organizational structure or
> pattern as to how you store files and directories, and there's the event
> or transaction-monitoring and logging operations above that. You could
> theoretically have journalling performed on a FAT32 file structure.
Microsoft is apparently considering it for their exFAT format. Not
really transaction logging as in NTFS, but using the second FAT as the
record to roll back to.
http://www.patentgenius.com/patent/7613738.html
mm
wrote:
>mm wrote in message I'll say this. At first when win98FE crashed, I would
>find files that were missing
>
>It's the Hard Drive going bad,
I gather that is a possibility given the symptoms. But you say it
like it's a certainty. It definitely wasn't the case in the example I
gave. There was a bug in one program I used, where I save outgoing
messages, but they weren't really saved until I closed the program or
closed the outbox. I complained to the author and at first he didnt'
believe me, but later he believed me and he fixed it.
>Not the Software win 98 FE .... the Hard
>Drive crashed,
There was no harddrive crash. Thanks anyhow.