Messages in this thread | | | Date | Wed, 30 Jun 1999 15:32:40 +1000 | From | Richard Gooch <> | Subject | Re: If we cannot trim subject lines... |
| |
Jamie Lokier writes: > Mark-Andre Hopf wrote: > > (a) Because it prevents the normal user from messing around with the > > internal of the `directory' and with it preventing the application > > programmer from adding tons of code to detect and workaround unexpected > > changes. > > All proposals so far don't _prevent_ the users, even normal ones, > from messing around with the internals. Frankly any reliable > application is going to have to deal with unexpected data in the > file anyway.
Indeed. Any attempt to pretend otherwise has the same intellectual rigour as security through obscurity.
> > (b) The normal user expects a `bunch of data' in a single file, not in a > > directory. > > (c) The content of the `directory' isn't of interest to the user but to some > > applications. > > These points merely argue for something that behaves like a > directory but doesn't look like one in an `ls' listing.
No, no! <ls> should see a directory-based albod as a directory. Leave it to the GIU file browser to present albods as "files".
> The only compelling reason I can see is: > > (1) Ordinary users wish to copy/move compound files as a single unit, > attach them to emails and put them on web sites.
GUI, GUI, GUI.
> Which argues for automatic conversion to/from flat form on demand. > It could be done in user space, and a kernel hook could make it > transparent for all programs.
GUI, GUI, GUI.
This is a user space problem. No kernel hooks or even libc hacks needed. Remember there are two classes of users. Power users who will want to get raw access. Then there are GUI lusers who want easy access. A scheme which puts the hacks into a special library allows both classes of user to be accommodated.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |