Receiving files from a script launched via an extension

Scriptable
1

I’m trying to accept one or more files passed in via an extension to a Scriptable script. I’m able to receive a path to the file via args.fileUrls, but the name of the file is always a UUID-like file name.

Is there a way to retrieve the actual file name of the shared file?

2

It may be that Scriptable renames the file in some occasions to avoid collisions with existing files. Shouldn’t be a problem in the case you describe. I’ll look into it.

3

I’ve tried two different scenarios:

  1. Export pdf from iaWriter and then share to Scriptable
  2. Select file in iCloud Drive (outside of Scriptables folder) from Files app and share to Scriptable.

Both files (with different file names) had the same results.

4

I’ve done a handful of tests using the script below. It’s been across a variety of storage providers (including of course iCloud), folder structure depths and file formats. Each has given me the expected filename in the last URL component.

Maybe you could have a quick test and see if that holds true for you too?

alMsg = new Alert();
alMsg.title = "First Received Filename";
alMsg.message = args.fileURLs[0];

//Copy URL to clipboard and display in an alert
Pasteboard.copyString(args.fileURLs[0]);
alMsg.presentAlert();

Example result from iCloud (Keynote’s folder)

image
9B22DB15-6D91-4114-B3AD-0E979569CB9C.jpeg1286×843 78.2 KB

Example result from Working Copy.

image
C9CE23C1-26D8-432A-B2C6-995CEFE0D564.jpeg1698×1020 117 KB

1 Like
5

My code was a bit different, but I grabbed your code to try - same results (exporting a PDF generated in iaWriter):

image
26F3B9EB-4FF6-43FF-BB85-04839B403382.jpeg2224×1668 138 KB

I got a similar result with sharing a file from the Files app (from the Numbers directory) but I can only post one image given my account status.

6

Forgot to mention - in case it’s relevant, I’m running build 1.3.2 (86).

7

Same Scriptable build version for me, but I see a filename for a Numbers file shared from Files.

image
A8D97423-59B2-4380-8220-586E90A7A5EB.jpeg1242×2208 149 KB

8

On a hunch, I just checked the “Always Run in App” setting. I have this turned on for my script (as I was intending to leverage File Bookmarks). I set that automatically when I created a script with your code. Once I turned the setting off and ran the script only in an extension, it works as expected. FYI @simonbs

1 Like
9

Just in case it is of use, here’s a quick set of test results using my script above on a common file being shared from Files.

RUN 1: Always Run in App ENABLED

/private/var/mobile/Containers/Shared/AppGroup/ECA37076-C561-4C4B-B266-36853A79F7D0/ActionExtension/95BA7547-BA51-4C00-BDE3-BE900B96031D

RUN 2: Always Run in App ENABLED

/private/var/mobile/Containers/Shared/AppGroup/ECA37076-C561-4C4B-B266-36853A79F7D0/ActionExtension/FC74F41B-7A07-44BC-B7C4-0417320B4181

RUN 3: Always Run in App DISABLED

/var/mobile/Containers/Data/Application/5E9FC707-1179-486D-8CF4-29E36F5BD8C5/Documents/maps/fileSystem.db
  • It definitely supports the idea of the generation of a transient URL, as it varies between runs.
  • There are significant differences in the structure of the URL path (apart from a small chunk) when the option is enabled/disabled.
1 Like
10

Thanks for looking into this. I just wanted to lte you know that this is fixed in the next update. Files will keep their file names, even when “Always Run in App” is enabled. Inputs that does not have names by itself, e.g. photos, will still have generated file names.

I’m not sure how much value this blurry GIF provides but nonetheless it shows that the issue have been fixed.

Once again thanks for taking your time to provide feedback and look into the issue.

Image-5

1 Like