On Thu, Apr 29, 2004 at 08:36:11AM +0300, Jarkko Hietaniemi wrote:
But for things like -r file open(FH, file) they are of rather
dubious value.
Well, I have some scripts that check at the start whether all the
things they going to need are readable/executable/whatever, so that they
can
Dave Mitchell wrote:
On Thu, Apr 29, 2004 at 08:36:11AM +0300, Jarkko Hietaniemi wrote:
But for things like -r file open(FH, file) they are of rather
dubious value.
Well, I have some scripts that check at the start whether all the
things they going to need are readable/executable/whatever,
As part of the great clean up the dangling bits sweep...
File stat stuff. Let's do:
stat [PINS]x, Sy, Iz
stat Px, Sy
where Y is the filename. Z is the stat element, and X is the value
for that element. (In the two-arg case it's an array PMC, where the
offset matches the element number in
On Wed, 2004-04-28 at 11:56, Dan Sugalski wrote:
stat [PINS]x, Sy, Iz
stat Px, Sy
[...]
The returned PMC in the two-arg case could be a hash/array pmc and
allow string-keyed access to elements. If we do that, then the names
correspond to the constant names that follow.
NAME
At 12:15 PM -0400 4/28/04, Aaron Sherman wrote:
On Wed, 2004-04-28 at 11:56, Dan Sugalski wrote:
stat [PINS]x, Sy, Iz
stat Px, Sy
[...]
The returned PMC in the two-arg case could be a hash/array pmc and
allow string-keyed access to elements. If we do that, then the names
correspond
On Wed, 2004-04-28 at 12:26, Dan Sugalski wrote:
NAME Filename, no extension or path
EXTENSION File extension
This represents a world-view that is not universal. Rather than making
Parrot into a lens through which system features need to be de-coded,
why not provide a set
At 1:33 PM -0400 4/28/04, Aaron Sherman wrote:
On Wed, 2004-04-28 at 12:26, Dan Sugalski wrote:
NAME Filename, no extension or path
EXTENSIONFile extension
This represents a world-view that is not universal. Rather than making
Parrot into a lens through which system features
On Wed, 2004-04-28 at 13:40, Dan Sugalski wrote:
ALTERNATE RESPONSE
This is where you go mad, right? :)
Usually ;-)
Why abstract within
the arbitrary constraints of a POSIX-type stat model?
I wasn't, actually. There's a good sprinkling of VMSisms in that
list, and I'm all for
Dan Sugalski wrote:
[...]
CTIME Creation time
Will unixen use this for change time? (also spelled ctime too)
OWNER_READTrue if owner can read
OWNER_WRITE True if owner can write
OWNER_EXECUTE True if owner can run
OWNER_DELETE True if owner can delete
GROUP_CD True if
From a Perl 6 language point of view, populating an array is a waste
of time. The user just wants an object that has various methods.
Some of those methods (ACLs, for instance) might be optional depending
on the roles filled by the object. New roles can be added to the
object as the concept of
At 8:08 PM +0200 4/28/04, Jerome Quelin wrote:
Dan Sugalski wrote:
[...]
CTIME Creation time
Will unixen use this for change time? (also spelled ctime too)
Nope, for that they use mtime. We can expand the names to skip the confusion.
Should be OWNER_CD?
Should be SYSTEM_CD?
Should be OTHER_CD?
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
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
s/out/that out/
At 2:01 PM -0400 4/28/04, Aaron Sherman wrote:
Keeping a niche open for ACLs is probably smart, esp. in the Windows
world.
I think you'll find ACL use is increasing, not decreasing. They've
been tacked on to most recent filesystems, and they're coming into
more widespread use as Linux is getting
At 11:39 AM -0700 4/28/04, Larry Wall wrote:
From a Perl 6 language point of view, populating an array is a waste
of time.
Who says we're populating an array? In the common case we'll be
checking individual bits (it'll be a long time before perl 6's the
common case) and in the case where we *do*
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
Keeping a niche open for ACLs is probably smart, esp. in the Windows
world.
I think you'll find ACL use is increasing, not decreasing. They've
been tacked on to most recent filesystems, and they're coming into
This is true. But good luck in trying to map between the ACL schema of
At 10:32 PM +0300 4/28/04, Jarkko Hietaniemi wrote:
Keeping a niche open for ACLs is probably smart, esp. in the Windows
world.
I think you'll find ACL use is increasing, not decreasing. They've
been tacked on to most recent filesystems, and they're coming into
This is true. But good luck in
Yech, good point. I'm not even sure you can do any sort of sane
abstraction there.
In that case, are we better off chopping it out entirely and leaving
it to library code, or making it a simple yes/no indicator that there
are some? (Chopping it out's probably the best thing)
Chopping
At 10:49 PM +0300 4/28/04, Jarkko Hietaniemi wrote:
Yech, good point. I'm not even sure you can do any sort of sane
abstraction there.
In that case, are we better off chopping it out entirely and leaving
it to library code, or making it a simple yes/no indicator that there
are some?
On Wed, 2004-04-28 at 14:51, Dan Sugalski wrote:
At 8:08 PM +0200 4/28/04, Jerome Quelin wrote:
Dan Sugalski wrote:
[...]
CTIME Creation time
Will unixen use this for change time? (also spelled ctime too)
Nope, for that they use mtime. We can expand the names to skip the
On Wed, 2004-04-28 at 15:42, Dan Sugalski wrote:
At 10:32 PM +0300 4/28/04, Jarkko Hietaniemi wrote:
I think you'll find ACL use is increasing, not decreasing. They've
been tacked on to most recent filesystems, and they're coming into
But AFAIK, Windows is the only place where the use of
On Wed, Apr 28, 2004 at 10:49:50PM +0300, Jarkko Hietaniemi wrote:
: Yech, good point. I'm not even sure you can do any sort of sane
: abstraction there.
:
: In that case, are we better off chopping it out entirely and leaving
: it to library code, or making it a simple yes/no indicator
Dan Sugalski wrote:
At 8:08 PM +0200 4/28/04, Jerome Quelin wrote:
Dan Sugalski wrote:
CTIME Creation time
Will unixen use this for change time? (also spelled ctime too)
Nope, for that they use mtime. We can expand the names to skip the
confusion.
mtime != ctime
mtime =
On top of which, ACLs suffer the same illness of any stat-based
checking, insofar as checks against them are only an approximation
to reality, potentially full of race conditions. It's really the OS
that's going to do the ACL checking, and it'll do it when you do the
actual operation, not
At 10:47 PM +0200 4/28/04, Jerome Quelin wrote:
Dan Sugalski wrote:
At 8:08 PM +0200 4/28/04, Jerome Quelin wrote:
Dan Sugalski wrote:
CTIMECreation time
Will unixen use this for change time? (also spelled ctime too)
Nope, for that they use mtime. We can expand the names to
Dan Sugalski wrote:
OWNER_READTrue if owner can read
OWNER_WRITETrue if owner can write
OWNER_EXECUTETrue if owner can run
OWNER_DELETETrue if owner can delete
GROUP_CDTrue if owner can enter this directory
Is it possible to have something along the lines of
At 4:43 PM -0700 4/28/04, Brent 'Dax' Royal-Gordon wrote:
Dan Sugalski wrote:
OWNER_READTrue if owner can read
OWNER_WRITETrue if owner can write
OWNER_EXECUTETrue if owner can run
OWNER_DELETETrue if owner can delete
GROUP_CDTrue if owner can enter this directory
Is it
Is it possible to have something along the lines of
ME_{READ,WRITE,EXECUTE,DELETE,CD} to say if, as the user the program
is running as, you can perform these actions? That strikes me as
rather useful. (Alternately, could we have a field indicating if
the current user is OWNER, GROUP, SYSTEM,
29 matches
Mail list logo
