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/execut
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
>>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
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 possible
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
ME_{READ,WRITE,EXEC
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
> 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, no
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
mti
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 indicato
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 u
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 t
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? (Choppin
> 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)
Choppi
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
>>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
d
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
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 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
>>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/
>>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
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?
Ye
>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 f
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
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
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 fea
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 p
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 to
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
28 matches
Mail list logo
