File stat info
Dan Sugalski
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 the three arg case) Whether an
element returns a string, int, or float depends on what it is.
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 Filename, no extension or path
EXTENSION File extension
PATH File path
DEVICE Device file is on
SIZE Filesize
ISDIR True if is a directory
ISDEV True if is a device
CTIME Creation time
MTIME Last modified time
ATIME Last accessed time
BTIME Last backup time
OWNER_READ True 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 owner can enter this directory
GROUP_READ True if group can read
GROUP_WRITE True if group can write
GROUP_EXECUTE True if group can execute
GROUP_DELETE True if group can delete
GROUP_CD True if group can enter this directory
SYSTEM_READ True if system/root/admin can read
SYSTEM_WRITE True if system/root/admin can write
SYSTEM_EXECUTE True if system/root/admin can run
SYSTEM_DELETE True if system/root/admin can delete
GROUP_CD True if group can enter this directory
OTHER_READ True if anyone can read
OTHER_WRITE True if anyone can write
OTHER_EXECUTE True if anyone can run
OTHER_DELETE True if anyone can delete
GROUP_CD True if anyone can enter this directory
UMASK System bitmask for privs
ACL_LIST An array PMC with the ACL list for this file
If there's stuff missing, let's add it to the list, then we can
assign numbers and appropriate return types.
I can see adding in a separate op for priv testing on files, something like:
canI Ix, Sy, Iz
where X is true or false, Y is the file, and Z is read, write,
execute, delete, or cd, so we don't have to figure out a way to walk
ACL lists when all we want to know is "Can I write to the damn file
or not?" and leave it to the system to sort out the privs there.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Aaron Sherman
> 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 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 of modular native-friendly tools with which to
perform such operations?
After all, in UNIX-land you can't know what the "extension" is (just
look at the filenames "auto.home", ".bash_logout" and "foo.tar.gz").
If you have a POSIX view by default, but provide a set of opcodes that
specialize in Win32, Darwin, VMS, PalmOS, then you can avoid these
points of confusion.
Heck, you might even provide this abstraction as yet another layer, if
it's really helpful. But most languages/system libraries that don't come
out of Microsoft expect a POSIX view of the world, so that's probably a
reasonable default.
--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Dan Sugalski
>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 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 of modular native-friendly tools with which to
>perform such operations?
Because you end up with 78 kinds of portability hell if you don't, as
everyone rolls their own way to handle this. (And I realized I forgot
VERSION as an entry in that list)
Whether pulling out a name and extension's a good thing or not
doesn't much matter, as people do it regardless, so we might as well
do it properly. OTOH, I can certainly see a good case for not doing
it at all and yanking all the filename stuff. That's fine too, and if
that's what you're proposing I can go either way, depending on how
folks weigh in. (Though I think I'll agree with you and yank them,
unless there's reason put forth to not do so)
I'm OK with adding a TYPE to the stat array as well, though more for
an "it's a file/socket/device/directory" type thing, rather than an
"it's an application/x-pdf file!" thing.
Aaron Sherman
> >> 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 of modular native-friendly tools with which to
> >perform such operations?
>
> Because you end up with 78 kinds of portability hell if you don't, as
> everyone rolls their own way to handle this.
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.
> I'm OK with adding a TYPE to the stat array as well, though more for
> an "it's a file/socket/device/directory" type thing, rather than an
> "it's an application/x-pdf file!" thing.
Well, since no OS I know of except for MacOS/Darwin has a reliable way
to determine the ACTUAL type of a file, that's wise.
##########################################
ALTERNATE RESPONSE
You didn't go far enough. Leave stat alone, back up 12 paces and write a
vfs layer for Parrot that comes in at a level of abstraction WAY above
the core POSIX/Win32/etc ops and provides a generic way to access URIs,
mailboxes, files, shared memory regions, etc, etc. Why abstract within
the arbitrary constraints of a POSIX-type stat model? Why assume that
something has a "name" rather than a "locator"? Why not provide an
abstract concept of type that encompasses all of MIME? Why not have
permissions/ACL/security be a totally separate object which can
understand SSL/TLS authentication models, pam, etc.?
The obvious response is that you want to ship Parrot before the Y3k bug
becomes a problem ;-) I understand that, and perhaps that's a reason to
speculate about such a best, but implement after 1.0, but that doesn't
invalidate the point.
Dan Sugalski
>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 of modular native-friendly tools with which to
>> >perform such operations?
>>
>> Because you end up with 78 kinds of portability hell if you don't, as
>> everyone rolls their own way to handle this.
>
>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'm OK with adding a TYPE to the stat array as well, though more for
>> an "it's a file/socket/device/directory" type thing, rather than an
>> "it's an application/x-pdf file!" thing.
>
>Well, since no OS I know of except for MacOS/Darwin has a reliable way
>to determine the ACTUAL type of a file, that's wise.
MacOS does, Darwin doesn't, really. Or, rather, it's got the same
sort of half-assed way of doing things as Windows does, with the
extra layer of Unix file checking.
>##########################################
>
>ALTERNATE RESPONSE
This is where you go mad, right? :)
> 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 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)
Aaron Sherman
> >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 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)
Yeah, noticed the VMSism (ACLs, version (mentioned later), a separate
change dir bit), and being an old VMS hacker I approved in spirit, if
not in action. VMS was nice for when it was used. It's too bad it's
being maintained as a legacy now, and not the OS it could have been.
If you scrap the places that you've factored out things that will have
to be un-factored in the common case (filenames were the biggie), it's
fine... just don't expect people to do anything with it except extract
the POSIX semantics... after all, it took 15 years to get to the point
that POSIX could unify file semantics as much as it did....
Keeping a niche open for ACLs is probably smart, esp. in the Windows
world.
Jerome Quelin
[...]
> CTIME Creation time
Will unixen use this for change time? (also spelled ctime too)
> OWNER_READ True 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 owner can enter this directory
Should be OWNER_CD?
> SYSTEM_READ True if system/root/admin can read
> SYSTEM_WRITE True if system/root/admin can write
> SYSTEM_EXECUTE True if system/root/admin can run
> SYSTEM_DELETE True if system/root/admin can delete
> GROUP_CD True if group can enter this directory
Should be SYSTEM_CD?
> OTHER_READ True if anyone can read
> OTHER_WRITE True if anyone can write
> OTHER_EXECUTE True if anyone can run
> OTHER_DELETE True if anyone can delete
> GROUP_CD True if anyone can enter this directory
Should be OTHER_CD?
Jerome
--
jqu...@mongueurs.net
Larry Wall
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 files mutates over time, or as people derive
from the base class. There are no ordering dependencies between the
methods as there are between array elements. Some of the methods can
pull things directly out of the underlying stat structure. Some of
the methods synthesize values. Encapsulating such decisions are what
objects were invented for...
I realize that you're talking at a lower level than that, but it sounds
kind of like you're making the Perl 5 mistake of synthesizing a bunch
of values the user might not be at all interested in. If the user
doesn't ask for the extension, why go out of your way to compute it?
Larry
Jarkko Hietaniemi
>>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.
Dan Sugalski
>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?
Yep. Cut'n'paste error. :(
Jarkko Hietaniemi
>>from stat here.
>
>
> I would recommend leaving out from stat()ish layer. An API not
s/out/that out/
Dan Sugalski
>
>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 really decked out for
mission-critical usage and the facilities are pushed out for everyone
to use.
They're certainly important for AIX, Solaris, Tru64, and HP/UX.
(Whether those are useful in themselves is a separate question, of
course...)
Dan Sugalski
>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* return an array PMC,
well... who says it's real? Easy enough to make the returned PMC have
the appropriate magic get routines to defer lookup.
Dan Sugalski
> >>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 Sugalski
> >>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
>
>different systems :-(
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)
Jarkko Hietaniemi
>>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
different systems :-(
> more widespread use as Linux is getting really decked out for
Jarkko Hietaniemi
> 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 off sounds like less coding :-)
I think the same general KISS approach applies here that you chose with
the time handling - no need to implement calendar algorithms in Parrot
lowest layer, so I don't think trying to abstract Universal ACL schema
is a priority. If someone after Parrot 1.0 wants to implement Tibetan
lunar calendar or POSIX 1.e ACLs in IMC, let them. The operative word
being "them".
--
Jarkko Hietaniemi <j...@iki.fi> http://www.iki.fi/jhi/ "There is this special
biologist word we use for 'stable'. It is 'dead'." -- Jack Cohen
Dan Sugalski
> > 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 off sounds like less coding :-)
>
>I think the same general KISS approach applies here that you chose with
>the time handling - no need to implement calendar algorithms in Parrot
>lowest layer, so I don't think trying to abstract Universal ACL schema
>is a priority. If someone after Parrot 1.0 wants to implement Tibetan
>lunar calendar or POSIX 1.e ACLs in IMC, let them. The operative word
>being "them".
Mmmm, point. OK, death to ACLs!
Aaron Sherman
> 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.
*scratch head*... I'll dig out a man-page 'cause I don't want to sign on
to the POSIX site just this sec:
time_t st_atime; /* time of last access */
time_t st_mtime; /* time of last modification */
time_t st_ctime; /* time of last change */
There's no creation time listed, and mtime and ctime are most certainly
not the same thing. Now, if you want to add a creation time, that's
fine, but I recommend against calling it ctime, as that's a sort of well
defined word in these parts.
> >Should be OWNER_CD?
> >Should be SYSTEM_CD?
> >Should be OTHER_CD?
>
> Yep. Cut'n'paste error. :(
I didn't even see that. Being dyslexic, my eye skips over that kind of
error very easily. I just see it as my own mistake ;-)
Aaron Sherman
> 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 ACLs is encouraged
in the native API. Everywhere else I look, they seem to be an add-on
that you can use if you want to tie yourself to a particular set of
extensions. This is why, for example, AIX has had ACLs forever, but I
can't name one product that uses them (other than backup and restore
software ;-)
> >This is true. But good luck in trying to map between the ACL schema of
> >different systems :-(
>
> Yech, good point. I'm not even sure you can do any sort of sane
> abstraction there.
Sure you can. It's just at a much higher level of abstraction than stat.
You could very easily say "this is a file permission object" and ask it
"can I do X to this file?" or "can <user> do X to this file" where
<user> might be a process or uid_t or whatever.
That's perfectly reasonable as a core system abstraction layer, I was
just waving the "keep the native access too" flag, since I've seen too
many systems abstract away the native system to the point that no
reasonable integration can occur between the language and its
surroundings (e.g. Java).
Jerome Quelin
> 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 = modification time = last time file content changed
ctime = change time = last time inode changed (iirc)
Jerome
--
jqu...@mongueurs.net
Larry Wall
: > Yech, good point. I'm not even sure you can do any sort of sane
: >
: > 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 off sounds like less coding :-)
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 the stat() call. Arguably a "correct" way to
program is to ignore stat-like stuff entirely and just try to do the
thing you want to do, and be prepared for the OS to reject it--which
you should have been prepared for anyway...
(Of course, fstat() does help with some of the race conditions by
intentionally "losing" the race, as it were.)
Larry
Jarkko Hietaniemi
> 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 the stat() call. Arguably a "correct" way to
> program is to ignore stat-like stuff entirely and just try to do the
> thing you want to do, and be prepared for the OS to reject it--which
> you should have been prepared for anyway...
Yup. <cue in Nike slogan>
Dan Sugalski
>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 = modification time = last time file content changed
>ctime = change time = last time inode changed (iirc)
Ah, it's been far too long since I looked at this stuff. I'll expand
the abbreviations, and split out metadata change and file contents
change times.
Brent 'Dax' Royal-Gordon
> OWNER_READ True 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 owner can enter this directory
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, or OTHER to this file? Gives you pretty
much the same info.)
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
Dan Sugalski
>Dan Sugalski wrote:
>>OWNER_READ True 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 owner can enter this directory
>
>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, or OTHER to this file?
>Gives you pretty much the same info.)
Sure, that works, and I can see it being as useful as the other
permission testing stuff. (Which, arguably, is actually really really
useless, but that's a separate issue. We could, I suppose,
unconditionally return 'true' for all of these...)
Jarkko Hietaniemi
>>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, or OTHER to this file?
>>Gives you pretty much the same info.)
>
> Sure, that works, and I can see it being as useful as the other
> permission testing stuff. (Which, arguably, is actually really really
> useless, but that's a separate issue. We could, I suppose,
Well, not *completely* useless... things like -w have their uses in e.g.
- warning the user before trying an operation
- "ls -l" or any other textual representation of "rights"
- checking the filesystem "rights" against some description of how
things should be
But for things like -r "file" && open(FH, "file") they are of rather
dubious value.
Dave Mitchell
> 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 (mostly) bomb out right at the start rather than failing halfway
through and leaving a mess.
--
This email is confidential, and now that you have read it you are legally
obliged to shoot yourself. Or shoot a lawyer, if you prefer. If you have
received this email in error, place it in its original wrapping and return
for a full refund. By opening this email, you accept that Elvis lives.
Jarkko Hietaniemi
> 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 (mostly) bomb out right at the start rather than failing halfway
> through and leaving a mess.
That is more like the case "checking a set of files against some
predefined set of properties" than the above more "immediate" testing.