Have Alfred download iCloud files before opening

[nikivi]

I have a problem where I have a file filter that searches for PDF files on my system. Firstly Alfred will show the file in both ~/Documents and iCloud Drive.

 

 

Not sure how to best solve this as I do have ~/Documents and ~/Desktop synced with iCloud. Perhaps I should just ignore ~/Documents folder in Alfred Prefs and only keep it to iCloud Drive? Or the other way?

 

That's one of the problems. The other is that if I do activate on any of the files I am met with this error:

 

 

Which I assume is due to macOS putting the files in the cloud. In finder, I can still open the file with CMD+O like here:

 

And macOS will open the file fine, downloading it first. It would be great if Alfred did the same under the hood if possible.

 

 

 

[nikivi]

Speaking of why Apple decides to put those files in the cloud is a mystery to me. Here is my storage on the macbook:

 

 

And here are the iCloud settings:

 

 

There should be more than 500GB left on the system. I think I tried to turn off the Optimize Mac Storage option too and the issue persists. 

So yeah, I hope Alfred can solve the above issue of Alfred not erroring out if file is in the cloud and dowloading it first, then opening it. If macOS API allows this.

 

Thank you.

 

Edited August 9, 2020 by nikivi

[nikivi]

The file filters look like this:

 

 

Speaking of scoping issue (problem #1). I could do this:

 

Then I won't get results from iCloud Drive. But thats not perfect as I want results from ~/Documents only and not iCloud Drive / Documents. 

 

 

[nikivi]

So I guess I have to somehow only have iCloud Drive / Documents ignored but not sure how to do it. Here is my search scope of folders.

 

 

Would appreciate any help on this. Ideally it would be nice if Alfred dealt with this issue in the background. That is assume user will have ~/Documents content duplicated to iCloud Drive too so only consider one of the locations.

 

And the issue with opening a file from Alfred that is in Apple Cloud would open it up by downloading it first and opening it (same as how cmd+o in Finder works).

Edited August 9, 2020 by nikivi

[vitor]

The question that needs to be answered first if if this is even possible. Does Apple provide APIs that developers can use to achieve this?

 

Considering how closed and automation-hostile they are under Cook, and the clusterfuck that is Cloud, there’s a good chance this isn’t easily achievable.

[Andrew]

This is so blatantly a bug in Apple's API for opening files, as it should never be asking for the app to open their own .iCloud files.

 

Have you tried associating .iCloud files with finder? As Finder seems to download these files before opening them. Alternatively, perhaps some AppleScript to tell Finder to open the .iCloud file to see if that instigates the download.

 

I can't see how to get my Mac to force offload a file to iCloud (to get a .iCloud file), so I can't test this for myself, but if one of these methods works, I could look at adding a workaround into Alfred.

[nikivi]

11 minutes ago, Andrew said:

Have you tried associating .iCloud files with finder?

 

I don't know how I can do it.

 

11 minutes ago, Andrew said:

perhaps some AppleScript to tell Finder to open the .iCloud file to see if that instigates the download

 

Would that mean I would have to change my file filter workflow to instead of passing it to `Open File` action, I would have to pass it to AppleScript code that first checks if it's iCloud file and converts it? Assuming this AppleScript code exists.

[nikivi]

Still confused what's meant by `Have you tried associating .iCloud files with finder`. 😞

[nikivi]

It's already associating opening .icloud files with pdf app of my choice.

 

It's already associating .cloud files with opening it i

 

[nikivi]

I assume this is something obvious as no one wants to reply. Any help is still very appreciated. ❤️

Edited August 13, 2020 by nikivi

[vitor]

1 hour ago, nikivi said:

I assume this is something obvious as no one wants to reply.

 

Why would you assume that? You’ve been part of this community long enough to know we don’t shy way from questions, no matter how simple. You should instead assume no one had the chance to look at it; or is busy; or enjoying a break; or missed this post; or doesn’t know; or can’t test. I doubt there’s a single post on this forum from the past half-decade (likely longer, probably ever) that was left without a reply for having an obvious answer. I’m optimistic you didn’t mean anything negative by it, but I am also surprised you’d entertain that idea as a genuine possibility.

I, for one, don’t have any of those undownloaded iCloud files to perform tests on and it’s not like you can give us one. I’m also too weary of iCloud Drive behaviour to risk playing with letting them be deleted or not, but even if I were to do it it’s not like we have control over it.

Posting multiple times in a row also doesn’t help. From an outside view (e.g. checking on posts via RSS), frequent posting seems to indicate a discussion is going underway, which tends to mean progress is being made.

Try changing the file association, as mentioned. If you can’t do it via a GUI, try duti (available on Homebrew). You may need to run mdls the file for useful information.

[nikivi]

51 minutes ago, vitor said:

Why would you assume that? You’ve been part of this community long enough to know we don’t shy way from questions, no matter how simple

 

I just assumed it as I saw @Andrew answer on issues whilst this was ignored. So I tried to create a reason in my head why he would do it. So I assumed it was probably due to him thinking it would be a waste of time to answer me as it should be obvious.

 

Thank you for your comment, will try it now. 

 

Oh and I am aware that no one owns an explanation to anything, I just expected some kind of answer as it's something Andrew himself said and I just wanted to ask for clarification but never got any. 😞

Edited August 13, 2020 by nikivi

[nikivi]

48 minutes ago, vitor said:

You should instead assume no one had the chance to look at it; or is busy; or enjoying a break; or missed this post; or doesn’t know; or can’t test

 

Yeah, you are right. I did assume it but then saw the other replies to other user's questions so thought I was getting ignored for some reason. In any way, I apologize and appreciate your response a lot @vitor

[nikivi]

53 minutes ago, vitor said:

Try changing the file association, as mentioned. If you can’t do it via a GUI, try duti (available on Homebrew). You may need to run mdls the file for useful information

I am still confused. The .cloud files are still associated to be opened with PDF reader as Finder seems to ignore the .cloud part and take into account the .pdf before it. As screenshot above shows.

 

Do I need to change file association of the .icloud files to something else? And if so, to what?

[nikivi]

I have a feeling there is no solution to this beyond not using iCloud to sync ~/Documents. 😢

Edited August 13, 2020 by nikivi

[nikivi]

I also still don't get how to get rid of duplicate results. I suppose I should add a folder to here:

 

 

But I don't get which one. It can't be ~/Documents as I can't even find it in Finder:

 

 

It's part of iCloud Drive. But I can't ignore iCloud Drive because that's where the ~/Documents is (I think) amongst other folders I care about being searched.

 

 

Very confused honestly. 😞

 

I don't want to stop syncing ~/Desktop and ~/Documents to iCloud as I want access to these files from iOS too. 

 

Edited August 13, 2020 by nikivi

[Andrew]

@nikivi I believe the .icloud extension is a generic one which denotes a file is currently not on your Mac.

 

The bug in macOS is that when you double click a .icloud file in Finder, it downloads it then opens it in the app of the real file type, e.g. a pdf. If you request to open this icloud file via the macOS cocoa API, macOS asks you to associate the .icloud file with an app, which is wrong, as any file type could have an icloud extension. It looks like you associated this generic icloud type with PDF Expert, which I think is wrong.

 

When I say associate the .icloud files with Finder, I'm wondering if that would be the same as using cmd+o on any file with a .icloud extension, which you say downloads first then opens it. My other alternative suggestion was finding out if you can hand that file off to Finder to open with AppleScript.

 

I haven't been able to test this as I can't get offloaded icloud files on my Mac. If anybody knows how to force this, let me know!

[vitor]

26 minutes ago, Andrew said:

I haven't been able to test this as I can't get offloaded icloud files on my Mac. If anybody knows how to force this, let me know!

 

Tried this right now and it worked for me: On the Mac, I turned on Optimise Mac Storage on the iCloud Drive preferences. On the iPhone, I went into the Photos app, picked one and on the Share Menu did a Save to Files and saved to iCloud Drive. The photo showed up on the Mac undownloaded.

 

The important steps should be to turn on Optimise Mac Storage on the target Mac and then adding a file to iCloud Drive from a different device.

[ljdinet]

If anyone has come up with a solution to this problem I'd love to know! 

[Skip R.]

Hi, everyone. This issue has been bugging for a while because I make heavy use of iCloud Drive and find it to be incredibly useful. So, I'd like it to cooperate better with Alfred. I've discovered that interacting with files that are offloaded to iCloud (also called "ubiquitous items") is possible with the (NS)FileManager API.

 

What is probably initially most useful is the "isUbiquitousItem" method, which can be used to conditionalize the code path that handles files offloaded to iCloud by checking whether a file can potentially be evicted from the filesystem. From there, you can kick off a file download with the "startDownloadingUbiquitousItem" method. To check whether the download is complete, you can observe the "NSMetadataQueryDidUpdate" notification via NotificationCenter in conjunction with the usage of an NSMetadataQuery in order to track the availability of the file.

 

The "resourceValues" method on the URL class lets you pass "ubiquitousItemDownloadingStatusKey" as a desired key, which lets you check the downloading status of a file ("current" (present on disk, up to date), "downloaded" (present on disk, but stale), and "notDownloaded"). There are other keys such as "ubiquitousItemDownloadingErrorKey", which grants you access to the error object if the download fails. Alfred could potentially check this key (and others) to present helpful (error) messages to the user when trying to open a file that needs to be downloaded, such as a lack of internet connection or disk space.

 

Here is a code sample, in Swift, demonstrating the above (tested in Xcode Version 15.0 beta 2 (15A5161b) with macOS 13.4.1 (c) (22F770820d)):

 

let manager = FileManager.default
let path = "/Users/slice/Library/Mobile Documents/com~apple~CloudDocs/Downloads/music 2/.just for me alac.m4a.icloud"
let url = URL(filePath: path)

// In this case, `true`.
manager.isUbiquitousItem(at: url)

let query = NSMetadataQuery()

// In a real application, this should probably be a more resilient query. Unfortunately, we are unable
// to use fully-qualified paths (NSMetadataItemPathKey) with this API for some reason. ¯\_(ツ)_/¯
query.predicate = NSPredicate(format: "%K == %@", NSMetadataItemFSNameKey, "just for me alac.m4a")

NotificationCenter.default.addObserver(forName: .NSMetadataQueryDidUpdate, object: query, queue: nil) { notification in
  guard let result = query.results.first as? NSMetadataItem else {
    return
  }
  let path = result.value(forAttribute: NSMetadataItemPathKey) as! String
  print("Ubiquitous file downloaded: \(path)")
  let resourceValues = try! URL(filePath: path).resourceValues(forKeys: [.ubiquitousItemDownloadingStatusKey])
  let status = resourceValues.ubiquitousItemDownloadingStatus!
  print("Status: \(status)")
  guard status == .current else {
    return
  }
  print("Attempting to open.")
  NSWorkspace.shared.open(URL(filePath: path))
  // Opening the file triggers another metadata query update (likely increasing the amount of times
  // opened). Stop the query to prevent an infinite loop.
  query.stop()
}
query.start()

try! manager.startDownloadingUbiquitousItem(at: url)

 

In my case, I am hardcoding the path to the ubiquitous file (with extension ".icloud"). The "isUbiquitousItem" method returns "true" for these paths. Before kicking off the download (which takes place in the background, asynchronously), I register an observer and NSMetadataQuery to track the download status of the file. This is a bit tricky because Spotlight's APIs do not let you form a query over a specific path for some reason, so I have just hardcoded the name of the file. I hope that Alfred has its own ways of coping with this limitation that can hopefully be put to use here.

 

I would love to see this integrated into Alfred. It's much, much faster than Apple's vanilla Spotlight UI for me when it comes to searching files, and I use iCloud Drive a ton!

 

P.S. You can interact with ubiquitous items from the command line via the "brctl" tool. See "man 1 brctl".

You can run "brctl download <path>" and "brctl evict <path>" to download a local copy and remove local copies, respectively. There are also other commands related to monitoring, versioning, and logging. But, if you just want to download or evict a file with Finder, you can do that with the "Download Now" and "Remove Download" menu items that are available on ubiquitous files.

 

cc @Andrew

Edited July 20, 2023 by Skip R.