Messages in this thread | | | Date | Thu, 01 Jul 1999 12:24:00 -0600 | From | Larry Butler <> | Subject | Re: we missed something wrt albods |
| |
Rik van Riel wrote: > > What we need is a way to have _both_ possibilities. Even a > (gross) hack to do both is better than to run into the problem > you paint above. > > Maybe we want to just list "file" as a standard file with the > dir listing but be able to open "\file" as an albod directory > when we ask for it. Most (almost all) non-albod-aware programs > have the possibility of explicitly entering a file/dir name to > perform an action on so it will just be a minor inconvenience > while some system tools will be converted. > > Besides, when you use file/logo.gif the system doesn't have > to guess what you want to do so it'll be not that much of a > problem once we've got a method in place of accessing an albod > in both ways.
So, I see no way that this can be transparent to the user with non-albod-aware applications.
Just imagine:
$ ls -l total 2 -rw-r--r-- 1 larry users 13 Jul 1 11:59 file.c ls $ ls -l \\file.c\ total 6 -rw-r--r-- 1 larry users 789 Jul 1 12:02 default -rw-r--r-- 1 larry users 456 Jul 1 12:02 fancy-editor-saved-state -rw-r--r-- 1 larry users 123 Jul 1 12:02 icon $ vi \\file.c/default (a big pain) $ gcc \\file.c/default (oh no, gcc doesn't even know its a .c file!)
Nobody will use this for files that don't strictly have to be in albod format unless *everything* is albod-aware. Otherwise it will be a big pain no matter where it is implemented.
As for applications that are written specifically to use albods, they could just as easily use a fancy file format and not be limited to one FS on one OS.
-Larry
- 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/
| |