Printable View
Ahh ic :cool: I never really considered that 'coping ability' so to speak of the file system. Obviously NTFS is more preferable for all the reasons of storage, accessibility and security - However, in a critical event, i assumed it was just more that could go wrong.Quote:
Originally Posted by Und3ertak3r
Intrigued
CTO
not to be argumentative.. but just because someone has never seen something is not reason to think it doesn't exist..Quote:
Originally Posted by morganlefay
I do find the tone of your opening comment more on the confronting side.. but your not one to try to wind someone up .. are you..
Not the File system expert.. there are people who can give you the full goss on the pro's and con's of the various file systems..Quote:
Originally Posted by CybertecOne
with MS some times even the OS does not have enough robustness/intelligence to survive some simple filesystem stuff-ups.. like recognising that the file error is in a system file and restoring a copy from cache.. instead of moving the whole thing off to a bin some where.. in the vain hope the user is able to work out wtf the file is and where it should come from and how to restore a valid working copy.. with a non functioning OS..
just one dll is all it takes to kill XP.. but just hiding a few files in the System32 folder can make it mighty ill with out complete death...
Its not worth it MLF.... walk away.Quote:
not to be argumentative.. but just because someone has never seen something is not reason to think it doesn't exist..
I do find the tone of your opening comment more on the confronting side.. but your not one to try to wind someone up .. are you..
---
IMO, the cause and effect of a file system error is universal across all file systems. What could cause a catastrophic issue on one particular FS, can do the same damage on any other FS.
Therefore, I cannot agree that FAT32 file systems have any effect or contribution to ANY problem caused as described, or any problem i have encountered in my many years in IT.
I therefore pose that the above statement is entirely non-sensical/erroneous.Quote:
Originally Posted by Und3ertak3r
The mere fact that most of the machines in which you have encountered problems have a FAT32 FS is entirely co-incidental, as in my experience the file system of a machine does not play into any equation unless considering data recovery or changes to the existing file system. I honestly cannot think of a time when i thought to myself during diagnosis, "oh, i better check what the FS was" ... "just in case that is what caused the problem"
CTO
who me??? :eek:Quote:
I do find the tone of your opening comment more on the confronting side.. but your not one to try to wind someone up .. are you..
only people that are easily wound... ;)
MLF
]EDIT> excellent article on troubleshooting disk issues with MS oses
http://technet.microsoft.com/en-us/l.../bb457122.aspx
Not necessarily. I replaced two harddrives in asQuote:
Originally Posted by nihil
many days last week both of which generated errors
when Ghost was run. Until I used "chkdsk /r" (both
times the file system got repaired), there was no
way to ghost the things. So, obviously, chkdsk can
make a HDD better, at least temporarily. But such
a repair is not something you want to count on unless
it's for a recovery.
What IS interesting was both drives were SATA
and chkdsk would not repair the system when run
natively from the installed OS (both XP). When
I booted off a PE disk and ran chkdsk, they were
repaired. That's a first (for me). Something to
bear in as you see more SATA drives.
chkdisk cannot run and repair on the drive while the OS is loaded ...and should ask you if you want to run on a restart so it can lock the drive\files as it tests the integrety of the file system and looks for corrupted files and damaged sectors on the drive.
And depending on the size of the drive and number of files can take a very long time.
If I suspect a drive failing...I usually slave it into another machine and backup the data...then use that machine to run chkdsk on the drive....in a sense using a boot disk.
If a drive is failing you usually will have issues with writing to the disk, slow boot...maybe clicking noises and errors in the event log.
Slaving the drive or using a boot disk to read and copy data puts less stress on the drive as there is minimal writing...
Then when running utilities such as chkdsk may kill the drive ...if it is physically damaged beyond the point of repair. .... else it will mark the damaged area and not use it...move the files to another area and.......... voila....you are up and running again. Now if this was a mission critical machine...I would consider replacing the drive.
But thats just me....and my ever so humble opinion on the matter :)
MLF
Replacing the drive is always the best way to go; new drive, new warranty, less wear and tear etcQuote:
Then when running utilities such as chkdsk may kill the drive ...if it is physically damaged beyond the point of repair. .... else it will mark the damaged area and not use it...move the files to another area and.......... voila....you are up and running again
I just wanted to point out that if it is a logical problem with the sectors (or even physical damage) and chkdsk marks those sectors as bad and moves the data, you wont have any future problems from the same cause.
However, if the physical damage is affecting moving parts (heads, bearings), expect the drive to continue to degrade even after chkdsk has done its work.
CTO
You are absolutely right CTO.....
I just meant that the only time I have seen chkdsk fluck up a drive was one already damaged....and that I have used chkdsk to recover a few machines...that went on humming for a couple of years.
I guess my point would be backup backup backup before doing anything :)
MLF
I'm well aware of how chkdsk works. It's strange, I'd never seen anything like this until last week. Both machines would hang at a certain point after the mandatory reboot and chkdsk started. One machine we left running for hours on end and it just sat at 43% during stage 4 once it got to that point. Then booting to a PE disk, chkdsk would work right thru, albeit slowly, and fixed the file system. Like I said, something to bear in mind.Quote:
Originally Posted by morganlefay
I do mostly field work and some clients can be hesitant about sensitive data, especially acct'ing, being copied over to one of my laptops. So I use bootdisks and usb drives to do backups generally, then run chkdsk in an attempt to prepare the file system for ghosting. Reinstalling from scratch is less profitable from my standpoint and I get less whining if I manage to restore the computer to it's former state.Quote:
Originally Posted by morganlefay