Re: NSFileWrapper

ur of a package. Do you happen to know > >> how I can achieve it? I had presumed it might be some mix of flag > >> setting at system level. If for example i set the extension on an > >> NSFileWrapper to .bundle i get some of what I need - but I cant find out > &

Re: NSFileWrapper

> On 6 Jun 2016, at 4:31 AM, Jens Alfke wrote: > > So I guess NSFileWrapper’s not popular on the AppKit team either :) Seems a pity, as in some cases it’s handy to pass around something that mirrors the structure of a chunk of disk storage. If it loaded its content lazily it wouldn’t have thi

Re: NSFileWrapper

> On Jun 4, 2016, at 11:52 PM, Charles Srstka wrote: > > Every time I’ve ever tried to use NSFileWrapper, I’ve always ended up having > to switch to something else because of the memory issue that Jens mentions. > Never really understood the point of that class. I was go

Re: NSFileWrapper

-pkg” for your >> package format. > > > You can use the same extension and leave it to your app to figure out which > it’s actually dealing with - the extension is only used to map the file to an > app that can open it - after that the file will be passed to NSDocument as a > NS

Re: NSFileWrapper

Hi All Many thanks to everyone who has contributed to this thread on NSFileWrapper. I have enough insight now to do some work to see what works. Again, thanks to everybody ! Peter ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do

Re: NSFileWrapper

r app to figure out which it’s actually dealing with - the extension is only used to map the file to an app that can open it - after that the file will be passed to NSDocument as a NSFileWrapper whatever its contents - packagae or flat file. Your app can then determine which it is based on some pr

Re: NSFileWrapper

might be some mix of flag setting at >> system level. If for example i set the extension on an NSFileWrapper to >> .bundle i get some of what I need - but I cant find out how to ‎get an icon >> of my choosing associated with it. > > You’ll have to work at it; it won’t be c

Re: NSFileWrapper

> On Jun 4, 2016, at 12:18 PM, Peter Hudson wrote: > > Hi Mike > > You're right - I want the behaviour of a package. Do you happen to know how I > can achieve it? I had presumed it might be some mix of flag setting at > system level. If for example i set the extens

Re: NSFileWrapper

large amounts of data. The problem is that NSFileWrapper doesn’t AFAIK have any API to get already-read files out of memory. In terms of eventual memory usage, it’s the same whether you read 1 large file or 100 small ones. Compounding this problem is that it’s typical for the file data to be an a

Re: NSFileWrapper

