On 8 Aug 2011, at 16:02, Kyle Sluder wrote:
> On Aug 8, 2011, at 4:54 AM, Chris Ridd wrote:
>
>>
>> Does OS X really support the sticky bit? Lion's 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 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 CFS
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
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,
wh
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 mean
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,
whic
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 syst
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".
On 8 Aug 2011, at 12:21, Kyle Sluder wrote:
On Mon, Aug 8, 2011 at 11:13 AM, Stephen Blinkhorn
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
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 optio
On Mon, Aug 8, 2011 at 11:13 AM, Stephen Blinkhorn
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 /Users/Shared isn't goi
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 where
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
On Aug 8, 2011, at 4:54 AM, Chris Ridd wrote:
>
> Does OS X really support the sticky bit? Lion's 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 Sluder
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,
> 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 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 w
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 ro
On Sun, Aug 7, 2011 at 8:48 PM, Stephen Blinkhorn
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 consequently the code be
19 matches
Mail list logo
