"Get File URL" Returns Path Instead of URL in 400B

[hiilppp]

Since the 400B update, the "Get File URL" action returns its argument's unescaped POSIX path (e.g., /some directory/some file.txt) instead of its URL (e.g., file:///some%20directory/some%20file.txt).

(I'm running OS X 10.9.3.)

[pjrobertson]

I can confirm this, and I’m pretty sure it’s caused by e5029a5

That commit was introduced explicitly to remove strings from file QSObjects, whereas in this case we want.

My suggestion is that that commit should be reverted, and the actions should be made to work properly (@skurfer)
Or perhaps the getFileURLs: method should just make the QSObject manually (instead of using the StringHandling convenience method)

17 Mai 2014, at 21:08, hiilppp notifications@github.com wrote:

Since the 400B update, the "Get File URL" action returns its argument's unescaped POSIX path (e.g., /some directory/some file.txt) instead of its URL (e.g., file:///some%20directory/some%20file.txt).

(I'm running OS X 10.9.3.)

—
Reply to this email directly or view it on GitHub.

[pjrobertson]

P.S. Thanks @hiilppp for taking the time to let us know about the issue.

On 17 Mai 2014, at 21:08, hiilppp notifications@github.com wrote:

Since the 400B update, the "Get File URL" action returns its argument's unescaped POSIX path (e.g., /some directory/some file.txt) instead of its URL (e.g., file:///some%20directory/some%20file.txt).

(I'm running OS X 10.9.3.)

—
Reply to this email directly or view it on GitHub.

[skurfer]

I think sniffString is doing its job correctly, and getFileURLs: doesn’t want 99% of what sniffString has to offer. It’s possible that objectWithString: wasn’t quite so “smart” when getFileURLs: was first created to use it.