On 04/06/16 18:42, Jens Alfke wrote: I wouldn’t recommend NSFileWrapper for large files, because it reads all of a file into memory. I find this comment to be very misleading. Part of the reason why packages are so great (apart from being supported by NSDocument/AppKit as a method to store

Re: NSFileWrapper

Jens Thanks for these notes - extremely helpful. I think I will kick off with Realm and see where I get too. Peter > On 4 Jun 2016, at 20:36, Jens Alfke wrote: > > >> On Jun 4, 2016, at 9:51 AM, Peter Hudson > > wrote: >> >> “If your app’s performance is sufferi

Re: NSFileWrapper

> On Jun 4, 2016, at 9:51 AM, Peter Hudson wrote: > > “If your app’s performance is suffering because of large files, then use > streams instead, and try to only read the part of the file that’s necessary.” > Could you point me at some material about this technique ? It sounds very > interest

Re: NSFileWrapper

Hi Jens “If your app’s performance is suffering because of large files, then use streams instead, and try to only read the part of the file that’s necessary.” Could you point me at some material about this technique ? It sounds very interesting. I will check out the database approach as well.

Re: NSFileWrapper

> On Jun 4, 2016, at 9:18 AM, Peter Hudson wrote: > > You're right - I want the behaviour of a package. Do you happen to know how I > can achieve it? I had presumed it might be some mix of flag setting at > system level. If for example i set the extension on an NSFileWra

Re: NSFileWrapper

Hi Mike You're right - I want the behaviour of a package. Do you happen to know how I can achieve it?   I had presumed it might be some mix of flag setting at system level. If for example i set the extension on an NSFileWrapper to   .bundle i get some of what I need - but I cant find ou

Re: NSFileWrapper

It sounds like you want your file format to be what is known as a “package”. It’s a directory, but is (mostly) presented as a single file. NSFileWrapper is an API for working with files, it does not directly control whether something is a package or not. It just happens to be the most

NSFileWrapper

half the data rarely changes. It would however be neccessary for the two files to be handled transparently, by the user, as one unit. I have been looking over the docs for NSFileWrapper. I can’t see if it is possible to construct a file wrapper that presents itself to the user as ‘one file

Re: NSFileWrapper serializedRepresentation

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

Re: NSFileWrapper serializedRepresentation

atever reason. > >> What I need is just: >> Folder → Data and >> Data → Folder > > NSFileWrapper is reasonable, I guess. Just don’t obsess over the details of > the data size. Why does it matter, anyway? Sending an additional 1.5 MB over (WiFi, Bluetooth - whatever

Re: NSFileWrapper serializedRepresentation

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 really need to send the data. Fair enough, I had only skimmed the earlier posts, I hadn’t really grokked what you’re trying to do.

Re: NSFileWrapper serializedRepresentation

ybe the file paths are different from the simulated app’s POV? But I don’t think the algorithm being used is any different across platforms. It’s just that the input data is different, for whatever reason. > What I need is just: > Folder → Data and > Data → Folder NSFileWrapper is reas

Re: NSFileWrapper serializedRepresentation

> 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

Re: NSFileWrapper serializedRepresentation

> 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

Re: NSFileWrapper serializedRepresentation

> 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

Re: NSFileWrapper serializedRepresentation

. Concise compression may not be the API’s highest priority. A serialized NSFileWrapper for a package must contain a representation of the file system hierarchy, and it’s not unreasonable that this may be very different on the two platforms. Since this particular serialization is supposed to

Re: NSFileWrapper serializedRepresentation

> 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

Re: NSFileWrapper serializedRepresentation

> 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 serializedRepresentation

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

Re: UIDocument with NSFileWrapper

I don't claim this is the one right way, but I think it makes sense based on the little bit of documentation there is for NSFIleWrapper and it seems to work. My situation is complicated because my document consists of multiple files. UIDocument is pretty simple if you only need a single

Re: UIDocument with NSFileWrapper

, Quincey Morris < > quinceymor...@rivergatesoftware.com> wrote: > > > > On Mar 19, 2016, at 18:54 , davel...@mac.com wrote: > >> > >> What I’m having trouble understanding is how I store the images (whose > filenames will vary from document to document) with N

Re: UIDocument with NSFileWrapper

> On Mar 21, 2016, at 2:08 AM, Quincey Morris > wrote: > > On Mar 19, 2016, at 18:54 , davel...@mac.com wrote: >> >> What I’m having trouble understanding is how I store the images (whose >> filenames will vary from document to document) with NSFileWrapper. In m

Re: UIDocument with NSFileWrapper

On Mar 19, 2016, at 18:54 , davel...@mac.com wrote: > > What I’m having trouble understanding is how I store the images (whose > filenames will vary from document to document) with NSFileWrapper. In my top > level directory do I have my main model file as a JSON file along with a f

Re: UIDocument with NSFileWrapper

> On Mar 19, 2016, at 8:01 PM, Quincey Morris > wrote: > > On Mar 19, 2016, at 14:23 , davel...@mac.com wrote: >> >> My thought is to have a dictionary mapping each image filename to a >> NSFileWrapper > > You already have one, basically. The

Re: UIDocument with NSFileWrapper

On Mar 19, 2016, at 14:23 , davel...@mac.com wrote: > > My thought is to have a dictionary mapping each image filename to a > NSFileWrapper You already have one, basically. The top level wrapper for a package is a directory wrapper, which lists the wrappers of contained files, indexe

Re: UIDocument with NSFileWrapper

iles before worrying any more about it. I just wondered if there was a "better way" to do it so I figured I'd ask before I delved to far into it. I'm not certain I fully understand what to do with NSFileWrapper in this case but I'll give it a try. My thought is to have a di

Re: UIDocument with NSFileWrapper

On Mar 19, 2016, at 10:18 , davel...@mac.com wrote: > > The downside I see for my app is that UIDocument writes out the data to a > temporary location and then moves it to the new location so I think my app > will constantly be writing out these image/PDF files that never change. Is > there a b

UIDocument with NSFileWrapper

NSFileWrapper works and how to use the - (id)contentsForType:(NSString *)typeName error:(NSError **)outError method. The downside I see for my app is that UIDocument writes out the data to a temporary location and then moves it to the new location so I think my app will constantly be writing out these

Re: NSFileWrapper - is this really so bad?

Perhaps just a little too OCD; however, if one is sending a message like count to a large number of containers using nil (Null) can be considerably more efficient then passing an empty shared instance. The Objective-C pattern when sending a message to a nil object pointer avoids the overhead of

Re: NSFileWrapper - is this really so bad?

> On Oct 27, 2015, at 7:08 PM, Graham Cox wrote: > >> On 28 Oct 2015, at 10:53 AM, Alex Kac > > wrote: >> >> Have you tried simply passing in a blank dictionary? Is that OK? > > > Yes, that works OK. It’s at least a simple way to shut the warning up, though >

Re: NSFileWrapper - is this really so bad?

> On 28 Oct 2015, at 10:53 AM, Alex Kac wrote: > > Have you tried simply passing in a blank dictionary? Is that OK? Yes, that works OK. It’s at least a simple way to shut the warning up, though strikes me as unnecessary and inefficient, FWIW. —G. __

Re: NSFileWrapper - is this really so bad?

On Oct 27, 2015, at 16:24 , Graham Cox wrote: > > NSFileWrapper* fw = [[NSFileWrapper alloc] > initDirectoryWithFileWrappers:nil]; //<— Null passed to a callee > that requires a non-null argument It’s not necessarily so much about null vs non-null. A side ef

Re: NSFileWrapper - is this really so bad?

> On 28 Oct 2015, at 10:24 AM, Graham Cox wrote: > > due to the addition of the NON_NULL qualifier Actually, I should amend that: it doesn’t have ANY qualifier, so that appears by default to mean that it’s NOT nullable. I’m still getting used to this additional syntax. —G. __

Re: NSFileWrapper - is this really so bad?

> On Oct 27, 2015, at 4:24 PM, Graham Cox wrote: > > In XCode 7, I’m getting a new warning when compiling some code that uses > NSFileWrapper, due to the addition of the NON_NULL qualifier: > > Null passed to a callee that requires a non-null argumen

Re: NSFileWrapper - is this really so bad?

> On Oct 27, 2015, at 16:24 , Graham Cox wrote: > > In XCode 7, I’m getting a new warning when compiling some code that uses > NSFileWrapper, due to the addition of the NON_NULL qualifier: > > Null passed to a callee that requires a non-null argument > > The code is:

NSFileWrapper - is this really so bad?

In XCode 7, I’m getting a new warning when compiling some code that uses NSFileWrapper, due to the addition of the NON_NULL qualifier: Null passed to a callee that requires a non-null argument The code is: NSFileWrapper* fw = [[NSFileWrapper alloc] initDirectoryWithFileWrappers:nil

Re: Updating Content of NSFileWrapper

On Sep 15, 2014, at 19:12 , Charles Jenkins wrote: >// What the heck do I do here? How to I update fw's contents? You do the “obvious” thing — remove the existing file wrapper and create a new one. The clearest logic for this would be: If this file’s content is modified, remov

Updating Content of NSFileWrapper

My app’s document consists of a tree of individual word processing files to be saved as separate files within an NSFileWrapper. Apple’s documentation suggests you can make the process of saving to a file wrapper more efficient if you only write out new or changed files. I’d like to do that and

Re: Write with NSFileWrapper vs. copy with NSFileManager

right now). > Le 26 mars 2014 à 04:27, Graham Cox a écrit : > > How about when a document is a file package on disk and contains a variety of > resources? I've found NSFileWrapper to be a fairly natural fit for that sort > of situation. If not, what else would you use? >

Re : Re: Removing a file via NSFileWrapper

Thanks for your help.I guess encountering such situations is part of the job... And I'm still learning it ;-)Colashttps://overview.mail.yahoo.com?.src=iOS";>Envoyé depuis Yahoo Mail pour iPad ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Plea

Re: Removing a file via NSFileWrapper

exists"}". I don’t know the answer. It’s not clear from the documentation whether the ‘writeToURL:’ method is supposed re-write an existing folder in place, or whether it’s correct to give the above error. (NSFileWrapper documentation is really lousy.) It’s possib

Re: Removing a file via NSFileWrapper

With the  ‘NSFileWrapperWritingAtomic’ option, the "re-writing" goes well (error = nil). With other options, the "re-writing" does not go well and there is an error ("Error Domain=NSCocoaErrorDomain Code=516 "The file “folderName” couldn’t be saved in the folder “Desktop” because a file with the

Re: Removing a file via NSFileWrapper

On Mar 30, 2014, at 14:38 , Colas B wrote: > So do you agree that it is strange that I can "re-write" a folder with > ‘NSFileWrapperWritingAtomic’ but not without? According to your earlier description, you seem to have been able to change a folder’s contents either way, but you couldn’t see

Re: Removing a file via NSFileWrapper

       d) this time, if I check again the content of myFolder.myApp, I don't see "file2" (but "file1" is still there) > > >What does “check again” mean? Did you close the window showing the contents of >myFolder.myApp, then open another one? Yes, it is what I mean. I don’t understand this. ‘NS

Re: Removing a file via NSFileWrapper

On Mar 30, 2014, at 07:26 , Colas B wrote: > 2) the problem occurs also when "creating" a file via the "write" method of > NSFileWrapper if I do the following >a) in my "packaged file" myFolder.myApp, I create a file "file1" >

