when writing a file using NSFileCoordinator i need to specify the correct NSFileCoordinatorWritingOptions. Although they are explained in detail, I am not sure when to use which one. The available options are:
NSFileCoordinatorWritingForDeleting
NSFileCoordinatorWritingForReplacing
NSFileCoordinatorWritingForMoving
NSFileCoordinatorWritingForMerging
For example, what option is the correct one if I want to create a file (a plist for example)?
Wich one when I modify a file?
Can someone explain the NSFileCoordinatorWritingOptions for a better understanding?
I agree, documentation is not complete on that front, and hard to understand. And no sample code is available even for basic operations like these.
I try to think of these options in the perspective of other apps that have that specific file open, that helps getting the whole picture.
Pass no option (0) to simply update the file and notify others of your changes.
Let's say you are deleting a file that TextEdit currently displays, by providing the NSFileCoordinatorWritingForDeleting option, you're telling TextEdit to close the file as it does not exist anymore (or it could propose to save it to another place if it's in memory). It acts because of deletion.
If you're overwriting a file (as opposed to updating a file), you want about that same behavior for other apps. That's NSFileCoordinatorWritingForReplacing.
NSFileCoordinatorWritingForMoving says other apps to track the file to it's new location, so that it can be later updated.
NSFileCoordinatorWritingForMerging asks other processes to first commit their changes so that you can then merge your own changes with those.
To answer your question, you should use NSFileCoordinatorWritingForReplacing when creating a new file (even when no file exists, as it was to appear in the mean time from another app, you'd be replacing it with your own, unrelated contents). And NSFileCoordinatorWritingForMerging should be used when updating an existing file with new data, as it allows integrating the latest changes to that file immediately (instead of doing later with conflict resolution).
Related
According to the documentation, the fourth parameter of FSEventStreamCreate (a function used to receive events about file changes) is "A CFArray of CFStringRefs, each specifying a path to a directory, ..." but I'm interested in changes to a specific file only. I know that I can pass the directory the file is in and then filter the events, which is what I've been doing up until now, but I have found out, that if I simply pass the file's entire path, it works perfectly fine (and allows me to simplify my code significantly).
So my question is, since I want to put this into production software, is this something I can rely on to work (e.g. in other versions of the OS), or is it a fluke? Is it documented somewhere to work this way? Does anyone else use it this way? My best guess is that the documentation is phrased like this because by default, only filesystem changes are reported, and the flag kFSEventStreamCreateFlagFileEvents has to be added to make it also report file content changes, but maybe I'm wrong.
The only thing Apple says about this is here
Request file-level notifications. Your stream will receive events about individual files in the hierarchy you're watching instead of only receiving directory level notifications.
Regarding other developers using this feature: yes, there are some.
You can probably leave a feedback on Apple, asking to improve the documentation, and maybe one day they will.
I'm using BartyCrouch to maintain an up-to-date localized project. My project is currently translated in 4 different languages, and I'm going to add some new languages. My issue is that my base Localizable.strings file has about 200-300 resources, even though there are probably less than 100 currently used in the project.
I'm looking for the best way to remove the un-referenced localized strings in the project, all while keeping the currently localized values.
Is there any native solution or do I have to use a third party? And if so, is there anything automatic?
Well, I definitely didn't look hard enough. I think it's worth posting an answer instead of deleting the question because I don't think the answer is on Stackoverflow yet.
https://github.com/ijoshsmith/abandoned-strings
This little gem will do exactly this. Easy to use. Simply download the zip file, use the Terminal to go into the "AbandonedStrings" folder containing a single "main.swift" file.
Then, on the terminal, enter: ./main.swift /the/path/to/your/project
This will display a list of all the unused ressources.
Then, if you also want the script to delete them, simply add "write" at the end of the command.
Watch out though: it will delete all the Storyboard localized ressources, so commit your project before and simply discard the changes.
For the last 2 days I've been trying to make my single-file document into a package, but I can't get it to work. In the documentation it states the preferred way is to use NSFileWrapper. I've tried it but it's just such a unintuitive way of handling files.
I guess to update a file I need to delete the file wrapper from it's directory, create a completely new one and add it again to the directory. I haven't found anything that explicitly states it, but I guess I should update the file only when fileWrapperOfType:error: is called.
As NSFileWrapper keeps everything (at least once loaded) in memory, this means that I'll have the old version and the new version at the same time until the user (or autosave) saves the file.
It seems like NSFileWrapper shouldn't be used for big files, but I think it's better if all the files that are needed by the document are inside the package(can be copied to another Mac/iPhone/iPad without errors) and I don't want to limit the user on how many/how big the files can be.
When using a manual URL-based saving mechanism, I end up getting corrupt packages, as the destination directory is always a temporary one, and I couldn't find any information on how to merge them. Every time I manually save the document without any changes, an error occurs, as I don't write anything to the temporary directory. But I don't see a reason in writing/linking everything to the temporary directory, only for it to be copied/'un'-linked back to its destination.
As I can't seem to find the right answer, what is the best-practice for saving and restoring big packages with many/big files in them?
I need to copy a folder from one location to another while providing my users with a progress bar.
The only appropiate API that I can find that isn't deprecated is copyfile(3). I've implemented this and the results are nearly perfect, however I've since discovered that neither the Finder comments nor the tags associated with original are copied over. Not only do I need them to be copied, but I'm worried about what other metadata isn't being copied that I'm not yet aware of.
Note that I am setting all the appropriate flags on copyfile to copy over the metadata.
How can I achieve my goal without resorting to awful techniques such as an Applescript bridge to read/write the comments using the Finder at the end of the copy?
UPDATE
After much research I have discovered that both the comment and the tags are copied over in the file's extended attributes. However, the comment refuses to display in the Finder.
I saw it mentioned that the comment is also stored in the .DS_Store. As a test I deleted the .DS_Store file and then relaunched the Finder so that it would be regenerated. The comment still doesn't appear.
What needs to be done for the Finder to recognise this metadata?
Note: this answer assumes you are correct about comments etc. not being copied, this has not been verified.
copyfile is available in source form from Apple. You might need to tweak it a bit though to actually compile it. Once you've done that you can modify to add the features you wish.
HTH
Our VB6 guy was part of the last RIF (Reduction in Force). The work he did has been split between me and another developer. We often are both are making changes to projects at the same time. This isn't a problem with CVS since we are working in different areas. However VB6 seems to modify the Reference section and change the paths each time either of us touches a project. Since we don't have the exact same path setup for out source trees we run into merge conflicts on the vbp file all the time.
Is there any way around this other than the obvious method of changing our setup so we have the same directory structures?
I would suggest two things:
Don't commit the .vbp unless you add a file to the project.
Mark the .vbp as read-only and check it in as such into your repo. When users check it out, it should still be read-only which will prevent changes to reference paths (and seemingly random reordering of the file) from being saved. When you have to make a change to the project--make the file read-write, save the change and then make it read-only again before committing.
Depending on your version control system, it is possible to automate this problem away. Both Subversion and Mercurial support hooks - scripts that are triggered by certain events, like check out, update, or commit. We wrote a fairly simple script that was triggered on commit: it looked to see if there was a .vbp in the commit package, and if there was, ran a "normalisation" routine that
put all the .cls/.bas/.frm files at the top of the .vbp, in alphabetic order
put the references section in alphabetic order
lower-cased the reference paths
The rest of the file is left alone, since it's only the first three sections that VB seems to delight in messing about.
Consequently, most of the time when you commit, and haven't made any substantive changes to the .vbp, the hook script restores your .vbp file to a canonical, ordered, state (like a revert), which has the effect of removing it from the commit since it's no longer changed.
In the event that you do add a new file or reference to your project, the consistent alphabetical sorting of the VBP lines means that merge conflicts are avoided since your VC merge algorithm can easily and correctly detect the changes.
We wrote our script in Javascript and execute it using Windows Script Host since, for Windows boxes at least, this removes the dependency on an interpreter like Perl/Python.
Hooking up this script to new VB projects is a 30 second job. The advantage over other manual approaches is that you don't have make any conscious effort to deal with the VBP file. Just commit it with everything else and the script takes care of the rest.