I'm trying to save a CFPropertyList to a location in the user's home folder. Using the code below I'm getting errorCode = -10 (unknown error).
CFURLRef fileURL = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, CFSTR("~/testfile.txt"), kCFURLPOSIXPathStyle, false );
SInt32 errorCode;
Boolean status = CFURLWriteDataAndPropertiesToResource(fileURL, xmlData, NULL, &errorCode);
If I change the path to something like "/testfile.txt" without the '~' then everything works. How can one save a property list to the current user's home folder? Must one obtain the user's name first and include it in the path such as /users/toffler/testfile.txt?
With Foundation, you can call the NSHomeDirectory function to get the absolute path to the user's home directory. You can then use the path-manipulation methods of NSString or of NSURL, or the equivalent function for CFURL, to tack a sub-path onto that.
However, please don't put files into the top level of my Home folder unless I, as the user, tell you to.
If you want to save a file at the user's request, run a save panel, and then save it where the user told you to.
If you want to save a preferences file, you probably should be using NSUserDefaults or CFPreferences, instead of handling plists yourself.
If you have some other reason to save a user-specific file, it should generally go into either the chewable items folder, the Caches folder, or the Preferences folder. The two functions that I linked to are the easiest ways to access those two of those three folders; the harder way, and the only one that works on all three, is the FSFindFolder function. Unlike most of the Folder Manager, FSFindFolder is not deprecated and is available in 64-bit.
Updates from the year 2012
Nowadays, you should use URLs, not paths. NSFileManager has a method for getting a URL to a desired directory.
Stapling paths (or file URLs) together does not work in a sandboxed application, because you don't have authorization to access the path you just made up. You need to get the path (or URL) from a system API, whether it's NSFileManager, NSSavePanel, or something else.
For saving and restoring file references, use NSURL's security-scoped bookmarks feature.
NSUserDefaults and CFPreferences work as expected in a sandbox.
The Folder Manager is now fully deprecated as of 10.8.
Polluting the user's Home folder is still bad manners.
Automatic ~ expansion is a feature of the shell.
If you are using Cocoa/Foundation, you can use the NSString methods
- (NSString *)stringByAbbreviatingWithTildeInPath;
- (NSString *)stringByExpandingTildeInPath;
otherwise, you'll have to write some code yourself to do this. Getting the user's login name and constructing the path /Users/login-name/ is not the correct way to do this. (While most users will have their home directory here, some will not.)
Related
I am trying to make a windows application. In this application, some files get modified as a user add or delete an entry. I saved these files on the application folder itself.
But After making binary file I installed it, As I try to add a entry it get crashed.
So, I figured out the issue. The windows doesn't allow to modified files inside C:\Program Files.
So, I installed it in other drive and it works. It solved my issue temporarily but I want to know how other application works in windows.
Where do those applications save their data?
I am not talking about some data which get saved in "Documents" but something which is essential need to modified every time user makes change like theme, formates.
No user access is allowed to the "program folder", and that's for good: it is a system folder, and it should only be accessed for system related operations (like installing or uninstalling a program).
There are many places where "program data" can be stored depending on the situation, and QStandardPaths provides access to their paths, according to the category location. What you might be interested in are:
ConfigLocation: Returns a directory location where user-specific configuration files should be written. This may be either a generic value or application-specific, and the returned path is never empty.
AppDataLocation: Returns a directory location where persistent application data can be stored. This is an application-specific directory.
AppLocalDataLocation: As the previous one, but Windows specific.
AppConfigLocation: Returns a directory location where user-specific configuration files should be written. This is an application-specific directory, and the returned path is never empty.
Those paths (along with the others listed in the documentation) can be accessed using the following static methods:
standardLocations(locationType): returns a list of paths for the requested location type, in order of priority (the first is usually the preferred one);
writableLocation(locationType): returns the preferred path for which write access is allowed (usually the first of the standardLocations());
If you need to store the user configuration, you can use QStandardPaths.writableLocation(AppConfigLocation), while if you have some user-specific internal data that is used by the application (email database, document templates, etc) QStandardPaths.writableLocation(AppLocalDataLocation) should be a good choice.
In both cases, those paths may not exist, so you need to ensure that and eventually create them, possibly by using QDir(path):
dataPath = QtCore.QStandardPaths.writableLocation(AppLocalDataLocation)
dataPathDir = QtCore.QDir(dataPath)
if not dataPathDir.exists():
# create the directory (including parent directories if they don't exist);
# that the argument of mkpath is relative to the QDir's object path, so
# using '.' means that it will create the actual dataPath
dataPathDir.mkpath('.')
Note that for all of the above (especially the last 3) it's required that you correctly set both the organizationName and the applicationName.
I have a sandboxed Cocoa app that allows the user to open and manipulate directories.
I'd like to disallow deleting special system folders such as the user's Documents and Desktop folders.
How can I tell if a file URL points to a special, protected system folder as defined in FileManager.SearchPathDirectory?
I use NSOpenPanel to open a folder. For the desktop folder, I get:
/Users/bob/Desktop
Now, FileManager has the handy method url(for:in:appropriateFor:create:) for locating special directories. For example:
FileManager.default.url(for: .desktopDirectory,
in : .userDomainMask, appropriateFor: nil, create: false)
returns:
/Users/bob/Library/Containers/com.mycompany.app/Data/Desktop
... which is expected, as this is a sandboxed app. But the problem now is that comparing these two urls fails, although semantically, they represent the same folder. How can I tell that they indeed point to the same folder?
The difference between the sandbox URL to a user-relative special folder and the non-sandbox one is always Library/Containers/<bundle id>/Data.
For your purposes both the sandbox and non-sandbox paths should presumably both be protected from deletion, indeed anything in ~/Library/Containers maybe should be protected.
So if FileManager.default.url returns a URL with a path of the form /Users/<name>/Library/Container/<bundle id>/Data/<folder...> you can use NSRegularExpression to match against this and map it to /User/<name>/<folder...>. Writing the RE is left as an exercise!
HTH
I'm new to Mac OS development, so I have simple question. I have a NSURL object of a folder, I want to keep this URL and make it bulletproof to app quit/reboot/folder rename. So, I made a NSData bookmark. I'm a little confuse right now, where I must save this NSData object for future use.
It is better to save object to NSUserDefaults?
Or I must make a file in my bundle and store this object in it, if so, what must be an extension of that file, and is it "safe"?
Or I must save that file in Application Support Directory ?
After I write this question, I found another one, what if I will have more data to save like NSString objects or NSNumber or else, I must make another files with info, or could make a one file with all that necessary info?
NSUserDefaults is used to store user preference and other data that will be used by application in the next run. For your instance you can use it.
Application bundle usually not used for writing data. Specifically user may be standard user in that case he/she will have only read,execute permission to App bundle and attempt writing inside bundle will fail.
Application Support directory is used to save files and other big data that application needs in the next run .If data size is less then it is preferred to store in NSUserDefaults.
You can define your own keys to save other NSString, NSNumber etc objects to NSUserDefaults. Same keys is used to read from NSUserDefaults.
One of the nice features of BBEdit is how it keeps track of files no matter what happens to those files. The application that I am working on needs to keep track of the location of a number of files owned by the user. The user can move or delete these files and my application needs to know where those files are even if my application was not running at the time the change in location happened.
What is a recommended strategy for this problem or what could it be?
Keeping track of files while the application is running is not the problem. I want the correct path to the files when my application is running no matter what happened to those files when my application was not running.
Is manually searching for the files the best approach or is there an API that I am overlooking that makes this easier?
Starting from 10.6, it is done by “Bookmarks” functionality of NSURL:
Bookmarks are a new facility for generating persistent references to resources identified by URLs. A bookmark is a data object generated by the system from a resource URL. The bookmark data encapsulates a durable, opaque reference to the underlying resource as well as value of resource properties captured when the bookmark was created. A bookmark can be stored in memory or on disk and later used to access the resource property values it contains, or resolved to cover the underlying resource’s URL. In the case of file system resources, the bookmark is capable of locating resources that have been moved or renamed since the bookmark was created, similar to Alias Manager aliases. Note that in this release, bookmarks resolve only by path.
The following new NSURL methods are further documented in NSURL.h:
- (NSData *)bookmarkDataWithOptions:(NSURLBookmarkCreationOptions)options includingResourceValuesForKeys:(NSArray *)keys relativeToURL:( NSURL*)relativeURL error:(NSURL **)error;
- (NSURL*)initByResolvingBookmarkData:(NSData*)bookmarkData options:(NSURLBookmarkResolutionOptions)options relativeToURL:(NSURL *)relativeURL bookmarkDataIsStale:(BOOL *)isStale error:(NSError **)error;
+ (NSURL *)URLByResolvingBookmarkData:(NSData *)bookmarkData options:(NSURLBookmarkResolutionOptions)options relativeToURL:(NSURL *)relativeURL bookmarkDataIsStale:(BOOL *)isStale error:(NSError **)error;
+ (NSDictionary *)resourceValuesForKeys:(NSArray *)keys fromBookmarkData:(NSData *)bookmarkData;
Before 10.6, it was done with aliases.
I used to be able to launch a locally installed helper application by registering a given mime-type in the Windows registry. This enabled me to allow users to be able to click once on a link to the current install of our internal browser application. This worked fine in Internet Explorer 5 (most of the time) and Firefox but now does not work in Internet Explorer 7.
The filename passed to my shell/open/command is not the full physical path to the downloaded install package. The path parameter I am handed by IE is
"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\
EIPortal_DEV_2_0_5_4[1].expd"
This unfortunately does not resolve to the physical file when calling FileExists() or when attempting to create a TFileStream object.
The physical path is missing the Internet Explorer hidden caching sub-directory for Temporary Internet Files of "Content.IE5\ALBKHO3Q" whose absolute path would be expressed as
"C:\Document and Settings\chq-tomc\Local Settings\Temporary Internet Files\
Content.IE5\ALBKHO3Q\EIPortal_DEV_2_0_5_4[1].expd"
Yes, the sub-directories are randomly generated by IE and that should not be a concern so long as IE passes the full path to my helper application, which it unfortunately is not doing.
Installation of the mime helper application is not a concern. It is installed/updated by a global login script for all 10,000+ users worldwide. The mime helper is only invoked when the user clicks on an internal web page with a link to an installation of our Desktop browser application. That install is served back with a mime-type of "application/x-expeditors". The registration of the ".expd" / "application/x-expeditors" mime-type looks like this.
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.expd]
#="ExpeditorsInstaller"
"Content Type"="application/x-expeditors"
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller]
"EditFlags"=hex:00,00,01,00
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell]
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open]
#=""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\ExpeditorsInstaller\shell\open\command]
#="\"C:\\projects\\desktop2\\WebInstaller\\WebInstaller.exe\" \"%1\""
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MIME\Database\Content Type\application/x-expeditors]
"Extension"=".expd"
I had considered enumerating all of a user's IE cache entries but I would be concerned with how long it may take to examine them all or that I may end up finding an older cache entry before the current entry I am looking for. However, the bracketed filename suffix "[n]" may be the unique key.
I have tried wininet method GetUrlCacheEntryInfo but that requires the URL, not the virtual path handed over by IE.
My hope is that there is a Shell function that given a virtual path will hand back the physical path.
I believe the sub-directories created by IE are randomly generated, so you won't be able guarantee that it will be named the same every time, and the problem I see with the registry method is that it only works when the file is still in the cache...emptying the cache would purge the file requiring yet another installation.
Would it not be better to install this helper into application data?
I'm not sure about this but perhaps this may lead you in the right direction: try using URL cache functions from the wininet DLL: FindFirstUrlCacheEntry, FindNextUrlCacheEntry, FindCloseUrlCache for enumeration and when you locate an entry whose local file name matches the given path maybe you can use RetrieveUrlCacheEntryFile to retrieve the file.
I am using a similar system with the X-Appl browser to display WAML web applications and it works perfectly. Maybe you should have a look at how they managed to do it.
It looks like iexplore is passing the shell namespace "name" of the file rather than the filesystem name.
I dont think there is a documented way to be passed a shell item id on the command line - explorer does it to itself, but there are marshaling considerations as shell item ids are (pointers to) binary data structures that are only valid in a single process.
What I might try doing is:
1. Call SHGetDesktopFolder which will return the root IShellFolder object of the shell namespace.
2. Call the IShellFolder::ParseDisplayName to turn the name you are given back into a shell item id list.
3. Try the IShellFolder::GetDisplayNameOF with the SHGDN_FORPARSING flag - which, frankly, feels like w'eve just gone in a complete circle and are back where we started. Because I think its this API thats ultimately responsible for returning the "wrong" filesystem relative path.
Some follow-up to close out this question.
Turned out the real issue was how I was creating the file handle using TFileStream. I changed to open with fmOpenRead or fmShareDenyWrite which solved what turned out to be a file locking issue.
srcFile := TFileStream.Create(physicalFilename, fmOpenRead or fmShareDenyWrite);