Mail Archives: opendos/1997/05/02/08:29:35
[ 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 <tbird AT caldera DOT com> 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 '<regexp>'
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 ...
- Raw text -