mitch@arcturus.UUCP (Mitchell S. Gorman) (08/01/89)
Had a strange thought last nite, so naturally I figured I'd throw it out on the net to see what happens... 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? To clarify (hopefully :^) the question: imagine, if you will, a directory under the root, called REAL. Imagine, also, another directory under the root which is named TEST. Suppose that in the directory info for the root, the entry for REAL has a pointer to a given sector x in the FAT. If we then create an entry under \TEST called LINK, set the entry's directory bit, and set its FAT pointer to be the same as that of \REAL (namely, set it to x), then will files located under \REAL be accessible through the path \TEST\LINK, and vice versa? Just a little question I thought I'd pose to greater minds than mine. ;^) Mitch @ Rockwell, Anaheim mitch@arcturus.UUCP Disclaimer: I can't help it; sometimes I just think funny thoughts...
jwright@atanasoff.cs.iastate.edu (Jim Wright) (08/03/89)
I think you're talking of hard links, not symbolic or soft links. Yes, this should appear to work at first. But eventually you'll screw up your system. First time you delete a file so the same space is marked as both free and claimed by a file. MSDOS never had any notion of links, and trying to graft them in now would be difficult. -- Jim Wright jwright@atanasoff.cs.iastate.edu
cs75jmc@unccvax.UUCP (John Covington WN4BBJ) (08/04/89)
In article <5569@arcturus>, mitch@arcturus.UUCP (Mitchell S. Gorman) writes: > > Had a strange thought last nite, so naturally I figured I'd throw > it out on the net to see what happens... > > 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? > > To clarify (hopefully :^) the question: imagine, if you will, a > directory under the root, called REAL. Imagine, also, another directory > under the root which is named TEST. Suppose that in the directory info for > the root, the entry for REAL has a pointer to a given sector x in the FAT. > If we then create an entry under \TEST called LINK, set the entry's > directory bit, and set its FAT pointer to be the same as that of \REAL > (namely, set it to x), then will files located under \REAL be accessible > through the path \TEST\LINK, and vice versa? > This will work but under DOS this is called a cross-linked file. If you run CHKDSK it will report it as a File cross-linked on cluster ####. You are basically asking for trouble if if you do this in the DOS world. In general, a cross-linked file is considered to be an error and the behavior is unpredictable. 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? I am sure this would work only as long as you don't dump over 144 files into the subdirectory; otherwise some strange things are likely to happen. John Covington WN4BBJ E-mail: cs75jmc@unccvax.UUCP P.O. Box 217122 MCI Mail: JCOVINGTON 342-6957 Charlotte, NC 28221-7122 Packet Radio: WN4BBJ @ KK4L (704) 537-7653 "Give it back, Eric, it's not yours" (the ICOM)
Ralf.Brown@B.GP.CS.CMU.EDU (08/04/89)
In article <1583@unccvax.UUCP>, cs75jmc@unccvax.UUCP (John Covington WN4BBJ) wrote: }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? As it happens, the length of a directory as reported in ITS directory entry is always zero. The true length is determined by following the FAT chain, except for the root directory, which is always of fixed size. }I am sure this would work only as long as you don't dump over 144 files }into the subdirectory; otherwise some strange things are likely to }happen. Directory entries are 32 bytes, so 2K clusters allow 64 entries, 4K clusters allow 128 entries, etc., before another cluster has to be added. Don't forget to count '.' and '..' as entries. -- UUCP: {ucbvax,harvard}!cs.cmu.edu!ralf -=-=-=-=- Voice: (412) 268-3053 (school) ARPA: ralf@cs.cmu.edu BIT: ralf%cs.cmu.edu@CMUCCVMA FIDO: Ralf Brown 1:129/46 FAX: available on request Disclaimer? I claimed something? Alan Demers: Here is the promised Fast Fourier Transform example. It worked for the two examples I tried, so I'm fairly sure it is correct. Student: Proof by exhaustive testing? Demers: Well, it sure exhausted me.
dixon@sagittarius.crd.ge.com (walt dixon) (08/04/89)
There are two problems with this idea. Since DOS doesn't know anything
about reference counts, file deletion will leave dangling references.
Subsequent operations on these references have the potential to trash
your disk structure. chkdsk would not be too happy about finding
the same cluster in more than one file.
Walt Dixon {arpa: dixon@crd.ge.com }
{us mail: ge crd }
{ po box 8 }
{ schenectady, ny 12345 }
{phone: 518-387-5798 }
Walt Dixon dixon@crd.ge.comdmurdoch@watstat.waterloo.edu (Duncan Murdoch) (08/05/89)
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
ho@fergvax.unl.edu (Tiny Bubbles...) (08/05/89)
From article <5569@arcturus>, by mitch@arcturus.UUCP (Mitchell S. Gorman): > 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? As someone else mentioned, that's a little more like a hard link, but then who's counting? On a more serious note, DON'T run chkdsk after doing this ... also, don't run any disk optimizers, and don't remove either of the directories. chkdsk will mark it as a cross-linked file and do heaven-knows-what to your directories. --- ... Michael Ho, University of Nebraska <ho@fergvax.unl.edu>
leonard@bucket.UUCP (Leonard Erickson) (08/07/89)
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?
CHKDSK will report any such "links" as "cross-linked files". And if you
have used the /f parameter, it will cheerfully nuke the files.
In short, that sort of link is not only not supported, it is considered
to be a damaged disk by the OS!!!!
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Shortandy@mks.UUCP (Andy Toy) (08/09/89)
In article <1604@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: |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? | |CHKDSK will report any such "links" as "cross-linked files". And if you |have used the /f parameter, it will cheerfully nuke the files. | |In short, that sort of link is not only not supported, it is considered |to be a damaged disk by the OS!!!! +-- Someone could always write a few utilities to support linked files. We would need a chkdsk-like programme (might as well call it fsck) that would do the same thing as chkdsk and handle linked files. Of course we need a ln command to create the links. Also mv and rm would have to check for links before deallocating the blocks. Sounds like it could be an interesting project. -- Andy Toy, Mortice Kern Systems Inc., Internet: andy%mks@watmath.UWaterloo.ca 35 King Street North, Waterloo, UUCP: uunet!watmath!mks!andy Ontario, CANADA N2J 2W9 Phone: 519/884-2251 FAX: 519/884-8861
swh@hpcupt1.HP.COM (Steve Harrold) (08/10/89)
Andy Toy of MKS writes: >> Someone could always write a few utilities to support linked >> files. We would need a chkdsk-like programme (might as well >> call it fsck) that would do the same thing as chkdsk and handle >> linked files. >> Of course we need a ln command to create the links. Also mv and rm >> would have to check for links before deallocating the blocks. >> Sounds like it could be an interesting project. ================== Go for it Andy. I can hardly wait for the MKS Toolkit upgrade.
iiitsh@cybaswan.UUCP (Steve Hosgood) (08/11/89)
In article <1406@mks.UUCP> andy@mks.waterloo.edu (Andy Toy) writes: >In article <1604@bucket.UUCP> leonard@bucket.UUCP (Leonard Erickson) writes: >|CHKDSK will report any such "links" as "cross-linked files". And if you >|have used the /f parameter, it will cheerfully nuke the files. > >Someone could always write a few utilities to support linked >files. We would need a chkdsk-like programme (might as well >call it fsck) that would do the same thing as chkdsk and handle >linked files. > >Of course we need a ln command to create the links. Also mv and rm >would have to check for links before deallocating the blocks. > >Sounds like it could be an interesting project. > I seriously thought of doing it too. So far, time has been too short :-( A simple re-write of rm, mv, ln etc wouldn't work as utilities could still create, delete and truncate files under DOS in the old manner. The most likely way of making it work is to intercept INT21 functions 13H, 16H, 3CH, 41H and maybe some others. This would "ensure" that existing utilities worked with the new regime without trouble. Chkdsk would have to be re-written, as would anything else that bypasses DOS and writes to the disk directly. -----------------------------------------------+------------------------------ Steve Hosgood BSc, | Phone (+44) 792 295213 Image Processing and Systems Engineer, | Fax (+44) 792 295532 Institute for Industrial Information Techology,| Telex 48149 Innovation Centre, University of Wales, | JANET: iiitsh@uk.ac.swan.pyr Swansea SA2 8PP | UUCP: ..!ukc!cybaswan!iiitsh -----------------------------------------------+------------------------------ My views are not necessarily those of my employers! Please note the change in my username as of 1 Aug '89
davidr@hplsla.HP.COM (David M. Reed) (08/12/89)
I agree. I would like to see a set of utilities that will handle linked files under DOS properly. (And I know of no one better qualified to do this than MKS.) For example, to conserve disc space, it would be nice to have one program with three names linked to it (cp, rm, ln) that simply looks at the name it was called by to determine the minor little differences in action that would need to occur when it runs. A further extension of this idea would be so that one BATch file could have many branches, and simply by looking at what name it was invoked by would act like a GOTO to branch to the proper section of the BATch file. I could really put a feature like this to use!
mitch@arcturus.UUCP (Mitchell S. Gorman) (08/17/89)
I posted the original query on this subject... <stop throwing things at me!!> Thru discussions via Email with someone who's name unfortunately escapes me at the moment, I thought of perhaps finally finding a use for a volume label flag being set within a subdirectory... Obviously, a directory has no clue whether or not something is linked to it, unless we tell it so. Perhaps we could use a directory entry marked as a volume label to give the "linked" directory a way to find out who it's "linkee"'s are. Oh, well, just throwing out a bit more for you folks to chew on... BTW, I am _not_ planning on writing a utility to do this, so you need not worry that _I_ will be making money on any ideas anyone may come up with. I cannot speak for anyone else, tho. Mitch @ Rockwell, Anaheim mitch@arcturus.UUCP Disclaimer: Just another in a long list of strange ideas... :^)