Lost file fragment identification

I have very few problems with my system unless I create them. 2 days ago, I forgot my system was on, and hit the power switch. After turning it back on, and going thru scandisk, I checked the scandisk log to see what damage I had done. A lost cluster was converted to a file. I was interested in finding out what file name the cluster was from, so I did a system search. The first two thirds of the lost cluster file could not be identified, but the last approx third was found to be part of the system backup cab files, ie rb00n.cab. I also have a few saved cab files that are many months old, on another drive, and the lost cluster identified with those backup cabs also.

I had thought that a lost cluster was just that, lost. But that apparently is not the case. So just how does 98 handle a lost cluster?

Also, is there a DOS command, or other command in 98 that can be used to create a cab file from several conventional files. Since the rb00n.cab files are made up of win.ini, system.ini, user.dat and system.dat, it would seem that if I make my own cab file, I should be able to determine which of these files were involved in the lost cluster.

Any ideas other than the above, to determine the files in the cab file, that are affected?

Bumps

 

I'll explain what a lost cluster/lost file fragment is. IBut, I'm confused as to what you want to do with the CAB files.

CHK files get created for the following reason.

When a program is running that is in the process of either creating a new file, or updating an existing one, the changes are obviously being written to an area on your disk (clusters). BUT, those clusters do not get actually assigned to a particular file name until that program closes the file.

Windows keeps track of all clusters, as to whether or not they are in use, and if in use, which file they belong to. (FAT table and disk directory)

When an application is terminated (ctl-alt-del), or it fails on an error or you reboot your PC while that program is running, the clusters continue to be "in use" (in the FAT) and continue to be "not assigned" (not referenced from the disk directory).

When Scandisk runs, it finds these "lost clusters" and either creates CHK files or deletes them, depending on the option. In general, you can delete the files after they are created. The only time you would want to attempt recovery, is in the event that the file being edited or created, was extremely important and needed to be recovered.

But, having said this, you still need to be careful. There can be situations on a failing drive where the FAT/directory is damaged, and scandisk "thinks" that a lot of your disk is comprised of lost file fragments. In this case you do not want to convert them to files, and you definitely don't want to delete them.

So, if you have just gone through a bad shutdown, or had programs fall over on you, then you can expect to have scandisk find some fragments when it runs. But, it it ever finds "a lot ", be suspicious.

This is one reason why you do want to be careful running scandisk with autofix selected. You always want to review the errors found and then decide if you really want scandisk to try and fix them.

 

>But, I'm confused as to what you want to do with the CAB files.<

Let me try to explain my "logic ". First, my Scandisk ini is set to convert fragments to files. So after the bad shutdown, scandisk ran, and created C:\FILE0001.CHK, a 5K file. I opened the file in Notepad. Although most of the CHK file looked like this:

\°1'Û¾S°mnc¡Å ZÔ#†–UTº+#–GpÔ)â+ƒÀµIQu‘ªHÔY´Ã‰VÆ’«èå±Ã•)bTQÃyÌÀ„cÃ’K#Èò¤Ãƒ«Ã'K¿Ã>ÔÙ¸E.“Cn7Å +ÔÇúºqZH4ó8XPÃŽÃŒ_Ñú'ÃtßcWôÑð„öñªqokòÿ³*wræäYý›ÃÃBpu]ÎÓ PïÑâ¯kqc°Fû£e:Ÿ º
ÃŒ¢Ã©R3xÃ’ÃJšÚ|54Ô

that part shown above, was located in every rb00n.cab file on my system, by doing a file search of *.*, and using that (above) as input information in the "Containing text" entry line of the search name and location window.

Now when I "View" the contents of my cab files, I have them setup to backup system.dat, user.dat, system.ini and win.ini via SCANREG.INI, and I can see those files there. However, if I extract those files from the rb00n.cab, and repeat the search using the data above, as contained in the CHK file, nothing is found because converting those files to a cab file results in non-text information. My thinking was, if I can convert win.ini, or any of the other files to a cab file, and then repeat the search, I would know if the file fragment was part of system.dat, user.dat, system.ini or win.ini, or a combination of 2 or more of those files.

BTW, this is the first time I have been able to relate information in a CHK file to a specific file in my system.

Bumps

 

I'll start by saying that I think you are wasting your time.

Since scandisk is just linking all the (lost) clusters into a chain(s), with no knowledge of what file they belong to, the information in a portion of the cluster may belong to one file, while the rest of the info belongs to another or many other files. This would happen because a file created that is less than a cluster in size will have the entire cluster assigned to it. But, whatever junk was there from the previous file or files stays there also. (why you are seeing a piece of the compressed cab files, I have no idea).

As I said, the only time you really want to attempt any recovery is if you had a very important file open in the process of being updated, and it would take a long time to redo the updates. Otherwise, if there aren't many present, just delete them or turn them into files and delete them.
I note that your option is to create files. I would suggest that you turn this option off for the reason that I stated above.