Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!elroy.jpl.nasa.gov!usc!ucla-cs!ucla-seas!turing!plinio From: plinio@turing.seas.ucla.edu (Plinio Barbeito/;093091;allsites) Newsgroups: comp.sys.atari.st Subject: Re: case insensitivity in TOS Message-ID: <1709@lee.SEAS.UCLA.EDU> Date: 29 Jan 91 03:26:19 GMT References: <1991Jan18.005041.22961@convex.com> <1991Jan22.170111.12465@cs.mcgill.ca> Sender: news@SEAS.UCLA.EDU Organization: SEASnet, University of California, Los Angeles Lines: 85 In article <1991Jan22.170111.12465@cs.mcgill.ca> depeche@cs.mcgill.ca (Acme Instant Dehydrated Boulder Kit) writes: >In article <1991Jan18.005041.22961@convex.com> rosenkra@convex.com (William Rosencranz) writes: >>In article kentd@FtCollins.NCR.com (Kent.Dalton) writes: >>>>is there any inherent reason why future TOS versions can't be case [sensitive?] [heated argument deleted...] >jove.RC >jovE.rC >JoVe.Rc >JOVE.RC >jove.rc > >big deal. You have a point, and I'll add to it. Case sensitive filenames are slower and more clumsy to type out. Only when you have filename completion in your shell ('a la gulam and unix csh), or a file selector written to show extra characters (read on) does this become moot. However, your next point I DON'T agree with. >And this is just a half-assed step towards a unix-like filesystem - if you >want a real unix filesystem, you gotta throw out all this TOS and MSDOS >bullshit and start FROM SCRATCH - we don't need all these tiny little steps >which make everything incompatible but look a little more like unix - give >me a break! There is a way, using some extra bytes (I forget how many, but enough to be useful) in the directory table which are presently "reserved" (by Atari) for each filename, that could be used to put a few more characters (or other attributes) into the filenames. True, a small step, but it could be made in such a way so that it would be upwardly compatible. It would be up to the disk driver (you'd have to write a new one) to decide how to use the extra information. You could use one or two of the bytes to provide an uppercase/lowercase bitmap for the other characters and the rest as extra filename characters, for example, just use all of them for extra filename characters, or other things (file protection bits, user id, etc...). If you wanted to go whole hog, you could use the extra bytes as a FAT pointer to an invisible, locked (but vanilla TOS) file containing lots more filename information. Or to a place on the disk mapped out so that old TOS treats it like as a bad sector... I argue that you could make it so that it wouldn't necessarily be incompatible with the present 8.3 case-insensitive filename system. You could use such a disk with a normal TOS file system, just that in a directory listing, you wouldn't see the extra attributes, and in a file-file copy, the extra bytes (probably) would not be copied. If any extra bytes are used for extra filename characters (e.g. 16.3 vs 8.3), the filename would be cut off at 8. But IMHO, you would be no worse off than before. About the only problem this is likely to cause is if you are trying to use two files that have the same first 8 characters (and the same 3 char extension) on the old TOS file system. The old TOS disk driver wouldn't be able to tell the difference between them. My guess is it will probably always choose the first of the two (unless you delete it) in the directory table for whatever operation you're doing. About all you'll need to see and use the nice new filenames from within your GEM programs is a new fileselector rewritten to accomodate the larger size of filenames (at least). Some shell programs not hardwired to the 8.3 convention, especially if they were originally ported from Unix, should work w/o modifications. Even the hardwired ones might only need a few trivial changes. There are other programs that do their own filename parsing, but in general these are not the "user-friendly" programs anyway. Atari itself might want to clear up just how "reserved" they presently consider the extra bytes in the directory table. My guess is that they won't be keen on the idea, since they've been going out of their way to go in the other direction (down towards DOS compatibility). plini b -- ----- Like ls * | grep string? How about grep string (ls *) ? plinio@boole.seas.ucla.edu * Boelter Hall 4442 lab: 206-1982