RE: Xcode default "Install Permissions", clean "permission denied"
RE: Xcode default "Install Permissions", clean "permission denied"
- Subject: RE: Xcode default "Install Permissions", clean "permission denied"
- From: "Alex Sheh" <email@hidden>
- Date: Wed, 22 Aug 2007 18:54:20 -0700
- Thread-topic: Xcode default "Install Permissions", clean "permission denied"
The main issue is that when I try to clean the configuration, Xcode
needs to be able to "rm" the previously built Bundle.app. However,
Xcode can't do this because the folders aren't writable, and the clean
fails. So basically developers can't clean from within Xcode and have
to manually remove the folder themselves, which doesn't make for an
efficient workflow.
-----Original Message-----
From: Kyle Sluder [mailto:email@hidden]
Sent: Wednesday, August 22, 2007 5:36 PM
To: Alex Sheh
Cc: James Bucanek; email@hidden
Subject: Re: Xcode default "Install Permissions", clean "permission
denied"
Try this in Terminal: create a directory called lvl1, and create a
directory inside that called lvl2. Change the permissions to 555
(dr-xr-xr-x) for both of them. Then try "rm -r undel". rm will first
descend into lvl1 and attempt to remove lvl2, but will fail because you
don't have write permission for lvl1. Then it will attempt to remove
lvl1 but fail for the same reason. You cannot remove non-empty
directories in UNIX, so any attempt to remove a non-empty directory for
which a user lacks write permission will fail. This can lead to some
confusion when a user attempts to delete an application from
~/Applications (which, remember, is a perfectly valid place to keep
apps). Of course the user has write permission for ~/Applications, so
what's the problem? For this reason, Finder uses a setuid utility to
prompt for a password and delete things.
Perhaps you should evaluate whether it is critical that the file's owner
not be allowed to modify the contents of the bundle. If you do
determine that you must not allow the user to modify the contents of the
bundle, then you're stuck.
--Kyle Sluder
On 8/22/07, Alex Sheh <email@hidden> wrote:
> Thanks for the information regarding the write permission of the
> containing directory.
>
> The problem is that when I check Deployment PostProcessing, and use
> "Install Permissions" a-w,a+rX, the permissions are recursively
> applied to every folder and file from the Bundle.app on downwards. It
> sounds like this doesn't happen to your projects, and I'm not sure
> what the difference is between our configuration settings.
>
> - Alex
>
> -----Original Message-----
> From: James Bucanek [mailto:email@hidden]
> Sent: Tuesday, August 21, 2007 8:36 PM
> To: Alex Sheh
> Cc: email@hidden
> Subject: Re: Xcode default "Install Permissions", clean "permission
> denied"
>
> Alex Sheh <mailto:email@hidden> wrote (Tuesday, August 21,
> 2007 5:01 PM -0700):
> >In my Deployment configuration, I have checked "Deployment
> >Postprocessing", which activates the default Install Permissions
> >"a-w,a+rX". I'm able to build the product the first time, but when I
> >try to clean, I get "permission denied" (since the install
> >permissions set the writable bit to OFF).
> >I could change the "Install Permissions" so that the writable bit is
> >ON, but then my application files would be writable.
>
> Whether a file can be deleted or not is controlled by the write
> permission of the directory that contains it, NOT the write permission
> of the file.
>
> I can't really advise you on your problem because I've never seen this
> -- and I have many projects with Deployment Postprocessing turned on,
> and all of those projects produce read-only files.
>
> But I suggest you examine the permission and ownership of the
> enclosing folders. I suspect that this is where your problem lies.
>
>
>
> James Bucanek
> ____________________________________________________________________
> Author of Beginning Xcode ISBN: 047175479X
> <http://www.beginningxcode.com/>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
> .com
>
> This email sent to email@hidden
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden