>>Oh, don't get me wrong! I'm not saying an abstraction isn't all keen andsuch, 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 thatlist, 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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
