klute@heike.informatik.uni-dortmund.de (Rainer Klute) (02/26/90)
In article <2051@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >Most people don't open a file 40 directories down in >their heirarchy, or two folders each 20 (different) levels down, or >whatever. Hmm, is that really possible? I once tried out how deep a file could be nested in the file system hierarchy. From the desktop I created a folder "1" in the root directory, then a folder "2" within "1" and so on. I ended with folder "8" and got a message which told me that it is not possible to create a folder so deep in the index structure. To open a file 20 or 40 levels deep in the file system should not be possible. Now you can calculate the maximum pathname length: 3 (drive id, colon, backslash) + 8 (max. folder nesting) * (8+1+3+1) (basename (folder), dot, extension, backslash) + (8+1+3) (basename (file), dot, extension) + 1 (string terminating null character) = 120. Many (most?) programs do not care for pathnames of that length. For example I got 1st Word Plus to bomb out when I tried to open a file "D:\11111111.111\...\88888888.888\TEST.DOC". Probably the internal pathname buffer is to small and longer names overwrite other data. My Laser C documentation says that a 64 byte buffer for the dirname portion of a pathname is sufficient. However, I do not know what the official Atari developer's documentation says. Any comments? Dipl.-Inform. Rainer Klute klute@heike.informatik.uni-dortmund.de Univ. Dortmund, IRB klute@unido.uucp, klute@unido.bitnet Postfach 500500 |)|/ ...uunet!mcvax!unido!klute D-4600 Dortmund 50 |\|\ Tel.: +49 231 755-4663
apratt@atari.UUCP (Allan Pratt) (02/28/90)
klute@heike.informatik.uni-dortmund.de (Rainer Klute) writes: >In article <2051@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >>Most people don't open a file 40 directories down in >>their heirarchy, or two folders each 20 (different) levels down, or >>whatever. >Hmm, is that really possible? I once tried out how deep a file >could be nested in the file system hierarchy. From the desktop [...] The desktop imposes (used to impose) limits; I can't remember if they were removed for TOS 1.4 or not. But those were definitely Desktop-oriented, and not limits in the filesystem. There are NO limits in GEMDOS, except those already discussed -- the fixed pool from which to allocate directory descriptors. When you expand the pool you push that limit farther away, and theoretically you could add 3.5MB or so on a Mega 4 before really getting in trouble. GEMDOS never *constructs* pathnames, so it doesn't have any buffers or anything (of limited size or otherwise). When you do a Dgetpath, *you* supply the buffer, and it had better be big enough. There's no way to tell in advance how big is "big enough," but I would choose 128 or 256 bytes. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
ljdickey@water.waterloo.edu (L.J.Dickey) (02/28/90)
In article <2018@laura.UUCP> klute@heike.informatik.uni-dortmund.de (Rainer Klute) writes: >Hmm, is that really possible? I once tried out how deep a file >could be nested in the file system hierarchy. From the desktop >I created a folder "1" in the root directory, then a folder "2" >within "1" and so on. I ended with folder "8" and got a message >which told me that it is not possible to create a folder so >deep in the index structure. To open a file 20 or 40 levels >deep in the file system should not be possible. I also tried this experiment on the desktop and came to the same conclusion. However, Mr. Bammi pointed out to me that there is a limitation imposed by the desktop that is not imposed by TOS. So, I tried the same thing using a Gulam shell. I got over 40 levels deep. -- L. J. Dickey, Faculty of Mathematics, University of Waterloo. ljdickey@water.UWaterloo.ca ljdickey@water.BITNET ljdickey@water.UUCP ..!uunet!watmath!water!ljdickey ljdickey@water.waterloo.edu
roeder@sbsvax.cs.uni-sb.de (Edgar Roeder) (02/28/90)
In article <2018@laura.UUCP>, klute@heike.informatik.uni-dortmund.de (Rainer Klute) writes: > Hmm, is that really possible? I once tried out how deep a file > could be nested in the file system hierarchy. From the desktop > I created a folder "1" in the root directory, then a folder "2" > within "1" and so on. I ended with folder "8" and got a message > which told me that it is not possible to create a folder so > deep in the index structure. To open a file 20 or 40 levels > deep in the file system should not be possible. ... > Any comments? This limit of 8 folder levels only applies to the desktop. The GEMDOS file and directory functions have no such limit. You can see this if you try the same procedure as above from a shell (eg. gulam). - Edgar -- Mail: Edgar R\"oder E-Mail: roeder@cs.uni-sb.de Liesbet-Dill-Stra\ss e 3 D-6602 Dudweiler -o- -o- W-Germany ^ Phone: 06897/74643 '---'
david@bdt.UUCP (David Beckemeyer) (03/01/90)
Regarding long path names. I'm pretty sure that there was at one time
a maximum length of 64 chars. for pathnames in the TOS code in a few places.
I don't know if TOS 1.4 has this limit. I haven't looked recently.
--
David Beckemeyer (david@bdt.UUCP) | "I'll forgive you Dad... If you have
Beckemeyer Development Tools | a breath mint."
P.O. Box 21575, Oakland, CA 94620 | Bart - "The Simpsons"
UUCP: {uunet,ucbvax}!unisoft!bdt!david |bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) (03/01/90)
In article <2056@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: > GEMDOS never *constructs* pathnames, so it doesn't have any buffers or > anything (of limited size or otherwise). When you do a Dgetpath, *you* > supply the buffer, and it had better be big enough. There's no way to > tell in advance how big is "big enough," but I would choose 128 or 256 > bytes. huh? Dgetpath/gemdos whoever *does* monkey around in the buffer you supply. if the buffer supplied to Dgetpath() is shorter than 32 bytes it clobbers stuff outside of it (my guess is that it has someting to do with the fact that a directory entry is 32 bytes long) (i cant remember exactly, but maybe you need to s/32/64/g above). the developers gemdos documentation states that 125 is the max path length. i guess its either obsolete or incorrect. on a related note: gemdos(Fsfirst()) still (at T1.4) doesnt realize that "." ".." "\" or "D:\" are directories (have attr == 0x10) (or atleast "." and ".." should be, even if "\" is not considered to be a subdir). -- -- bang: {any internet host}!dsrgsun.ces.CWRU.edu!bammi jwahar r. bammi domain: bammi@dsrgsun.ces.CWRU.edu GEnie: J.Bammi
jlm@Apple.COM (Jeff Morris) (03/02/90)
In article <3052@sbsvax.cs.uni-sb.de> roeder@sbsvax.cs.uni-sb.de (Edgar Roeder) writes: >In article <2018@laura.UUCP>, klute@heike.informatik.uni-dortmund.de (Rainer Klute) writes: >> Hmm, is that really possible? I once tried out how deep a file >> could be nested in the file system hierarchy. From the desktop >> I created a folder "1" in the root directory, then a folder "2" >> within "1" and so on. I ended with folder "8" and got a message >> which told me that it is not possible to create a folder so >> deep in the index structure. To open a file 20 or 40 levels >> deep in the file system should not be possible. >... >> Any comments? > >This limit of 8 folder levels only applies to the desktop. The GEMDOS file and >directory functions have no such limit. You can see this if you try the same >procedure as above from a shell (eg. gulam). > > - Edgar >-- > Suppose this could be the window limit of GEM??? JLM #include <disclaim.h>
apratt@atari.UUCP (Allan Pratt) (03/02/90)
bammi@dsrgsun.ces.CWRU.Edu (Jwahar R. Bammi) writes: >In article <2056@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes: >> GEMDOS never *constructs* pathnames, so it doesn't have any buffers or >> anything (of limited size or otherwise). When you do a Dgetpath, *you* >> supply the buffer, and it had better be big enough. >huh? Dgetpath/gemdos whoever *does* monkey around in the buffer >you supply. That's what I said: Dgetpath writes the the current path into the buffer you supply, and since you can't tell Dgetpath how long that buffer is, it'd better be long enough. If your current path is shorter than 32 chars, Dgetpath should certainly not clobber anything outside your 32-char buffer. > the developers gemdos documentation states that 125 is the max >path length. i guess its either obsolete or incorrect. That has always been specious: I think the original author must've used that number because it's the longest filename you could pass as an argument to a program via Pexec. There's no such limit on filename lengths and never has been. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt