Reply-To: From: "The Rt. Hon. Sir Anonymous X. Fuck-the-System, VC" To: Cc: Subject: Re: A few FS notions Date: Thu, 1 May 1997 11:15:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-ID: <1349546426-55796249@diablo.eimages.co.uk> Precedence: bulk [ My apologies in advance if this turns out to be formatted like shite - I'm having to use MS Incontinent Exploder against my better judgement. Normal service will be resumed on Tuesday ;-) ] Tim Bird wrote: > A while ago I volunteered that I have been thinking about attributed file > systems for some time... > > ... One use of an attributed file system > would be to isolate name components from a fixed hierarchy, and allow for > 1) query-style searches and operations on the file system, and this I can just see it now, in SQL-DOS 1.0 ... " COPY INTO /mnt/floppy SELECT *.txt FROM /home/davidc WHERE FILE CONTAINS TEXT '' WITH OPTION RECURSE" > Some attributes that I think it would be interesting to have include: > - for a directory, aggregate disk space of all my descendants > - owner, group, access control list, etc. > - package I belong to > - security signature Is this not covered by the owner/group information? > - file that created me > - file type (in MIME? or some other standard form) > - icon Sounds like the Resource Fork in Mac HFS. That proves to be a right royal pain in the backside when transferring files between Mac and PC, and would presumably be just as painful when transferring between (for instance) Opendos and MS-DOS/Win95/NT. Anyway, the 'icon' resource is meaningless for Opendos, unless we're going to provide an Opendos-aware GUI as well. > - etc. > This list is by no means exhaustive, but gives an example of the types > of things that could be kept. Some of these attributes only make sense > if you have an appropriate file system monitor installed which can track > the information (like the directory disk space attribute) The FS driver could be intelligent enough to update the parent attributes whenever a child was modified. No extra software needed. > It sure would be nice to be able to index the file system by any > particular attribute, so that a different hierarchical view could be > synthesized on demand. For example, I'd like to be able to generate > a tree of directories where each directory at the root was the month, > then each subdirectory was a day, and the files would appear in the > appropriate subdirectory based on their last modification time (or > creation time). This would make finding a file based upon the last > time I edited it (or created it) easier. Or I'd like to see a tree where > the top directories were the packages installed on the system, and the > files were listed each under its owning (or creating) package. How about a cmdline tool which would sort the directory entries IN THE FAT for you, based upon your criteria? That way, you could simply do a DIR in directory X and get files sorted by extension, in directory Y and get files sorted by last-access date, and so on. I use a horrible combination of 4DOS aliases to fake this per-directory configurable sort-order at the moment. Of course, the user-imposed defaults could be over-ridden temporarily, by asking DIR to sort differently. I suppose it would be safer to have this as an attribute of the directory, but that would not be as flexible. By re-ordering the FAT entries, you could sort files by their contents, for instance. > Also, with a generic name, value pair syntax, > a generic utility could be created to hand-manipulate an attribute, if > necessary or desirable. How about calling it RESEDIT? ;-) > Thanks for listening. Thanks for stimulating some ideas! I'm off to hack around with re-ordering my FAT ...