On Apr 4, 2016, at 17:41 , Gerriet M. Denkmann wrote:
>
> What are the alternatives?
What I had in mind is that you would construct a composite NSData object that
contained the results of compressing each file’s content as sub-components. By
compressing this yourself, you could (for example) c
> On 5 Apr 2016, at 08:30, Jens Alfke wrote:
>
>
>> On Apr 4, 2016, at 9:59 AM, Gerriet M. Denkmann wrote:
>>
>> Both the Simulator and the OS X App compress the same folder (which resides
>> on OS X).
>
> OK, but the raw data size is significantly different, so they must be zipping
> diff
> On 5 Apr 2016, at 11:30 AM, Gerriet M. Denkmann wrote:
>
>
>> On 5 Apr 2016, at 08:17, Graham Cox wrote:
>>
>>> On 5 Apr 2016, at 10:41 AM, Gerriet M. Denkmann
>>> wrote:
>>>
>>> What are the alternatives?
>>
>> file paths or NSURL?
>
> Not really. If I send file paths or NSURLs (point
> On Apr 4, 2016, at 9:59 AM, Gerriet M. Denkmann wrote:
>
> Both the Simulator and the OS X App compress the same folder (which resides
> on OS X).
OK, but the raw data size is significantly different, so they must be zipping
different data. I don’t know why that would be; maybe the file pat
> On 5 Apr 2016, at 08:17, Graham Cox wrote:
>
>> On 5 Apr 2016, at 10:41 AM, Gerriet M. Denkmann wrote:
>>
>> What are the alternatives?
>
> file paths or NSURL?
Not really. If I send file paths or NSURLs (pointing to files on OS X) to my
iOS Devices, these would not be very useful.
I real
> On 5 Apr 2016, at 10:41 AM, Gerriet M. Denkmann wrote:
>
> What are the alternatives?
file paths or NSURL?
—Graham
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Con
> On 5 Apr 2016, at 00:35, Quincey Morris
> wrote:
>
> On Apr 4, 2016, at 09:59 , Gerriet M. Denkmann wrote:
>>
>> Both the Simulator and the OS X App compress the same folder (which resides
>> on OS X).
> Incidentally, the OS X documentation for NSFileContentsPboardType,
> serializedRepre
On Apr 4, 2016, at 09:59 , Gerriet M. Denkmann wrote:
>
> Both the Simulator and the OS X App compress the same folder (which resides
> on OS X).
You can’t really use a convenience API such as ‘serializedRepresentation’ and
then complain it doesn’t optimize for your specific use case. Concise
> On 4 Apr 2016, at 23:49, Jens Alfke wrote:
>
>
>> On Apr 4, 2016, at 1:18 AM, Gerriet M. Denkmann wrote:
>>
>> When I do this in OS X 10.11.4 dataRaw = 30380898, dataCompressed = 5638680
>> ( 18.6 %)
>> But in the iOS Simulator 9.3.1: dataRaw = 28206422, dataCompressed = 4282602
>> ( 15.2
> On Apr 4, 2016, at 1:18 AM, Gerriet M. Denkmann wrote:
>
> When I do this in OS X 10.11.4 dataRaw = 30380898, dataCompressed = 5638680 (
> 18.6 %)
> But in the iOS Simulator 9.3.1: dataRaw = 28206422, dataCompressed = 4282602
> ( 15.2 %)
>
> That is OS X (10.11.4) makes an 8 % bigger FileWr
NSFileWrapper *fileWrapper = … some Folder …
NSData *dataRaw = fileWrapper.serializedRepresentation;
NSDate *dataCompressed = … COMPRESSION_LZFSE …
When I do this in OS X 10.11.4 dataRaw = 30380898, dataCompressed = 5638680 (
18.6 %)
But in the iOS Simulator 9.3.1: dataRaw = 28206422, dataCompre
Not sure its related, but I have noticed that using Finder nowadays to create
an alias of a plain folder results in a 1MB alias file. Seems its also stashing
away a copy of the plain folder icon. (Actually it is stashing two copies, one
in the resource fork for compatibility and one in the data
Problem ID: 8840391
_murat
On Jan 8, 2011, at 7:55 PM, Ken Ferry wrote:
> Hi,
>
> That's what I see too. From inspecting the serialized rep, it looks like
> it's icon data.
>
> Since at least in my test case the folders did not have custom icons, it
> seems like one could do better. Could
Hi,
That's what I see too. From inspecting the serialized rep, it looks like
it's icon data.
Since at least in my test case the folders did not have custom icons, it
seems like one could do better. Could you file a bug please?
-Ken
Cocoa Frameworks
On Sat, Jan 8, 2011 at 5:16 PM, mlist0...@gm
I create an NSFileWrapper for a directory hierarchy like this (all items are
directories, no files):
test-dir/
test-dir/inner-dir-a
test-dir/inner-dir-b
test-dir/inner-dir-c
The wrapper's serialized representation weighs in at around an astounding 1mB
(1,022,234 bytes)!
Seems that the overhead
15 matches
Mail list logo
