gcoen@emx.utexas.edu (Gary A. Coen) (05/21/91)
Running Windows 3.0 on an IBM PS2 Model 80 (6Mb RAM, 44.5Mb FD, PCDOS 3.3), when invoking the CHKDSK function with the /F parameter set, I get the fol- lowing behavior: CHKDSK /F Volume is ... File A is cross linked on cluster n. File B is cross linked on cluster n. I have not been able to find documentation of this in my DOS manual. Is it bad? Does anyone *know* what it means? Does anyone *know* why it is happen- ing? --Gary Coen
jcmorris@mwunix.mitre.org (Joe Morris) (05/21/91)
gcoen@emx.utexas.edu (Gary A. Coen) writes: >Running Windows 3.0 on an IBM PS2 Model 80 (6Mb RAM, 44.5Mb FD, PCDOS 3.3), >when invoking the CHKDSK function with the /F parameter set, I get the fol- >lowing behavior: > CHKDSK /F > Volume is ... > File A is cross linked on cluster n. > File B is cross linked on cluster n. >I have not been able to find documentation of this in my DOS manual. Is it >bad? Does anyone *know* what it means? Does anyone *know* why it is happen- >ing? What it's telling you is that both files A and B are claiming that cluster -n- contains their data. This cannot occur in a properly-running system. At least one of the two files is corrupted, and possibly both. The DOS file system works (if you want to call it that) by using the directory entry for a file to point to the first cluster containing the data. When someone wants to get the data from the next cluster, the file system goes to the FAT (File Allocation Table) entry for the first cluster; that entry should be either an EOF (End-of-File) mark, or a pointer to the second cluster of data. The process continues until the user either gives up (e.g., by reading a ^Z in a text file) or the get-next-cluster routine encounters an EOF mark in the FAT. *Every* cluster in the data portion of a disk (fixed or floppy) is represented by a FAT entry. The entry can say that the cluster is: (a) Unused, and not allocated to any file (b) In use by a file, and the FAT entry points to the next cluster, (c) In use by a file, and is the last cluster for that file, or (d) unusable because of a disk error. What CHKDSK does is to build a map in memory of all of the clusters on the disk. It strikes out the clusters which are marked free in the FAT, and then runs through all the directories on the disk, and strikes out the clusters owned by each file by running the FAT chain. The disk is OK if at the end of the process each cluster has been struck out exactly once. (Yes, CHKDSK also matches the file size against the cluster count... but that wasn't the question.) An error is reported if either (a) a cluster was not struck out during the process, or (b) a cluster was struck twice. If a cluster was not struck out, then you get a "lost chain" error message. If a cluster was struck more than once (as you saw) then two or more files are claiming ownership of the cluster. The CHKDSK function has nothing to do with Windows, although it may have been a Windows program (or crash) which contaminated the disk. Best idea would be to restore the files from your backup disks. Joe
huff@kuhub.cc.ukans.edu (Steve Huff, University of Kansas, Lawrence) (05/22/91)
> Running Windows 3.0 on an IBM PS2 Model 80 (6Mb RAM, 44.5Mb FD, PCDOS 3.3), > when invoking the CHKDSK function with the /F parameter set, I get the fol- > lowing behavior: > > CHKDSK /F > > Volume is ... > File A is cross linked on cluster n. > File B is cross linked on cluster n. I'm doing this from memory, so if anybody can expand on this please do. My Norton book is at the office. What happened is the File Allocation Table (FAT) is shows that File A and File B are occupying the same cluster (n). It's like parking your car and your wife's in the same stall -- it's pretty difficult to extract them once done (Yugos excluded). When you attempt to use File A or File B, expect some corruption. Hopefully they're .bak or .tmp files -- if so delete them if you're done with 'em and be on your way I've seen this response most often when using Windows. Windows is disk intensive, and sometimes loses track of it's .tmp files. This causes chkdsk to report errors. One possible solution is putting the following in your config.sys: STACKS 0,0 And you might also try this close to the beginning of your autoexec.bat: SET TEMP=C:\WINDOWS\TEMP or the location of your TEMP directory for Windows. Good luck! Steve ----- Steve Huff, student, University of Kansas "Still love that KU basketball!" Microcomputer Consultant, Hill's Pet Products, Topeka, Kansas Internet: HUFF@kuhub.cc.ukans.edu Bitnet: HUFF@UKANVAX GEIS: HUFF@HILLCORP#
sberger@cpocd3.intel.COM (Scott Berger) (05/23/91)
In article <49299@ut-emx.uucp>, gcoen@emx.utexas.edu (Gary A. Coen) writes: |> Running Windows 3.0 on an IBM PS2 Model 80 (6Mb RAM, 44.5Mb FD, PCDOS 3.3), |> when invoking the CHKDSK function with the /F parameter set, I get the fol- |> lowing behavior: |> |> CHKDSK /F |> |> Volume is ... |> File A is cross linked on cluster n. |> File B is cross linked on cluster n. |> |> I have not been able to find documentation of this in my DOS manual. Is it |> bad? Does anyone *know* what it means? Does anyone *know* why it is happen- |> ing? |> |> --Gary Coen What it means is that somewhere along the way the file system got confused and it thinks that a cluster belongs to two different files. I do remember reading that running chkdsk with the /f option from within Windows is a distinct no-no. You should exit Windows and run it again to make sure. Unfortunetly one of the files thats involved in the cross link is toasted. The solution is to copy both files involved in the cross link to new files, then go back and kill the original. But you will always lose some data when this happens, hopefuilly it was something you have backed up elsewhere. -- ----------------------------------------------------------------------- - Scott Berger sberger@cpocd3.intel.com - - Intel Corporation, Chandler, AZ sberger@ch3.intel.com - -----------------------------------------------------------------------
f18@clark.edu (Torry V Schreiner) (05/24/91)
In article <49299@ut-emx.uucp> gcoen@emx.utexas.edu (Gary A. Coen) writes: >Running Windows 3.0 on an IBM PS2 Model 80 (6Mb RAM, 44.5Mb FD, PCDOS 3.3), >when invoking the CHKDSK function with the /F parameter set, I get the fol- >lowing behavior: > > CHKDSK /F > > Volume is ... > File A is cross linked on cluster n. > File B is cross linked on cluster n. > >I have not been able to find documentation of this in my DOS manual. Is it >bad? Does anyone *know* what it means? Does anyone *know* why it is happen- >ing? > >--Gary Coen It is well known that 'CHKDSK /F' doesn't work properly under Windows 3.0 because of a bug in Windows 3.0 that interferes with the does shell.