MCCABE@MTUS5.BITNET (04/01/88)
Date: 1 April 1988, 10:54:39 EST From: Jim McCabe MCCABE at MTUS5 To: INFO-ATARI16 at SCORE.STANFORD.EDU Subject: directory limit I seem to recall someone mentioning this topic before. I'm writing an application where it is conceivable that there might be hundreds of files in some directory. Is there a limit to the number of files per directory? I know MSDOS has a limit in the root directory but not the other subdirectories. Is GEMDOS the same? Thanks! +-----------------------+-----------------------------+ | Jim McCabe | BITNET: mccabe @ mtus5 | | G31 ECH MTU | jemccabe @ mtus5 | | Houghton, MI 49931 | UUCP: mccabe @ m-net | +-----------------------+-----------------------------+
apratt@atari.UUCP (Allan Pratt) (04/05/88)
From article <8804011616.AA00787@ucbvax.Berkeley.EDU>, by MCCABE@MTUS5.BITNET: > Is there a limit to the number of files per directory? I know MSDOS > has a limit in the root directory but not the other subdirectories. > Is GEMDOS the same? Yes, GEMDOS is the same -- a limit on root directory size but no limit to the number of files in a subdirectory. If you want more files in the root directory, you can fiddle with the boot sector of a freshly- formatted disk (even a hard disk partition) to make the root directory bigger -- this is one of the fields of the BPB that GEMDOS handles correctly. Note that big subdirectories will result in long file search times: all files will be searched for from the start of the subdir. When you create a file, you'll search twice: once to be sure the file doesn't already exist (and delete it if it does) and a second time to find an empty slot. You just have to deal with that, I'm afraid. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
wes@obie.UUCP (Barnacle Wes) (04/08/88)
In article <8804011616.AA00787@ucbvax.Berkeley.EDU>, MCCABE@MTUS5.BITNET writes: | Is there a limit to the number of files per directory? I know MSDOS | has a limit in the root directory but not the other subdirectories. | Is GEMDOS the same? Yep. -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes
pes@ux63.bath.ac.uk (Smee) (04/08/88)
TOS dir limits are like MS/DOS ones. Part of the 'formatting info' contained in the boot sector of a flopsy is an indication of how many sectors (7) are used for the root dir. This allows up to 112 (as I recall) entries in the root directory. Subdirectories are handled like normal files, so are not length limited, so there is no limit to the number of files in a subdir (other than the obvious one that there's a limit to how much trash you can put onto a flopsy at all). HOWEVER: If a subdirectory gets big, it hurts performance, both within the machine, and at the user-interface level, where you've got to find the file you want among the bunch. AND: The ST operating system does NOT shrink subdirectories. If you create a subdir holding (say) 256 files (takes 16 sectors) and then delete all but one of the files, the subdir file itself still stays 16 sectors long. To shrink it back to the 1 sector which would now be needed, you have to create a new subdir, move the file into it, delete the old subdir, and juggle the names. (Unless someone wants to write a PD directory compactor.)
wes@obie.UUCP (Barnacle Wes) (04/09/88)
In article <1035@atari.UUCP>, apratt@atari.UUCP (Allan Pratt) writes: > From article <8804011616.AA00787@ucbvax.Berkeley.EDU>, by MCCABE@MTUS5.BITNET: > > Is there a limit to the number of files per directory? I know MSDOS > > has a limit in the root directory but not the other subdirectories. > > Is GEMDOS the same? [...] > Note that big subdirectories will result in long file search times: all > files will be searched for from the start of the subdir. When you > create a file, you'll search twice: once to be sure the file doesn't > already exist (and delete it if it does) and a second time to find an > empty slot. You just have to deal with that, I'm afraid. You have a good point on directory search times here, Allan. In many ways, the Unix file system is similar - long directories slow down the file system. This is why the 2.11 version of the News software creates directory trees for the newsgroups. For instance, if /usr/spool/news is the news spooling directory, comp.sys.atari.st will be found in /usr/spool/news/comp/sys/atari/st. MCCABE: You will probably speed your program up by creating a reasonable directory structure and keeping the number of files in each directory down to 60 or so. Your application should run faster, and it _might_ make floppy backups easier (note the emphasis on might, this would depend on your app and the size of the data files). -- /\ - "Against Stupidity, - {backbones}! /\/\ . /\ - The Gods Themselves - utah-cs!utah-gr! / \/ \/\/ \ - Contend in Vain." - uplherc!sp7040! / U i n T e c h \ - Schiller - obie!wes