On 8 Aug 2011, at 16:02, Kyle Sluder wrote:
On Aug 8, 2011, at 4:54 AM, Chris Ridd chrisr...@mac.com wrote:
Does OS X really support the sticky bit? Lion's sys/stat.h suggests no,
though this line could be read a couple of ways:
Yep, it's supported and used on directories. Don't think
On Aug 7, 2011, at 10:07 PM, Stephen Blinkhorn wrote:
It's a validation file containing registration details. My product is an
AudioUnit plugin so there's no App Store potential but I'd prefer to keep
things clean just in case.
I don't care where I write the file much (previously I wrote
Some apps, including iTunes, using /Users/Shared/ for DRM. It may still be
world-writable in Lion [which I can't confirm as I haven't switched
yet...come on 10.7.2...].
I can confirm /Users/Shared is world writable on 10.7; besides, it has the
sticky (8) bit set, just like /tmp.
Vincent
On 8 Aug 2011, at 08:13, vincent habchi wrote:
Some apps, including iTunes, using /Users/Shared/ for DRM. It may still be
world-writable in Lion [which I can't confirm as I haven't switched
yet...come on 10.7.2...].
I can confirm /Users/Shared is world writable on 10.7; besides, it has
On Aug 8, 2011, at 4:54 AM, Chris Ridd chrisr...@mac.com wrote:
Does OS X really support the sticky bit? Lion's sys/stat.h suggests no,
though this line could be read a couple of ways:
Yep, it's supported and used on directories. Don't think it's supported on
files, though.
--Kyle
On Mon, 8 Aug 2011 01:04:07 -0600, Eli Bach said:
It's a validation file containing registration details. My product is
an AudioUnit plugin so there's no App Store potential but I'd prefer to
keep things clean just in case.
I don't care where I write the file much (previously I wrote it to /
On 8 Aug 2011, at 10:36, Sean McBride wrote:
On Mon, 8 Aug 2011 01:04:07 -0600, Eli Bach said:
It's a validation file containing registration details. My product
is
an AudioUnit plugin so there's no App Store potential but I'd
prefer to
keep things clean just in case.
I don't care
On Mon, Aug 8, 2011 at 11:13 AM, Stephen Blinkhorn
step...@audiospillage.com wrote:
I'm afraid your fears have just been confirmed, until I find a better
solution at least. Maybe I can justify this as a kind of protest against
AudioUnits not being allowed in the App Store :-)
Well, writing to
But doesn't it seem entirely reasonable that apps signed by the same vendor
(for example) be able to share files? I mean in a safe location perhaps with a
limited quota of space?
Cookies and client side storage in HTML 5 allow this (not exactly the same but
still), but native apps have no
On Aug 8, 2011, at 11:39 , Stephen Blinkhorn wrote:
OK, well /Library/Application Support/CompanyName/ is out I believe as you're
not supposed to store user data in there.
IIRC, the data you're talking about is registration information, which is *not*
what (I think) is meant by user data. In
On Aug 8, 2011, at 11:39 AM, Stephen Blinkhorn wrote:
OK, well /Library/Application Support/CompanyName/ is out I believe as you're
not supposed to store user data in there. Which leaves the keychain as the
only option I can think of right now.
Keychains are per-user, apart from the system
On 8 Aug 2011, at 12:56, Quincey Morris wrote:
On Aug 8, 2011, at 11:39 , Stephen Blinkhorn wrote:
OK, well /Library/Application Support/CompanyName/ is out I believe
as you're not supposed to store user data in there.
IIRC, the data you're talking about is registration information,
On Mon, 8 Aug 2011 14:42:54 -0600, Stephen Blinkhorn said:
OK, well /Library/Application Support/CompanyName/ is out I believe
as you're not supposed to store user data in there.
IIRC, the data you're talking about is registration information,
which is *not* what (I think) is meant by user
On 8 Aug 2011, at 14:56, Sean McBride wrote:
On Mon, 8 Aug 2011 14:42:54 -0600, Stephen Blinkhorn said:
OK, well /Library/Application Support/CompanyName/ is out I believe
as you're not supposed to store user data in there.
IIRC, the data you're talking about is registration information,
On Mon, 8 Aug 2011 16:13:50 -0600, Stephen Blinkhorn said:
To be clear, you'd need to use ~/Library/App Support not the one in /
Library.
OK, no problem in Cocoa with the stringByExpandingTildeInPath: method
of NSString. More problematic for CFStringRef though. Is there an
acknowledged way of
On 8 Aug 2011, at 16:42, Sean McBride wrote:
On Mon, 8 Aug 2011 16:13:50 -0600, Stephen Blinkhorn said:
To be clear, you'd need to use ~/Library/App Support not the one
in /
Library.
OK, no problem in Cocoa with the stringByExpandingTildeInPath: method
of NSString. More problematic for
Hello,
Under Tiger, Leopard, and Snow Leopard I use
CFURLWriteDataAndPropertiesToResource to store some data into a file.
On Lion the default permissions appear to have been upgraded almost
everywhere and consequently the code below isn't succeeding. Is it
possible to run the below code
On Sun, Aug 7, 2011 at 8:48 PM, Stephen Blinkhorn
step...@audiospillage.com wrote:
Hello,
Under Tiger, Leopard, and Snow Leopard I use
CFURLWriteDataAndPropertiesToResource to store some data into a file. On
Lion the default permissions appear to have been upgraded almost everywhere
and
It's a validation file containing registration details. My product is
an AudioUnit plugin so there's no App Store potential but I'd prefer
to keep things clean just in case.
I don't care where I write the file much (previously I wrote it to /
Library/Preferences) but even the hard drive
19 matches
Mail list logo
