File stat info - perl.perl6.internals

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
perl.perl6.internals
Message from discussion File stat info
Newsgroups: perl.perl6.internals
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Mailing-List: contact perl6-internals-h...@perl.org; run by ezmlm
Mime-Version: 1.0
Message-ID: <a06100519bcb5afaa3a26@[10.0.1.3]>
In-Reply-To: <408FFD90.5080402@iki.fi>
References: <a06100508bcb580d740bf@[10.0.1.3]>	
 <1083168925.4822.1201.camel@pps>  <a0610050cbcb58a1f6db2@[10.0.1.3]>
 <1083173629.4816.1255.camel@pps> <a06100513bcb59c50b126@[10.0.1.3]>
 <408FFD90.5080402@iki.fi>
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"
Approved: n...@nntp.perl.org
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
>>  itself)
>
>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
>[1], 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
>thousand!)

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
>
>   owner
>   group
>
>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,
>though.)

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

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
