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> The point is, "filesystem" might need to be redefined if the
    Al> semantics become meaningless, or half-meaningless at best.

This isn't going to happen.  Files are still going strong on all
systems I know of!

    Al> I'm not convinced a virtual filesystem necessarily shares
    Al> 'time-stamps' in the same manner a physical filesystem,
    Al> especially if it is an informational system, such as proc, or

Well, I think you'd be surprised at how useful it could be if the
implementors only had the imagination to put it in.

Eg, personally, I think it would be a good idea if stuff like
/proc/sys/net/ipv4/ip_forward reflected the last time they were set.
Sure, a lot of the stuff in /proc/1 (etc) will be up to the jiffy, but
other stuff is not.  For example, the creation time for /proc/1234
should reflect the time the process was created.  I'm not sure what
modification and access times should reflect, but I can imagine useful
applications (eg, some way of determining how long the process has
been sleeping/waiting on IO or whatever).

    Al> representing some other such non-file-but-data-all-the-same
    Al> objects..

Please call it something else if you want to change the semantics.
That's all I'm saying.

    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> That's nit-picking - the relationship is between the data and
    Al> the file, not the data and the directory. The file then has a
    Al> relationship with the directory. Although the directory may be
    Al> the store of such information, that's an implementation
    Al> issue. It doesn't matter where the data is stored.

It is _not_ nitpicking.  It's the core of the whole discussion.  Eg,
Unix file system semantics are responsible for all of the root
exploits based on race conditions, including the one that causes the
restriction on suid shell scripts.  There would be no problem if the
file itself carried the permissions.  It is the fact that the file
does _not_ carry the permissions that makes symlinks dangerous here.

There are reasons to suppose that within the decade advanced systems
will migrate to a new, non-Unix filesystem semantics.  These systems
will probably not be represented hierarchically, but rather as an OO
database.  It's not clear what will happen to these virtual
filesystems as that progresses.  They may migrate easily (especially
since the OO FS of the future will probably be able to emulate the
desirable behaviors of the Unix VFS).  But more likely they will
mutate drastically to take advantage of the OO capabilities.

    Al> All I was saying was, it can go on if it wants, just do it
    Al> behind my back ;) Not a philosophy I expect you to share ;)

No, I don't.  These bugs carry knives ... no way I'm turning my back
on them!


-- 
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.