>>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.) (The first person to suggest duplicating the File::Spec API will be hung upside down above the scorpion pit.) > 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.) Hmmm... something like this is about the minimum: name canI (method/callback that can be called with r/w/x/d) size type (method/callback that can be called with file/directory/other) 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!) [1] The POSIX bits cannot even be mapped 100% to many ACL schemes. After those come maybe the rtime wtime (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.) All the rest in the POSIX stat (dev, ino, nlink, rdev, ctime, blksize, blocks) are somewhat unportable to varying degrees.
