Modify Spotlight metadata for a file outside Spotlight importer? - macos

I would like to modify a Spotlight metadata attribute of a file within my application (i.e. not in a Spotlight importer) but I can't find any API for doing so. Is it possible? Pointers to the relevant docs would be ideal.
In case it's helpful, here's my use case:
I want to store a reference to a file
system path in a Core Data store.
Ideally, I should be able to find the
file even if is moved, potentially
across mounted volumes. My understanding is that
an archived FSRef or AliasRecord will not do the trick because they
are not invariant wrt to moves across mounted
volumes. So my plan was to store a URL
and also to add a UUID (also stored in
the data store) to the file's
Spotlight metadata so that I could
perform a Spotlight query for that
UUID if the URL no longer pointed to
the file when the app goes back to
look for the file.

After further research, using Spotlight is not the best solution for the use case. The AliasRecord is a better persistent storage for a file. It automatically tracks moves/renames/etc. You can read more about AliasRecords here. Chris Hansen has written an Objective-C wrapper for AliasRecords, BDAlias. It's currently available from the rentzsch.com SVN.

Related

Get path to file in storage

I saved a file to storage using:
$request->file('avatar')->store('avatars');
Which saved it to:
storage/app/avatars/avatar.png
How can I get the path to this file/folder (not the URL)? What is the correct way to do this using Laravel's Filesystem?
There is no correct way to do this; because it should not be done. The Storage is an opaque system to talk to different storage systems; as such there is no api to get the backing file path. As an example, that wouldn't work with Amazon S3. The only path your application knows about is the string you send to the Storage facade to work with the file, there are no guarantees that this string is used to generate the filename when the storage system stores the file.
There are some hacks you can use that works for the local disk, but those are not available for the Storage system in general. Using these solutions means that you'll limit yourself to only use the local disk; this will cause you troubles when you need to scale out and add another server. You'll then have two servers with two separate local disks, with separate content.
The correct way to work with the files, that will work for all configurations, is to get the file content (Storage::get), do the modifications (including storing them in a temporary file) and then write back the new file content (Storage::set).
If you're really sure that you will only ever use the local filesystem, use the File facade instead of the Storage facade. I'm unable to find any documentation for this, only the interface it exposes.
Reference: https://github.com/laravel/framework/issues/13610
Try this
storage_path('app/avatars/avatar.png');
you can only get the storage folder path from laravel function, you can give nested folder name after it, it will bind the base url as well
storage_path(folder1/folder2/.../file.png);

How to write a stream to Google Cloud Storage?

I want to write a file in gcs with a stream object but I've only found the "create_file" function that creates a new file object by providing a path to a local file to upload and the path to store it with in the bucket.
Is there any function to create a file in gcs from a stream?
Fuse over GCS
You could try gcsfuse which layers a user-space fs over a bucket but it is only beta s/ware at present. There's a nice section on limitations which you should read first.
I use fog to access GCS but that is a thin layer which doesn't try to impose any additional semantics into the bucket/object model.
Warning, if your problem really requires a standard file-system underneath any possible solution then GCS is not a good fit.
The ability to provide an IO object instead of a File object has only recently been possible. It was added in PR 1335, and will be included in the next release.
Until then, quickest way is to write the stream to a tempfile and upload that. For more see Issue 305.

file-system: SD-Card support

As far as i see the file-system.knownFolders only supports the
Application
Data
Temp
folders on the device storage. Is there any way how to access external storage like SD-Cards?
I have made a little research and found that you could access some directories on the device storage using android.os.Environment.getExternalStoragePublicDirectory(...).toString(). This method will return the path to wanted folder and then you could use NativeScript method to read and write files in this folder. For accessing SD Card should be something similar. In regard to that you could also review my sample project where I am accessing Download folder of the device and console.log names of all files.
You could also review below attached links:
https://docs.nativescript.org/cookbook/file-system
Write a file in external storage in Android
https://developer.android.com/guide/topics/data/data-storage.html

Copy / Backup Persistent Store

Normally when I backed up the core data file for my app, I would just copy the .sqlite file to another location while the app was running. But now that journaling (wal) is enabled, this does not work anymore. I cannot see a way for NSPersistentStoreCordinator or NSManagedObjectContext to write a new file. I'm guessing maybe I have 2 methods:
Close the persistent store and opening it again with #{#"journal_mode" : #"DELETE"} and then copy the .sqlite file.
Add another persistent store and maybe copy from the original ps to the new one ?
Any better ideas ?
Thank you.
Changing the journal mode will eliminate the journal files, so it's simple. I don't know that I'd trust it for your use, though-- because there's no guarantee that Core Data has actually flushed all new changes to the SQLite file. It might be OK, but there might be some in-memory changes that Core Data hasn't written out yet. This is almost certainly safe, but there's a small chance that it won't work right once in a while.
Option 2 would be safer, though more work. I'd create the second persistent store using NSPersistentStoreCoordinator's migratePersistentStore:toURL:options:withType:error: method (which the docs specifically mention as being useful for "save as" operations). Telling Core Data to create the copy for you should ensure that everything necessary is actually copied. Just don't do this on your main persistent store coordinator, because after migration, the PSC drops the reference to the original store object (the file's still there, but it's no longer used by that PSC). The steps would be
Create a new migrate-only NSPersistentStoreCoordinator and add your original persistent store file.
Use this new PSC to migrate to a new file URL.
Drop all reference to this new PSC, don't use it for anything else.

Mac OS X: Where should I store common application data?

What's the standard path on MacOS X for storing application data that is to be shared by different users? I am not talking about temporary data, but data which is used by one particular program on a regular basis and belongs to no particular user. For example a game highscore table.
Thanks,
Adrian
I believe you're talking about Support files - a file that supports the application but is not required to run (your highscore table for example).
These files should be put in ~/Library/Application Support/YourApp or /Library/Application Support/YourApp for shared users.
The Library Directory Stores App-Specific Files
To get the directory, you can use the function "NSSearchPathForDirectoriesInDomains", with the directory parameter being "NSApplicationSupportDirectory", and the domainMask parameter being "NSLocalDomainMask".
(NSApplicationSupportDirectory is the "Location of application support files", while NSLocalDomainMask means "Local to the current machine—the place to install items available to everyone on this machine.")
Some applications put files into the /Users/Shared-directory. I know it's the standard way to share files between users, but I'm not 100% sure it's thought for application data storage.
The there's the /Library*-folder which is thought for systemwide common data, similiar to the /Users/Usernames/Library.
But you certainly shouldn't write data to the Application.app-directory. Users without admin rights won't even have the right to write to these directories.
* = Or /System/Library. Need to verify.

Resources