Path: yama.mcc.ac.uk!doc.ic.ac.uk!sunsite.doc.ic.ac.uk!lyra.csx.cam.ac.uk!rjk1002 From: [EMAIL PROTECTED] (Richard Kettlewell) Newsgroups: comp.sys.sinclair Subject: Re: Hard-Drive DOS standard for SAM Date: 27 Oct 1994 13:15:53 GMT Organization: Cambridge University Lines: 91 Message-ID: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> NNTP-Posting-Host: myrddin.chu.cam.ac.uk
In article <[EMAIL PROTECTED]>, Simon Cooke <[EMAIL PROTECTED]> wrote: >Hello everyone... > >The time has come to work out the standard file structure for this new >hard-drive thingummybob... > >I'm going to see about posting this to the SAM Users mail thingy as well, >and I'll see if I can post all input from that here too... Not a SAM user, but I do have a couple of thoughts on the subject... The following are opinions only, E&OE, etc. >Basically, how should we arrange it all? > >I'd like a filesystem that has no limits on no' of files, 32 bit file numbers (inode numbers, in Unix terminology), 32 bit file lengths, etc should solve most of the potential problems. Make directories real files (as far as the file system is concerned, even if not the user); then no limits on file size => no limits on number of files in a directory. >allows user >status (ie password protected areas, file groups, etc.... to allow >networking / fileserver activity if it ever happens)... As you are probably aware, Unix associates with each file one user and one group; the user has read, write and execute rights (or not), likewise the group, and likewise everyone else. This is not sufficient. In a multi-user environment it is nice to have some concept of supervisory rights -- i.e. the ability to change the rights pertaining to the file. Under Unix, only the user who owns the file can do this; hence in shared files, the user who creates the file (and therefore owns it) must remember to arrange for appropriate other users to be able to write to it! Novell does things a bit better, but has too many distinct types of rights, and it is too easy to shoot one's self in the foot and delete _all_ your rights over a file! Password protected files might be best implemented simply by requiring a password to join a particular group; this removes the need for password protection from the file system. Of course, without any memory protetction, security is a little tricky. (The point of the execute right is not to _stop_ people from running things -- if you can read it, you can make a copy and set the execute bit on that. The point is to indicate which files it is sensible to execute.) >Basically, we've got to define how we're going to store the files on the >disc, how it finds them when they're stored there, and what's held in the >directory structure. > >Any ideas anyone? > >I'm currently thinking of 64 chars per directory entry, allowing 20 >character (or so) filenames, with possibly a quick-to-access file system (ie >one that is a combination of FAT and sector/head/track at the end of each >logical sector (ala SAM)). There are some advantages to the Unix system where a directory entry consists of a name and a number -- and nothing else. The number says where to look up further information on the file; through this mechanism, many filenames may refer to a single file. Of course, since the information on any one file is stored in two places on the disk, things slow down a bit; but you will only need the filename part when actually opening (deleting, renaming...) a file. There are real disadvantages to putting the 'next' block number at the end of each block. It will badly slug any operations which involve seeking back and forth through a file (especially back.) It is unlikely to significantly improve plain serial loading times over a DOS-like FAT since one would usually maintain most or all of the FAT in memory anyway (depends how big the disk is, but unless you have bad fragmentation -- which can be cured -- one file's FAT entries will only occupy two or three distinct blocks at most.) You might like to come up with some fun strategy to make sure that accidentally deleted files are as easy as possible to retrieve, e.g. not using the disk space they occupy until there is no alternative. But, this would probably lead to very bad fragmentation. -- Richard Kettlewell [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], CUWoCS VP, SF nut and Jomsviking.
