Message from discussion File stat info
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-intern...@perl.org
Received: (qmail 46128 invoked from network); 28 Apr 2004 19:13:18 -0000
Received: from x1.develooper.com (126.96.36.199)
by onion.develooper.com with SMTP; 28 Apr 2004 19:13:18 -0000
Received: (qmail 32217 invoked by uid 225); 28 Apr 2004 19:13:17 -0000
Received: (qmail 32208 invoked by alias); 28 Apr 2004 19:13:17 -0000
X-Spam-Status: No, hits=0.0 required=7.0
Received: from 188.8.131.52.snet.net (HELO sprite.sidhe.org) (184.108.40.206)
by la.mx.develooper.com (qpsmtpd/0.27.1) with SMTP; Wed, 28 Apr 2004 12:13:16 -0700
Received: (qmail 12844 invoked from network); 28 Apr 2004 19:13:03 -0000
X-Scanned-By: AMaViS-ng at sidhe.org
Received: from unknown (HELO ?10.0.1.3?) (d...@220.127.116.11)
by 18.104.22.168.snet.net with SMTP; 28 Apr 2004 19:12:59 -0000
Date: Wed, 28 Apr 2004 15:12:49 -0400
To: Jarkko Hietaniemi <j...@iki.fi>, perl6-intern...@perl.org
Subject: Re: File stat info
Cc: Aaron Sherman <a...@ajs.com>,
Perl6 Internals List <perl6-intern...@perl.org>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Spam-Rating: onion.develooper.com 1.6.2 0/1000/N
From: d...@sidhe.org (Dan Sugalski)
At 9:53 PM +0300 4/28/04, Jarkko Hietaniemi wrote:
> >>Oh, don't get me wrong! I'm not saying an abstraction isn't all keen and
>>>such, I'm just wondering why we're abstracting farther out than POSIX
>>>when "the right way", as you point out has never been a matter of
>>>consensus, and many client languages will be presenting POSIX semantics
>>>through their standard libraries anyway, which they will have to massage
>>>your representation back into.
>> Which is why I'm fine with yanking all the filename mangling stuff
>> from stat here.
>I would recommend leaving out from stat()ish layer. An API not
>dissimilar to Path::Class would the mangly bits would be rather nice.
>(Though it doesn't do "extensions" IIRC.)
Good 'nuff. They're history. I shall blame them on too much blood and
tool ittle sugar in my caffeine stream. :)
> > I wasn't, actually. There's a good sprinkling of VMSisms in that
>> list, and I'm all for adding more stuff if need be. (I forgot to note
>> the various flavors of symlink, as well as the link count in cases
>> where it can be determined, as well as user and group of the file
>While I'm all for supporting cool stuff like ACLs or builtin MIME-types
>(a la BeFS), I doubt the feasibility of supporting them in a portable
>way. Rather I'd personally go for a minimal set of properties. (So
>minimal that even reporting the POSIXish mode bits would be too much
>, the "canI" interface is the minimum for the rights, I think.)
I was aiming more towards presenting tasks, rather than properties.
All the filesystems have hacks in them in one form or another--the x
bit in unix filesystems with its different semantics for files and
directories comes to mind.
I'm thinking that rather than presenting as little information as we
can, we present functions and say whether we can or can't do that
function. Systems synthesize the answer as they can, and return
invalid for things they can't. S0, for example, on systems with no
backup time marker the backup time returns -1 (or 0, or an
exception--we can hash that out) while OWNER_CD checks the
directory's X bit on unix systems and READ on VMS systems, or
something like that.
>The size would in bytes, but the name already is a bit tricky... don't
>say "bytes" because e.g. Windows NTFS and Apple HFS+ are full Unicode
>beasts when it comes to filenames. So we need to solve what is a
>"string" first... :-) (Dan, please put *that* down and count to one
Name is a string, and we'll leave it at that. (They're abstract.
Really! :-P ) Besides, if I probe any deeper you'll tell me there are
systems that return filename strings based on the system's locale and
we may get handed Latin-9 names, and I know I'll regret that.
>(atime and mtime in POSIX). ctime is not portable. Creation time is
>not available in POSIX. But for these we need to decide on the epoch
>issue and granularity.
>After those maybe the
>But how to return these portably? Numeric UIDs and GIDs suck for
>systems that have username strings (my understanding is that Windows
>is like this, the mapping to numbers is "faked" - I may be wrong here,
I can see having dual versions of some of these--ask for an int and
you get the UID, ask for a string and you get the name. Ick, though.
>All the rest in the POSIX stat (dev, ino, nlink, rdev, ctime, blksize,
>blocks) are somewhat unportable to varying degrees.
Yeah, but synthesizable, so that's OK. Well, sorta, if you assume
that "no, I'm not telling" counts as synthesizing some of the data....
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk