Trying to design low level hard disk manipulation program
|
From: Jan Vorbrüggen on 26 Sep 2006 06:07 > Er, how does it know that you are putting in file names? Yes, there is > a kludge that works moderately well for both case-sensitive and case- > insensitive for sort, but what about uniq? Miscommunication - I thought you were talking of the file browser which knows that it can do a case-blind compare. Obviously, for other cases tools such as sort and uniq will need to be told of such constraints. What default? Dunno. Jan
From: =?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?= on 26 Sep 2006 06:13 Benny Amorsen <benny+usenet(a)amorsen.dk> wrote: > One special case is ? which can be alternatively spelled Aa in Danish. > A case-insensitive file system really ought to forbid having both > Aalborg and ?lborg as file names in the same directory. As far as I > know, no system has gone that far. (I wonder if any system even gets > the sorting right: a is before b is before aa is the same as ?). Case is not an alternate spelling. -- Mvh./Regards, Niels J?rgen Kruse, Vanl?se, Denmark
From: Brian Inglis on 26 Sep 2006 06:23 On Mon, 25 Sep 2006 09:52:55 -0600 in alt.folklore.computers, Anne & Lynn Wheeler <lynn(a)garlic.com> wrote: > >Bill Todd <billtodd(a)metrocast.net> writes: >further work on the full record access traces started to show up some >amount of repeated patterns that tended to access the same collection >of files. for this collection of data access patterns, rather than >disk arm motion with various kinds of distribution ... there was very >strong bursty locality. this led down the path of maintaining more >detailed information about files and their useage for optimizing >thruput (and layout). VMAP/VMMAP (IBM VM Monitor Analysis Program) seek traces combined with minidisk maps made it easy to identify hotspots and contention. Doing something about it required manually emulating a disk defragger working across all drives (if you trusted tape as little as I did). -- Thanks. Take care, Brian Inglis Calgary, Alberta, Canada Brian.Inglis(a)CSi.com (Brian[dot]Inglis{at}SystematicSW[dot]ab[dot]ca) fake address use address above to reply
From: Terje Mathisen on 26 Sep 2006 06:53 Bill Todd wrote: > Andrew Reilly wrote: > Is it what you are thinking >> about, or would such meta-information be duplicated from the file into >> file-system meta-data forks? > > That sounds like an implementation detail, and I'm a firm believer in > letting the mechanism match the problem (e.g., storing a one-byte > metadata value should probably be done differently from storing a 100 MB > metadata value, just as is the case with small vs. large data forks). As > for how metadata is presented to the outside world, bundles (which sound > similar to what you may mean by 'meta-data forks') seem like one good > option. If we must have this, then I would strongly prefer to have them visible and accessible as virtual directory structures: I.e. attribute "creator" of file "foo" could be read by 'cat foo/creator' or possibly 'cat foo.meta/creator' Allowing regular file/directory operations to create/read/write/modify these attribute streams seems like the obviously Right Thing (tm) to do. It also has the great advantage of being almost transparently portable to any hierarchical filesystem, modulo performance. Terje -- - <Terje.Mathisen(a)hda.hydro.com> "almost all programming can be viewed as an exercise in caching"
From: Ketil Malde on 26 Sep 2006 07:37
Andrew Reilly <andrew-newspost(a)areilly.bpc-users.org> writes: > Aren't file extensions exclusively a file-type hint, rather than a > preferred application hint? What are some common file extensions that can > be used for different types of file? I can open .doc files with four or > five different applications, these days (with varying degress of success, > admittedly). I believe .doc files can ('could' is probably more appropriate) contain RTF content? -k -- If I haven't seen further, it is by standing in the footprints of giants |