Change Unix file permissions from a Carbon app?

[David Phillip Oster]

In article <not.here-ya02408000R3007030100130001@news.dial.pipex.com>,
[email]not.here@dial.pipex.com[/email] (Phil Taylor) wrote:

> I'm trying to invoke a Unix tool from within my CFM-Carbon app.
> To do this I can create a file containing the command line input,
> save it in the user's home directory and send an Apple event
> to the Finder to launch Terminal with the file as input.
>
> This all works fine provided that the command file is marked
> as executable by the user, but I need to do this programmatically.
> How can I perform the equivalent of chmod from within my app?

1.)
Look in <Files.h> at FSSetCatalogInfo(), and struct FSPermissionInfo


2.)
chmod is a system call. You can just call it, but you will need
to dynamicly link to Mach-O from CFM. See:


Calling Quartz Functions From a CFM Application


<[url]http://developer.apple.com/documentation/GraphicsImaging/Conceptual/Quar[/url]
tzPrimer/qprimer_main/chapter_1_section_6.html#//apple_ref/doc/uid/DontLi
nkBookID_99-DontLinkChapterID_1-TPXREF21>

for an example of doing this.

Look in the System framework for chmod().

From Terminal, do:

---------
man 2 chmod
---------

for more information.

[Phil Taylor]

In article <oster-E9E4D4.17162229072003@newssvr23-ext.news.prodigy.com>,
David Phillip Oster <oster@ieee.org> wrote:

> In article <not.here-ya02408000R3007030100130001@news.dial.pipex.com>,
> [email]not.here@dial.pipex.com[/email] (Phil Taylor) wrote:
>

> > I'm trying to invoke a Unix tool from within my CFM-Carbon app.
> > To do this I can create a file containing the command line input,
> > save it in the user's home directory and send an Apple event
> > to the Finder to launch Terminal with the file as input.
> >
> > This all works fine provided that the command file is marked
> > as executable by the user, but I need to do this programmatically.
> > How can I perform the equivalent of chmod from within my app?

>
> 1.)
> Look in <Files.h> at FSSetCatalogInfo(), and struct FSPermissionInfo
>
>
> 2.)
> chmod is a system call. You can just call it, but you will need
> to dynamicly link to Mach-O from CFM. See:
>
>
> Calling Quartz Functions From a CFM Application
>
>
> <[url]http://developer.apple.com/documentation/GraphicsImaging/Conceptual/Quar[/url]
> tzPrimer/qprimer_main/chapter_1_section_6.html#//apple_ref/doc/uid/DontLi
> nkBookID_99-DontLinkChapterID_1-TPXREF21>
>
> for an example of doing this.
>
> Look in the System framework for chmod().
>
> From Terminal, do:
>
> ---------
> man 2 chmod
> ---------
>
> for more information.

Many thanks! That looks like just what I need.

Phil Taylor

[Phil Taylor]

Hmm, still having trouble with this.

man 2 chmod

tells me that I need the value 700 to set user permissions to rwx,
and doing that manually in terminal works OK.

So I try getting the existing permissions using FSGetCatalogInfo,
with kFSCatInfoPermissions as the FSCatalogInfoBitmap parameter,
change permissions and use FSSetCatalogInfo to set the new value.

However, the permissions field of FSCatalogInfo is an array of
four UINT32s. So which do I change? The online docs say:

"permissions
User and group permission information. The Mac OS 8 and 9 File Manager does
not use or enforce this permission information. It could be used by a file
server program or other operating system (primarily Mac OS X)."

Which is not much use to me.

Experimentally, I find that setting permissions[2] to 0x700, or ORing
it with 0x700 causes FSSetCatalogInfo to return a -36 OSErr, while
changing any (or all) of the other three has no effect, leaving the
file's permissions unchanged.

Any idea what I'm doing wrong here?

I'd rather not mess with Mach-O at the moment, since that's a whole
new world.



In article <not.here-ya02408000R3007030152040001@news.dial.pipex.com>,
[email]not.here@dial.pipex.com[/email] (Phil Taylor) wrote:

> In article <oster-E9E4D4.17162229072003@newssvr23-ext.news.prodigy.com>,
> David Phillip Oster <oster@ieee.org> wrote:
>

> > In article <not.here-ya02408000R3007030100130001@news.dial.pipex.com>,
> > [email]not.here@dial.pipex.com[/email] (Phil Taylor) wrote:
> >

