Trying to design low level hard disk manipulation program
|
From: Jan Vorbrüggen on 26 Sep 2006 05:27 > JV> Case-blind case-preserving is the only variant which is acceptable > JV> from the point of view of ergonomics, IMNSHO. > Put it in user space, not the file system. No, that cannot work. 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. Jan
From: Andrew Reilly on 26 Sep 2006 05:30 On Tue, 26 Sep 2006 09:55:40 +0200, Terje Mathisen wrote: > Andrew Reilly wrote: >> Quite a lot of meta-data is stored within files, in application-specific >> formats, now. ID3 title/artist tags or sample rates in MP3 files, "meta" >> attributes in HTML files, author information in office documents. >> Alternate language soundtracks in DVD movies, perhaps (not meta-data, but >> "extra stream" information). >> >> How could this reasonably be subsumed by a file system, when the >> information must travel with the file, by the definition of the file >> format? Perhaps it is reasonable for a "file system" to expose abstract >> meta-data methods that operate on different file types through >> type-specific plug-ins that access (and modify?) the information in >> format-specific ways. Is that really a win? Is it what you are thinking >> about, or would such meta-information be duplicated from the file into >> file-system meta-data forks? How much effort would you go to to ensure >> consistency in that case? > > The examples you're using here are all more or less of the 'file system > within a single file' order. > > Until the least common denominator of file systems include all this > stuff, we'll still see the need for file formats that effectively works > as a limited/application specific file system: That's likely to be "forever", then, because several of the "file formats" that I mentioned do double duty as communication protocols, and can operate without any particular defined beginning or end, or much in the way of out-of-band data. Consider MPEG formats used in digital radio and television: just a stream of packets. > tar, zip, doc and probably a bunch of others. Yep. And most of the current crop of GUI file viewers are quite happy to look into those files and present the results as directories. Should that be made part of a file system, through a system of file-type plugins or layered mounts? That way arbitrary applications could access individual components of these collections. > Java jar files are afaik just zip files with a modified extension and > one or two added conventions for naming/content. I think so. There's some sort of manifest file, too, I think. Cheers, -- Andrew
From: Jan Vorbrüggen on 26 Sep 2006 05:34 > For coders and > systems people, the advantage of having a system that doesn't do magical > or inexplicable things on one's behalf is a much greater benefit. With the disadvantage of introducing a maintenance nightmare. We're not talking only filenames, but identifiers in programs etc. But even if it's just filenames: I have had, several times, the experience that fixing a problem took much longer than necessary because of the unexpected, counter- intiutive behaviour of Unix in this regard. Even technical people who "know" better get this wrong when it's time to look for that one letter in the "wrong" case. 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? Jan
From: Rob Warnock on 26 Sep 2006 05:43 Andrew Reilly <andrew-newspost(a)areilly.bpc-users.org> wrote: +--------------- | 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). +--------------- But they're *only* a "hint", since they're often ambiguous. For example, long before MS Windows existed, ".DOC" was used used on the PDP-10 (and elsewhere) to indicate that a file was "documentation", that is, human-readable plaintext. Even today on Unix/Linux there are several software packages that use the same convention -- that ".doc" is human-readable plaintext, *not* MS Word format. Case in point: On my FreeBSD laptop, of 226 files named "*.doc", 147 are plain ASCII text, 30 are directories(!), and only 46 are Microsoft format files. And even when ".doc" *does* mean MS Word or Office format, which *version*?!? There have been several compatibility breaks over the years. -Rob ----- Rob Warnock <rpw3(a)rpw3.org> 627 26th Avenue <URL:http://rpw3.org/> San Mateo, CA 94403 (650)572-2607
From: Nick Maclaren on 26 Sep 2006 06:03
In article <4ns9v1Fbj7t7U1(a)individual.net>, =?ISO-8859-1?Q?Jan_Vorbr=FCggen?= <jvorbrueggen(a)not-mediasec.de> writes: |> > I have used systems that did just that. |> |> I suspect so...I consider it one of the (few) things Winwoes got right. Oh, does it? I haven't used it for ages. |> > It is a negligible number of instructions, but is rather confusing - |> > consider putting a list of names into sort or uniq - should the default |> > be case sensitive or insensitive? |> |> The sort should be case-blind - which is, from my cursory testing just now, |> what Windows does. 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? Not to say how to sort out Maclaren with machinery :-) Regards, Nick Maclaren. |