I'm trying to implement a class which uses a NSMetadataQuery to find objects within a specified location. I tried it with the user's Downloads folder and the user's .Trash folder. Querying the Downloads folder works find but the query for the .Trash folder always return 0 results (though there are files in it).
I'm creating an NSPredicate with the value of
((kMDItemDisplayName != \"*\"))
and the search scope
/Users/xyz/.Trash
But that doesn't work. Using the search scope
/Users/xyz/Downloads
works fine.
I have read that Spotlight may ignore invisible files. So I created a second predicate with
kMDItemFSInvisible == YES
and combined them both to an NSCompoundPredicate with an "AndPredicateType". But this doesn't work as well (neither works "OrPredicateType").
Does anybody have a clue?
Just to mention: I'm using Swift with Xcode 6 Beta 5, but I think that doesn't matter.
Edit
The reason for this all: I want to find ALL items within a specified folder. I could use NSFileManager... but retrieving file information from it is a pain (incredibly slow when retrieving the attributes file by file).
Depending on Apple's documentation it doesn't seem to be possible to use NSMetadataQuery for querying the Trash folder:
Note: It is important to remember that on OS X, while file-system metadata is available on all volumes, other metadata attributes are not. CDs, DVDs, disk images and System directories are not indexed by Spotlight.
Related
I followed the “build mobile apps with Xamarin.Forms” course. On the “store local data with SQLite in a Xamarin.Forms app” section, they say iOS provides two folders to deal with the files saved on a device:
the Documents folder, for user-generated data only.
the Library folder, for for app-generated data.
Then, this subsection is presented:
What I don’t understand is: is this the correct way to deal with the iOS Documents folder? I ask this because they explicitly say libFolder contains the appropriate Library location. What about the Documents folder required by Apple’s guidelines?
There are detailed information about different purposes of folders in iOS, in this document:
Documents:/
Use this directory to store user documents and application data files.
The contents of this directory can be made available to the user
through iTunes file sharing (although this is disabled by default).
Add a UIFileSharingEnabled Boolean key to the Info.plist file to allow
users to access these files.
Even if an application doesn’t immediately enable file sharing, you
should avoid placing files that should be hidden from your users in
this directory (such as database files, unless you intend to share
them). As long as sensitive files remain hidden, these files will not
be exposed (and potentially moved, modified, or deleted by iTunes) if
file sharing is enabled in a future version.
You can use the Environment.GetFolderPath
(Environment.SpecialFolder.MyDocuments) method to get the path to the
Documents directory for your application.
The contents of this directory are backed up by iTunes.
Library/:
The Library directory is a good place to store files that are not
created directly by the user, such as databases or other
application-generated files. The contents of this directory are never
exposed to the user via iTunes.
You can create your own subdirectories in Library; however, there are
already some system-created directories here that you should be aware
of, including Preferences and Caches.
The contents of this directory (except for the Caches subdirectory)
are backed up by iTunes. Custom directories that you create in Library
will be backed up.
Please read the document and feel free to ask if you have other problems.
Update
to access update answer:
iOS:
string docFolder = Environment.GetFolderPath(Environment.SpecialFolder.Personal);
string libFolder = System.IO.Path.Combine(docFolder, "..", "Library");
Android:
string path = Environment.GetFolderPath(Environment.SpecialFolder.Personal);
I am trying to build an alternative file manager that works similar to the default Finder in Cocoa.
As you can imagine, the app needs to show a list of files/subfolders in certain directory, and when the user click on an item, it checks whether it's a folder or a file that a user has clicked. If it's a folder, the app simply shows the content of the folder. If it's a file, it will be opened with the default application.
I used NSFileManager.fileExists(atPath:isDirectory:) to determine if an item at certain path is a folder. This works well in most cases, but for things like something.app or project.xcodeproj, they are also considered as directories according to the method.
I know it's true that technically they are just folders, but is there a way in Cocoa to distinguish them from actual folders?
Use (NS)URL.
Get the values for resource keys isDirectoryKey and isPackageKey via resourceValues(forKeys.
In case of bundles isPackage is true.
I have a sandboxed application that uses a document format which can contain embedded filenames. E.g. some of these referenced files are for image files which the user selects in order to associate the image file with data stored in the document. Whilst such images will sometimes be located in the users pictures folder, sometimes they are elsewhere. The document format itself cannot be changed for portability reasons (it is shared with an existing Windows version of the app).
In order for the app to be able to access the files whose names are embedded within the document, when the user selects a filename (using nsopenpanel) to be stored in the document like this, the app also creates an app-scoped security scoped bookmark for each such stored filename. It then stores these bookmarks by serialising them to another file. When the app runs again it loads its previously serialised bookmarks and uses them when accessing the 'embedded' filename and that works fine.
But when I copy such a document (and its associated serialised bookmarks file) from one Mac to another, it doesnt work, even though all the files the bookmarks refer to are known to exist on both Macs. What happens is that whilst the app opens the document file ok (after the user selected it with an nsopenpanel), and successfully reads in the serialised bookmarks from its associated serialised bookmarks file (which again the user has selected using nsopenpanel), and even though the exact same filenames that the bookmarks refer to are known to exist on the other Mac (and can be accessed by the user through finder etc), the sandboxed app still cannot access them. Resolving the bookmarks seems to fail.
The question is: are app-scoped bookmarks restricted to only working on the Mac on which they were created? If I cannot move an app-scoped bookmark from one system to another, how else can I achieve the effect I want without forcing the user to have to manually re-select every such 'embedded' filename with an nsopenpanel?
Tried to find the answer to this question in the Apple docs without success.
I take it it goes without saying that security-scoped bookmarks can only be used by the app that creates them.
No, because if this were possible, developers could save security-scoped bookmarks to sensitive files/directories on their own computers and then deploy their apps and have access to those same sensitive files/directories on other peoples' computers.
In my Mac app I have an NSMetadataQuery to watch the app's iCloud directory. When the user decides to enable iCloud from within the app I do the following in this order:
Call [[NSFileManager defaultManager] URLForUbiquityContainerIdentifier:nil] to establish access to the iCloud container
Start a NSMetadataQuery to find all files (pattern: "*") in the iCloud container
Now I iterate over all files in the local container and move them to iCloud by using [fileManager setUbiquitous:YES itemAtURL:fileURL destinationURL:targetURL error:&error]
I have two types of documents that I move to iCloud:
The actual documents stored as file packages
For each document I have a .preview file as simple binary file
My problem is that the meta data query only returns my binary preview files, but not my actual documents until I relaunch my app (or open a Finder window of the app's iCloud folder from the Terminal - in this case my app gets another query result with all files).
So is this some weird caching issue? Is this because the documents are file packages and not simple binary files?
I don't see why that should be a problem. If I restart my app the query does return all files correctly.
Could this be a problem with the way my custom document type is exported in Info.plist?
Could this be a problem with the way my custom document type is
exported in Info.plist?
I suppose so: the issue you are describing is most likely because your document format is a file package (I assume written with NSFileWrapper). Remember that the package bit is set when writing the file, so if you have other apps writing to iCloud, that could make the issue much more confusing as it's not about interpreting a file bundle but writing it in a correct manner.
NSMetadataQuery unfortunately ignores folders, so your files will never be reported back unless you have correctly registered your filetype as bundle in the application that writes the file to the iCloud container.
There are a lot of similar and potentially confusing settings in the info.plist, so many things that can go wrong. I experienced an issue when I registered my document filetype correctly on OS X, but failed to do so on iOS: https://stackoverflow.com/a/14993694/388412
The first thing you should do is to go to https://developer.icloud.com/#documents and see if you're looking at files (correct) or folders (problem).
Work on your info.plist document types until you see the documents as files, then it should work.
is there a way to "hook" into the OSX Finder to perform the following:
When my Application starts, the User sees a Folder in his Finder which is created by my application. Inside this Folder the User sees Files from several Folders...a unified view to several Files in several Folders that the User specified in my Application.
So, in this "Unified Folder" are not the real Files, they are still in there original Folder but the User sees them in this one Folder as if there were all his real Files in this new Folder. So there is no copying or moving involved.
To be honest, I've no Idea if it's possible and what I should looking for inside the Cocoa SDK. Maybe there is an API for the Finder itself or some other way?!
Regards
twickl
First option is your application could create aliases to the original files. The Finder will show these with a small arrow "badge" over the icon, so it is clear they are not the original files but aliases of them.
If you don't like the badges on the icons creating hard links may give you what you want.
Mac OS X presents a view of the HFS+ (Mac) filesystem which matches the UFS (Unix) one and you have access to hard and symbolic links. The latter are treated by the Finder similar to aliases but the former are indistinguishable from the original files as they are the original files - under the Unix filesystem a file in a directory is just a reference (the inode number) to the real file, each entry in a directory is just a hard link to the actual file, and a file can have any number of hard links to it (a file is deleted when the link count drops to 0, think of the retain/release model if that helps).
At the Cocoa level NSFileManager has methods to create hard links, or you can use the Unix level link(2) function.