Re: Removing a file via NSFileWrapper

Thanks Mike for your answer. I did more tests. 1) the wrappers are not nil 2) the problem occurs also when "creating" a file via the "write" method of NSFileWrapper if I do the following        a) in my "packaged file" myFolder.myApp, I create a file "file1&q

Re: Removing a file via NSFileWrapper

On 29 Mar 2014, at 16:43, Colas B wrote: > Dear cocoa-dev, > > There is a problem when I try to remove a file from a folder via > NSFileWrapper. I don't know if this is an important info, but the folder is > inside a "package" (a folder with an ex

Removing a file via NSFileWrapper

Dear cocoa-dev, There is a problem when I try to remove a file from a folder via NSFileWrapper. I don't know if this is an important info, but the folder is inside a "package" (a folder with an extension). I have a folder "(...)/attached_files" on my disk. I cr

Re: Write with NSFileWrapper vs. copy with NSFileManager

On 26 Mar 2014, at 10:19, Colas B wrote: > > What is the difference between writing a hard link and just ignore this > particular file that has not changed ? If the file is already there, where > the hard link will be created? > > Envoyé depuis Yahoo Mail pour iPad NSF

Re : Re: Write with NSFileWrapper vs. copy with NSFileManager

What is the difference between writing a hard link and just ignore this particular file that has not changed ? If the file is already there, where the hard link will be created?https://overview.mail.yahoo.com?.src=iOS";>Envoyé depuis Yahoo Mail pour iPad _

