1.

Solve : system32\chkdsk.exe?

Answer»

i ran the above for a check with advanced care and got the report below do i type in y/n as it says at the bottom , thanks for the help

[Saving space, attachment deleted by ADMIN]Not a big deal one way or the other, they're just lost chains. Say yes. Then boot to the recovery CONSOLE and run chkdsk /ri'll try it now but what is a lost chain and truncatedA lost chain was once part of a file but because of a problem they lost connection with that file and no longer have any reference in the file table, so the OS really doesn't know they exist. The usual cause for lost chains is an anomalous shutdown of the system. They are GENERALLY not an issue.i did that , took a long time , is that it ok now

Quote from: ALLAN on November 05, 2009, 02:46:06 PM

The usual cause for lost chains is an anomalous shutdown of the system.

anonaly , n , abnormality;anything inconsistent or old .- anomalous adj.

anomalous this word has only been used twice in ch That's cause i couldn't spell it..... Quote from: harry 48 on November 05, 2009, 04:54:14 PM
i did that , took a long time , is that it ok now

anonaly , n , abnormality;anything inconsistent or old .- anomalous adj.

anomalous this word has only been used twice in ch
Yes, it should have taken a while to run and yes, it should be fine now.

And note - you spelled "anomaly" wrong Unless the files listed are important to you as data files there is generally no reason to convert the lost chains to files; it's usually better to just delete them and free the space.

Yes... lost chains do consume disk space, and they are still listed as used clusters in the FAT; they are not, however, associated with any files. This can happen, for example, if a delete operation is interrupted, or even disk corruption that finagles with the files clusters, so that the first cluster for example no longer points to the second.

The FAT and FAT32 file systems where these errors occur (NTFS is "immune" to these types of errors for the most part, since it implements journalling and allows the operating system to undo nearly any action performed on the drive), store a file as a "chain" of occupied clusters.

The File Allocation Table itself only points TOWARDS the first occupied cluster of the file. Each cluster points towards the next occupied cluster in the chain. (it usually tries to puke the file in a straight contiguous line, but sometimes it has to dry heave to skip over already occupied clusters). Once completed- tada! the file is stored.

The issues result when either a physical error occurs writing or reading the data or more commonly a sudden power loss during a critical time in a read or write operation. For example,if one was to overwrite a file, the files clusters will be overwritten. Assume for the moment that a smaller file is written over a large one, and just as the last cluster is written, there is a power outage.

What results? Well, quite possibly the last cluster of the new file contains only a portion of it's data, and the remainder- including the pointer to the next cluster- is still the same as before- so what we have now is a large fragment of the saved file and a fragment of the file it overwrote all, according to the filesystem, stored in one file chain. This doesn't result in either lost chains or lost clusters.

Whatever causes it lost chains are just that- lost chains of clusters that don't belong to a file but are marked as allocated. Cross-linked files as I explained are when clusters are shared between files, this is almost never intentional.

The opposite error is a "cross-linked" file, where it isn't that no files reference the cluster, but where multiple files do. In such a case one or both files are usually corrupted.Quote from: Allan on November 06, 2009, 05:48:16 AM
Yes, it should have taken a while to run and yes, it should be fine now.

And note - you spelled "anomaly" wrong






thank you as well bc-p


Discussion

No Comment Found