Re: [Sheflug] listing sizes of directories..

["Stephen J. Turnbull" <nospam [at] sk.tsukuba.ac.jp>]

>>>>> "Al" == Alex Hudson <hudson [at] id-pro.co.uk> writes:

    Al> I know it has a standard definition currently, I was more
    Al> asking the question whether or not the current definition
    Al> holds properly with different types of filesystem we may want
    Al> - virtual, etc.  - because if it doesn't, as you say, the new
    Al> bit in question is not part of the 'filesystem'. However, we
    Al> can get around this issue by redefining 'filesystem' ;)

You're telling an economist that one way to deal with a problem is to
assume it doesn't exist?

The point is not to redefine "filesystem."  It is that Unix filesystem
semantics is often an appropriate way to present hierarchical
information structures.  If you have such a structure, then mapping it
into the filesystem is a good idea.  Viz, /proc and /dev.

The issue is that some utilities have expectations of what they'll
find in directory entries, such as semantically useful time stamps,
owners, sizes, and modes.  If a virtual filesystem does not provide
those semantics, then programs will provide garbage results.  That's
why _you_ have to worry about semantics/versions/standards.

    Al> Sorry, I've changed subject without telling you ;) I was

No, you haven't.

    Al> referring to the *files* within /proc, not the directory

Of course you're referring to the directory; the file has *no*
information about itself unless it's a directory or an object in a
very low-level OO system (ie, an OO FS).  Some of the information is
in the directory itself (name) and the rest is in the inode.  The file
is a completely different data structure.

    Al> itself. Obviously, the directory usually has a timestamp for
    Al> when it was created. I was thinking more about the semantics
    Al> of 'pushing' information (i.e., writing regularly to a proc
    Al> file to keep it up to date) not being vastly different to a
    Al> 'pull' system (i.e., dumping out the internal variables the
    Al> proc file refers to in a standard manner upon a read()).

    Al> If I don't fix them? Personally? ;))) I don't care whether
    Al> version numbers go away or not; I just don't want to have to
    Al> interact with them ;)

Suffering from a bug is an "interaction."  I prefer my interactions to
be wins, or at least repairs, rather than "lose lose lose."

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.