Re: Write with NSFileWrapper vs. copy with NSFileManager

age), and pass in a suitable original URL, NSFileWrapper will do its best to write hard links for any files it detects haven’t changed. I should probably point out that NSFileWrapper can be configured to use memory mapping, which may lower the memory requirements for your app. _

Re : Re: Write with NSFileWrapper vs. copy with NSFileManager

Yes indeed, I'm using this method to manage additional data in a document.Want you say Mike frightens me a little bit, I would not want all my memory used my extra files when I save the document.Which options should I use if I want the file wrapper to read/write as less as possible when I updat

Re: Write with NSFileWrapper vs. copy with NSFileManager

How about when a document is a file package on disk and contains a variety of resources? I've found NSFileWrapper to be a fairly natural fit for that sort of situation. If not, what else would you use? --Graham On 26 Mar 2014, at 2:11 pm, Jens Alfke wrote: > For what it’s worth, I

Re: Write with NSFileWrapper vs. copy with NSFileManager

For what it’s worth, I’ve been coding with Cocoa for 13 years and have almost never found a reason to use NSFileWrapper. I think the only times are when I’ve needed to add image or file attachments to an NSTextView (because the API basically requires it.) —Jens

Re: Write with NSFileWrapper vs. copy with NSFileManager

On 25 Mar 2014, at 12:52, Colas B wrote: > Hi, I am having troubles using NSFileWrapper. In order to have a better > understanding of it, I would like to ask you the following question. > > Is there a difference between > > NSURL *referenceUR

