Path: utzoo!utgpu!watmath!maytag!watstat!dmurdoch
From: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Symbolic links in DOS (a la Unix) ?
Keywords: Putting the FAT in the fire
Message-ID: <346@maytag.waterloo.edu>
Date: 4 Aug 89 17:50:53 GMT
References: <5569@arcturus> <1583@unccvax.UUCP>
Sender: daemon@maytag.waterloo.edu
Reply-To: dmurdoch@watstat.waterloo.edu (Duncan Murdoch)
Organization: U. of Waterloo, Ontario
Lines: 22

In article <1583@unccvax.UUCP> cs75jmc@unccvax.UUCP (John Covington WN4BBJ) writes:
>In article <5569@arcturus>, mitch@arcturus.UUCP (Mitchell S. Gorman) writes:
>> 	What problems would occur if one should attempt to implement a
>> unix-like symbolic link to directories by creating an entry in a directory
>> that has a FAT start-point that is the same as a "real" directory somewhere
>> else in the tree?  
>
>Consider this:  You create two subdirectory entries  and zap them so
>they point to the same cluster.  You then copy 300 files into the one
>called \TEST.  A normal subdirectory starts out holding something like
>144 files and is extended to accomodate additional files.  The length of
>\TEST as stored in the root directory will be increased, but \REAL will
>not be modified.  What will DOS do then when you access \REAL? Will it 
>follow the FAT chain to determine the length of \REAL or will it go as 
>far as the root directory entry says it can go?

Actually, the directory entry for a subdirectory always gives the length
as 0 bytes, so this wouldn't be a problem.  But what you said (that I 
edited out) about CHKDSK complaining is the real problem, especially
if you get a real problem and run CHKDSK /F to fix it.

Duncan Murdoch