Andrew Clausen wrote:
On Sat, Jan 12, 2002 at 07:48:23PM +0100, Xuan Baldauf wrote:
Why would they rely on using foo.jpeg/thumbnail.png, as opposed to
foo.jpeg/thumbnail.png/content?
Because there is a contract between the application and the filesystem that some
entity (e.g. a file) can be found again using the same name which was used on
creation of that entity.
I agree, but I don't see how this is inconsistent.
If you just store thumbnail.png (as opposed to thumbnail/content),
then there is no possibility of adding attributes.
That's the point. :-) There shall be the possibility of adding attributes to files and
there shall be files being accessible by using the same name as used before, so, for
complying to both requirements, there must be a possibility of adding attributes to
files without requiring to rename them.
Why not support both options? If a file is a file, it's a file. (*grin*)
If a file is a directory with /content, then it's also a file ;)
That's my point. If attributes of files are implemented as directories, accessing
those files with attributes must be downward compatible. If redirecting an
open(foo.jpeg);
to an
open(foo.jpeg/content);
within the kernel if foo.jpeg got changed to be an directory is possible and
efficient, that could be okay from that viewpoint.
It seems better to implement this in user space. libgnomevfs, or something
like that.
What does name mean in this context?
The text string to access the same data which was stored using the same name some
time ago. So requiring the application to change
open(foo.jpeg);
to
open(foo.jpeg/content);
All problems in software engineering can be solved by adding another
layer of indirection TM
Basically: on the shell, etc., I want to see foo/content as a directory
containing a file. When I use GNOME, I want to be able to see it both
ways. For applications that don't adopt this, no big deal... just pass
them file/content, instead of file.
I agree with you that this could be done in userspace, but
(1) It has to be done below the application level (e.g. glibc), not higher (like
GNOME), because all the tools (tar, cp, etc.) _must_ still be able to open foo.jpeg
if it has morphed into foo.jpeg/content using the same name.
(2) It will slow down disk accesses, because for every attributed file, there will be
two calls needed to access the file. But this can be optimized by kernel support and
changing glibc appropriately at a later stage of distribution of attributes.
(3) What do you do with attributes of directories? There are conventions for UNIX-style
filesystems that the number of subdirectories within a directory is the link count of
that directory - 2. This convention might be changed if attributes of directories are
implemented as entries of that directories. A glibc-implementation could reimplement
stat to return the conventional link count at the cost of a subdirectory scan and the
associated performance penalty, though.
(4) There will be some glitches, like the atomic rename(2), which by definition
automatically unlinks the destination file if it exists in one step. If implemented in
userspace, there won't be atomic rename-over-attributed-files.
After all, implementing within glibc sounds feasible for me and the only semantic
drawback is the missing atomicity of rename(). This is not the fault of glibc per se,
but the missing transaction API between kernel and userspace. Even the filesystem
namespace occupied for attributes can be hidden by a glibc implementation which escapes
names used by applications which would denote an attribute if read by glibc again.
This implementation would be inefficient but portable. Note that I still see this
implementation only as a transitional implementation until native kernel and filesystem
support is available.
Andrew
Xuân.
--
Mit freundlichen Grüßen
Xuân Baldauf
Medium.net Internet Server Software
