What is the equivalent of Window's C:\Users\userName\AppData\Roaming\appName?
I need a directory that won't cause permission problems to store the updateable part
of my application so I can automatically download and override my content.
Thank you.
/Users/USERNAME/Library/Application Support/
Edit:
This answer has drawn a lot of upvotes despite its minimalistic nature. Therefore, I want to point out the things mentioned in the comments here to make them more visible:
There are several other folders being used for application data / configuration, as mentioned in this answer.
If writing an application, don't hardcode that path. Instead, use macOS' API to retrieve it. This question has several answers for both ObjectiveC and Swift.
~/Library/Application Support/
in shift+command+G in finder
Related
I have create a new directory with
FileUtils.mkdir_p 'backupFiles' unless File.exists?('backupFiles')
how ever i like this folder to be hidden from CL and within the text editor visualisation of the rails project.
Any hints or advise how to do so?
and if the folder is hidden would it still be accessible by my program ? (e.g. with FileUtils.cp_r "./app", "backupFiles/")
This will be hard to answer correctly without any clarification on what you mean by "hidden" (I would have asked that in a comment, but reputation you know). I'll try anyway.
What I understand is that your application creates a directory in your app directory that you don't want to see.
If you don't want to see it in the Finder/Nautilus/Windows Explorer, then the easiest way should be to name the directory beginning with period. For your example that would translate to:
FileUtils.mkdir_p '.backupFiles' unless File.exists?('.backupFiles')
This wouldn't affect the accessibility of that folder via the commandline or your app in any way. (Accept that it's name starts with a period obviously)
Maybe that might be possible using SELinux Extended Security Attributes but it sounds pretty hard to implement.
Take a look at this:
https://superuser.com/questions/738392/completely-hide-files-on-linux
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
I'm a little confused with the sandbox. Is this possible?
Thanks!
Yes, but it requires a "temporary exception" entitlement. "Temporary" means that it may go away in some future version of the OS, but that's not much of a risk. The bigger problem is that word "exception": It means you will have to justify your use of the entitlement, or the App Store reviewers will probably reject you.
File a bug report explaining exactly what it is you think you ought to be able to do, but can't do today without access to ~/Library, and ideally also start a forum thread on the topic. They may suggest a workaround to use instead of accessing ~/Library (maybe even using private APIs), in which case, do what they say. Or they may say to use the temporary exception for now, in which case, do that. Or they may not respond, in which case you use the temporary exception and cross your fingers. In any case, make sure your App Store submission review notes have a link to the bug report and/or forum thread.
You will have to edit your project's entitlements plist manually to do this, but it's not very hard. Create a com.apple.security.temporary-exception.files.home-relative-path.read-only array, with one string, "/Library/". Like this:
<key>com.apple.security.temporary-exception.files.home-relative-path.read-only</key>
<array>
<string>/Library/</string>
</array>
The extra / at the end is how the sandbox knows you want to access a directory, rather than a file. If you leave it off, you will get access to all files in ~/Library, which is what you asked for, but not to files in (recursive) subdirectories of ~/Library, like, say, ~/Library/LaunchAgents/com.mycompany.myapp.myoldagent.12345678-ABCD-EF00-1234-567890ABCDEF.plist, which is what you probably want. See File Access Temporary Extensions in the Entitlement Key Reference documentation.
Also, notice that you already have access "for free" to certain things under ~/Library, either because they get copied into your container, or indirectly when you use the appropriate APIs instead of using paths. So, there may be a better way to accomplish what you're doing—e.g., to read files left by a previous non-sandboxed version of your app, you might be able to migrate them into the container and read them there.
One more thing: Just having access to ~/Library doesn't change what NSHomeDirectory(), URLsForDirectory:inDomains:, etc. will return--you'll still get ~/Containers/com.mycompany.myproduct/Data/Library instead. Apple's semi-official recommendation for dealing with this is to use BSD APIs to get the user's real home directory, and the simplest way is this:
const char *home = getpwuid(getuid())->pw_dir;
NSString *path = [[NSFileManager defaultManager]
stringWithFileSystemRepresentation:home
length:strlen(home)];
NSURL *url = [NSURL fileURLWithPath:path isDirectory:YES];
A few notes:
It's generally not a good idea to call getpwuid too frequently. The best solution is to call this code once early, and then cache the resulting NSURL.
This can obviously also be used to get other users' home (and therefore Library) directories, but the App Store almost certainly won't allow any software that actually tries that.
The fact that the library is at ~/Library is considered an "implementation detail" that could change one day, which is another reason (on top of the entitlement) that this has to be considered a temporary workaround until Apple provides a real solution to your higher-level problem, and it might be worth mentioning in your review notes.
I am looking for where I should save my app stuff, and after a quick search I found this:
Cocoa equivalent of .NET's Environment.SpecialFolder for saving preferences/settings?
and this:
https://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/FileSystemProgrammingGUide/AccessingFilesandDirectories/AccessingFilesandDirectories.html#//apple_ref/doc/uid/TP40010672-CH3-SW3
Then I look at my Application Support Folder and noticed that almost every app uses the AppName and not the BundleID as apple suggests in its documentation.
I want to make sure I choose the right one, because I heard that some apps got rejected for writing in a ~/Library/Application Support/ subdirectory with different name than the app's name.
IN SHORT:
Which naming convention you think I should use?
Does it matter when they are reviewing apps? Both are OK?
Thank you
Well, answering my own question, just to not leave as is...
I just called NSSearchPathForDirectoriesInDomains( NSApplicationSupportDirectory, NSUserDomainMask, YES ); to get the application support folder and appended the App name.
I hardly believe something like that will be a reason for a rejection, as NSApplicationSupportDirectory appears to return te correct folder even when the app is sandboxed.
I would like to generate some temporary files in the course of my application. Specifically, I'm using AVAudioRecorder to record a file that I, upon stopping the recording, would like to load and edit/process. My question is:
What is the appropriate standard place to create temporary files. Is there some generally accepted approach to this for Mac or for iPad programming in general? I don't want to simply create a directory and write files into it if there is a proper protocol to this.
The answer to this question is actually a lot more complicated then one might assume. One cannot necessarily just use NSTemporaryDirectory and be done. I cocoadev.com has some good pages on this topic and I would suggest that you study them yourself and determine what will work best for your circumstance.
http://www.cocoadev.com/index.pl?NSTemporaryDirectory
http://www.cocoadev.com/index.pl?GettingTemporaryFolderOnSpecificVolume
The usual place for applications to store temporary data is /var/tmp. You could also use /tmp but this directory is for system-generated temporary files and anything in /tmp is deleted when the machine reboots.
What I found was that according to the iOS Application Programming Guide, I am supposed to query for the appropriate temporary folder for my application via NSTemporaryDirectory(). I tried this and it returned a folder within the /var directory, in my case '/var/folders/pQ/pQ+ZqZCSHWSIHftcbIo57U+++TI/-Tmp-/'.
/tmp or /usr/tmp are the usual places to store temporary files in Unix (which Mac OS X and iOS are).