> > > I'm trying to invoke a Unix tool from within my CFM-Carbon app.
> > > To do this I can create a file containing the command line input,
> > > save it in the user's home directory and send an Apple event
> > > to the Finder to launch Terminal with the file as input.
> > >
> > > This all works fine provided that the command file is marked
> > > as executable by the user, but I need to do this programmatically.
> > > How can I perform the equivalent of chmod from within my app?

> >
> > 1.)
> > Look in <Files.h> at FSSetCatalogInfo(), and struct FSPermissionInfo
> >
> >
> > 2.)
> > chmod is a system call. You can just call it, but you will need
> > to dynamicly link to Mach-O from CFM. See:
> >
> >
> > Calling Quartz Functions From a CFM Application
> >
> >
> > <[url]http://developer.apple.com/documentation/GraphicsImaging/Conceptual/Quar[/url]
> > tzPrimer/qprimer_main/chapter_1_section_6.html#//apple_ref/doc/uid/DontLi
> > nkBookID_99-DontLinkChapterID_1-TPXREF21>
> >
> > for an example of doing this.
> >
> > Look in the System framework for chmod().
> >
> > From Terminal, do:
> >
> > ---------
> > man 2 chmod
> > ---------
> >
> > for more information.

>
> Many thanks! That looks like just what I need.

Phil Taylor

[Patryk 'Silver Dream !' £ogiewa]

Phil Taylor wrote:

> Hmm, still having trouble with this.
>
> man 2 chmod
>
> tells me that I need the value 700 to set user permissions to rwx,
> and doing that manually in terminal works OK.
>

[...]

>
> Experimentally, I find that setting permissions[2] to 0x700, or ORing
> it with 0x700 causes FSSetCatalogInfo to return a -36 OSErr, while
> changing any (or all) of the other three has no effect, leaving the
> file's permissions unchanged.
>
> Any idea what I'm doing wrong here?

I don't know if this helps in that particular situation but this number
is supposed to be octal, not hex, and I remember when passing e.g. 750
to mkdir(), I needed to pass 0750. Yes. The leading zero was significant.

[Patrick Stadelmann]

In article <3f27d3df$1@news.inet.com.pl>,
"Patryk 'Silver Dream !' ?ogiewa" <silverdr@inet.remove.it.pl> wrote:

> I don't know if this helps in that particular situation but this number
> is supposed to be octal, not hex, and I remember when passing e.g. 750
> to mkdir(), I needed to pass 0750. Yes. The leading zero was significant.

Sure. In C, 750 is interpreted as a decimal number and 0750 as an octal
number. The leading 0 is the equivalent of the leading 0x for
hexadecimal numbers.

Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>

[David Phillip Oster]

In article <MPG.1991e9c88c84325f989683@News.Individual.NET> ,
James Weatherley <news@weatherley.net> wrote:

> In article <Patrick.Stadelmann-1AA30D.16315930072003@news.fu-berlin.de>,
> [email]Patrick.Stadelmann@unine.ch[/email] says...

> > In article <3f27d3df$1@news.inet.com.pl>,
> > "Patryk 'Silver Dream !' ?ogiewa" <silverdr@inet.remove.it.pl> wrote:
> >

> > > I don't know if this helps in that particular situation but this number
> > > is supposed to be octal, not hex, and I remember when passing e.g. 750
> > > to mkdir(), I needed to pass 0750. Yes. The leading zero was significant.

> >
> > Sure. In C, 750 is interpreted as a decimal number and 0750 as an octal
> > number. The leading 0 is the equivalent of the leading 0x for
> > hexadecimal numbers.
> >
> > Patrick
> >

>
> And this leads to great obfuscation possiblities:

I talked to a Navy man once, who claimed that he'd worked in an
assembler that implemented the rule:

"Leading zero means base 8."

even for floating point numbers. So,

.5 was one half (five tenths)

but

0.5 was five eighths.

This created many subtle errors in the navigation software.

[Patryk 'Silver Dream !' £ogiewa]

David Phillip Oster wrote:
[...]

>
> I talked to a Navy man once, who claimed that he'd worked in an
> assembler that implemented the rule:
>
> "Leading zero means base 8."
>
> even for floating point numbers. So,
>
> .5 was one half (five tenths)
>
> but
>
> 0.5 was five eighths.
>
> This created many subtle errors in the navigation software.

.... and the Bermuda Triangle legend began. ;-)

[Phil Taylor]

OK, I figured it out (I think).

permissions[2] contains the usual set of permissions in the
low order ten bits, i.e. drwxrwxrwx, so the value I need to
OR with it to set the user permission to execute is 0x40.
700 octal would have worked too, as you pointed out. I've
still no idea what the rest of the permissions array is for
so I'll just leave it alone.

Thanks again for pointing me in the right direction.

Phil Taylor