Trying to design low level hard disk manipulation program
|
From: David Hopwood on 26 Sep 2006 13:12 Jean-Marc Bourguet wrote: > Jan Vorbrüggen <jvorbrueggen(a)not-mediasec.de> writes: > >> [...] I asked whether there are languages that use the >>same letters, but for which the mapping between upper- and lower-case is in- >>compatible. > > Turkish has two I, one with a dot and one without. If in a Turkish locale > you ask for the lowercase of I, you get the dotless i. Treating {ı, i, I, İ} as a single equivalence class works fine. That is what the Unicode case folding algorithm does, when you include the optional foldings. -- David Hopwood <david.nospam.hopwood(a)blueyonder.co.uk>
From: Stephen Fuld on 26 Sep 2006 13:25 "Bill Todd" <billtodd(a)metrocast.net> wrote in message news:I6mdnX_I3tsGcIXYnZ2dnUVZ_rudnZ2d(a)metrocastcablevision.com... >>> 2. Various bits of the directory entry (loosly defined) for such >>> things as read only status, ownership, time of last update, etc. > > Careful: you're confusing how metadata may be managed (an > implementation-specific matter) with how it's presented to the users (an > interface-specific matter). There are good reasons why metadata whose use > behavior is understood by the system should be maintained in locations > that allow efficient processing of it. Yes, I stated this poorly. What I meant to indicate is that information such as I listed is typically accessed through a different API than information in the other catagories. Where the metadata is actually stored is not of concern at the level I am talking about. -- - Stephen Fuld e-mail address disguised to prevent spam
From: Tarjei T. Jensen on 26 Sep 2006 17:08 Jan Vorbrüggen wrote: > As a general aside, I think one of the biggest failings of Unix is that > all > of the more complex design decisions are handed off with the remark, "no, > we > won't put it into the OS, that will be handled by the user/application.". > That just doesn't work. That is true. Side note: 15 years ago they told us that within 5 years Unix would surpass VMS with regards to features, etc. Whether they call the operating system Unix or Linux, it is still stone age compared to VMS 4.7. greetings,
From: Tarjei T. Jensen on 26 Sep 2006 17:11 "Eric P." wreote: >I have never built a file system, but it seems to me that the problem >with file compression is that a write in the middle of the file >will be recompressed and can cause changes to the files' physical >block mappings and meta data structures. This in turn updates file >system block allocation tables and meta transaction logs. In NetWare the file was compressed if it was not used (or was it modified) for a certain time. Once you write it stays uncompressed until it became eligeble for compression again. greetings,
From: Andrew Reilly on 26 Sep 2006 20:17
On Tue, 26 Sep 2006 11:34:55 +0200, Jan Vorbr?ggen wrote: > And there's the other point: What value do you attach to the ability to make > this distinction carry meaning? It's OK that you would be allowed to call a > file, say, stdIO.h or stdio.h or STDIO.H - but what _semantics_ are you going > to define for the distinction if those are actually different files? I don't give a hoot about the ability to asign some (specific) semantics to the different spellings. Since the source code of the language in question is case sensitive, two of those three are just wrong, and that some file systems will mask that fact doesn't make either right, it just makes it more likely that people using such systems will make a mistake. Never mind that there was a time when one of those systems would helpfully capitalize all-lower-case file names... My concern is that there's no obvious reason that one shouldn't be required to specify a file by the name that it was given. The argument that the file system should allow for any member of an ill-defined equivelance class to match seems specious, IMO. Cheers, -- Andrew |