Write with NSFileWrapper vs. copy with NSFileManager

Hi, I am having troubles using NSFileWrapper. In order to have a better understanding of it, I would like to ask you the following question. Is there a difference between     NSURL *referenceURL, *destinationURL ;          [[[NSFileManager alloc] init] copyItemAtURL:referenceURL

Re: NSFileWrapper and plist

On Sep 13, 2013, at 6:46 PM, Trygve Inda wrote: > I have an NSDictionary that contains objects that support NSCopying. I can > use writeToFile:atomically: and it saves a nice plist file that I can read > cleanly. > > If I use NSFileWrapper however (for my document-based app),

NSFileWrapper and plist

I have an NSDictionary that contains objects that support NSCopying. I can use writeToFile:atomically: and it saves a nice plist file that I can read cleanly. If I use NSFileWrapper however (for my document-based app), I need to use a keyed archiver to conver the NSDictionary to NSData. After

Re: UIDocument + NSFileWrapper, how to get incremental saving to work?

On Aug 25, 2013, at 2:25 PM, Markus Spoettl wrote: > On 8/25/13 11:09 PM, Kyle Sluder wrote: > > > The behavior of this method may be affected by external variables. > > In which case those would have been documented. Even if Apple's documentation were far superior to its current mediocre sta

Re: UIDocument + NSFileWrapper, how to get incremental saving to work?

On 8/24/13 11:38 PM, Kyle Sluder wrote: On Sat, Aug 24, 2013, at 02:31 PM, Markus Spoettl wrote: That's exactly what I'm doing. My save times are so bad, the only explanation that I can come up with is that UIDocument/NSFileWrapper isn't really hard-linking unchanged wrappers.

Re: UIDocument + NSFileWrapper, how to get incremental saving to work?

On Sat, Aug 24, 2013, at 02:31 PM, Markus Spoettl wrote: > That's exactly what I'm doing. My save times are so bad, the only > explanation > that I can come up with is that UIDocument/NSFileWrapper isn't really > hard-linking unchanged wrappers. Or it does and al

Re: UIDocument + NSFileWrapper, how to get incremental saving to work?

les. That's exactly what I'm doing. My save times are so bad, the only explanation that I can come up with is that UIDocument/NSFileWrapper isn't really hard-linking unchanged wrappers. Or it does and also does something else to counter the gain. Regards Markus

Re: UIDocument + NSFileWrapper, how to get incremental saving to work?

t; took that to mean that UIDocument's use of NSFileWrapper doesn't support > incremental saving for some reason. The file wrapper optimization is not, AFAIK, regarded as incremental saving, though the intended effect is of course somewhat similar. > So I went and implemented my

UIDocument + NSFileWrapper, how to get incremental saving to work?

Hi, I have an iOS app that uses UIDocument in conjunction with a document package that is implemented through NSFileWrapper. It seems no matter what I do, I can't get incremental saving to work. The more sub-wrappers my package wrapper contains, the longer it takes for the document t

Re: NSFileWrapper NSKeyedArchiver and Mutability

mmutable object. Archiving doesn't change the mutability of container objects. Perhaps you were thinking of serializations, which *do* return immutable versions of mutable containers? > However, if I do: > > NSFileWrapper* myWrapper = [[[NSFileWrapper alloc] > initRegularFileWith

NSFileWrapper NSKeyedArchiver and Mutability

NSMutableDictionary* myMutDict = [[NSMutableDictionary alloc] init]; NSData* myMutData = [NSKeyedArchiver archivedDataWithRootObject:myMutDict]; If I unarchive this, I was under the impression that it would return an immutable object. However, if I do: NSFileWrapper* myWrapper

Re: UIDocument + NSFileWrapper crashes on opening

On Jun 21, 2013, at 03:40 , Markus Spoettl wrote: > can it be that a wrapper which I hold on to from the time I first created it > switches it's backing from in-memory to memory mapped disk once it has been > saved? There are actually three possible states for a regular file wrapper: 1. 'regu

Re: UIDocument + NSFileWrapper crashes on opening

apper UIDocument/the framework hasn't had a chance to memory map it because I didn't hand over the root file wrapper yet. That inspired the thought that saving - even incrementally - will use all memory necessary to load the whole thing. I clearly don't know enough about the inner worki

Re: UIDocument + NSFileWrapper crashes on opening

On Jun 20, 2013, at 22:05 , Markus Spoettl wrote: > It seems that the default implementation of UIDocument uses an NSFileWrapper > initialized with the NSFileWrapperReadingImmediate reading option. > > When I create a NSFileWrapper not using that option it works, meaning it now

Re: UIDocument + NSFileWrapper crashes on opening

On 6/20/13 11:52 PM, Quincey Morris wrote: OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing sub-wrappers instead of actual data of contained files/folders, which can be read on demand when needed? No, NSFileWrapper provides *lazy* loading, in the sense tha

Re: UIDocument + NSFileWrapper crashes on opening

the Hiesterman wrote: Probably exactly as you said. Try overriding -readFromURL:error: to implement incremental reading. OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing sub-wrappers instead of actual data of contained files/folders, which can be read on demand

Re: UIDocument + NSFileWrapper crashes on opening

ent incremental reading. > > OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing > sub-wrappers instead of actual data of contained files/folders, which can be > read on demand when needed? > > Is NSFileWrapper on iOS doing things differently than

Re: UIDocument + NSFileWrapper crashes on opening

On Jun 20, 2013, at 14:37 , Markus Spoettl wrote: > OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing > sub-wrappers instead of actual data of contained files/folders, which can be > read on demand when needed? No, NSFileWrapper provides *lazy* loading

Re: UIDocument + NSFileWrapper crashes on opening

On 6/20/13 11:16 PM, Luke the Hiesterman wrote: Probably exactly as you said. Try overriding -readFromURL:error: to implement incremental reading. OK, but isn't NSFileWrapper supposed to facilitate exactly that by providing sub-wrappers instead of actual data of contained files/fo

Re: UIDocument + NSFileWrapper crashes on opening

The document data is loaded from and saved to a NSFileWrapper > (representing a file package containing many files and folders), handed from > and to the document in -loadFromContents::: and -contentsForType::. > > This all works well for small documents but I now have a case where a

Re: UIDocument + NSFileWrapper crashes on opening

Seems the log didn't make it in the initial post, not sure why. On 6/20/13 11:01 PM, Markus Spoettl wrote: I'm pasting the console output of a typical session from the time the app is started via Springboard until it crashes/vanishes. Maybe it contains a clue I don't see. Jun 20 20:52:08 Flatf

UIDocument + NSFileWrapper crashes on opening

Hello everyone, I have an iOS 6 app that uses UIDocument to implement loading and saving of my app's data. The document data is loaded from and saved to a NSFileWrapper (representing a file package containing many files and folders), handed from and to the document in -loadFromCon

Re: NSDocument packages and incremental writing using NSFileWrapper

way to speed this up. After thinking about it, I also suspect Versions to be the culprit. I will ask DTS about that issue. Thanks, Thomas > > On 5 Feb 2013, at 10:38, Thomas Zoechling wrote: > >> >> Thanks for your response, >>> Given the right conditions, NSF

Re: NSDocument packages and incremental writing using NSFileWrapper

On 5 Feb 2013, at 10:38, Thomas Zoechling wrote: > > Thanks for your response, >> Given the right conditions, NSFileWrapper can make writing vastly more >> efficient by writing hard links for unchanged files, rather than recreating >> them afresh. Have you de

Re: NSDocument packages and incremental writing using NSFileWrapper

Thanks for your response, > Given the right conditions, NSFileWrapper can make writing vastly more > efficient by writing hard links for unchanged files, rather than recreating > them afresh. Have you determined whether this is happening at all? Currently I am trying to figure out w

Re: NSDocument packages and incremental writing using NSFileWrapper

> +- large2.file (large, immutable) > > While the metadata.plist file can change any time, all large files are > created once and then stay as they are. > As my "large0-2" files can be several gigabytes, I try to carefully avoid > unnecessary IO by using document packa

NSDocument packages and incremental writing using NSFileWrapper

files are created once and then stay as they are. As my "large0-2" files can be several gigabytes, I try to carefully avoid unnecessary IO by using document packages with NSFileWrapper. My package reading/writing methods resemble the ones in the "Document Package with iCloud" sam

Re: Maximum size for NSFileWrapper serialization?

On Fri, 18 Jan 2013 13:18:52 -0800, Sebastien Boisvert said: >I'm trying to initialize a NSFileWrapper with an existing file which is >about 3.65GB (gigs), then get the NSData by serializing it, but get the >following exception: > >MyApp[81289:303] can't write int larger

Maximum size for NSFileWrapper serialization?

I'm trying to initialize a NSFileWrapper with an existing file which is about 3.65GB (gigs), then get the NSData by serializing it, but get the following exception: MyApp[81289:303] can't write int larger than INT_MAX MyApp[81289:303] ( 0   CoreFoundation    0x7f

NSFileWrapper/NSDocument package saving performance trouble

Hello, I have an NSDocument based app that uses the NSFileWrapper based reading and writing methods to save a package document file. Works fine in theory and with small documents but when I put a lot of files in my package, saving is seriously slow. My understanding is that if one changes

Re: NSFileWrapper Role

2012, at 12:27 PM, Graham Cox wrote: > > On 25/02/2012, at 2:47 PM, -Sergei G- wrote: > >> I don't quite get the role of NSFileWrapper. It appears to provide a subset >> of NSFileManager functionality. Some of the Apple samples use NSFileWrapper >> to impleme

Re: NSFileWrapper Role

On 25/02/2012, at 2:47 PM, -Sergei G- wrote: > I don't quite get the role of NSFileWrapper. It appears to provide a subset > of NSFileManager functionality. Some of the Apple samples use NSFileWrapper > to implement bundle support, but it is not clear if that's a requi

NSFileWrapper Role

I don't quite get the role of NSFileWrapper. It appears to provide a subset of NSFileManager functionality. Some of the Apple samples use NSFileWrapper to implement bundle support, but it is not clear if that's a requirement or just a choice of the developer. Can someone elaborate

Re: NSFileWrapper serializedRepresentation bloat?

m 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 >> &g

Re: NSFileWrapper serializedRepresentation bloat?

ike one could do better. Could you file a bug please? > > -Ken > Cocoa Frameworks > > On Sat, Jan 8, 2011 at 5:16 PM, mlist0...@gmail.com > wrote: > I create an NSFileWrapper for a directory hierarchy like this (all items are > directories, no files): > > test-

Re: NSFileWrapper serializedRepresentation bloat?

PM, mlist0...@gmail.com wrote: > 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 i

  1   2   >