Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
hiilppp opened this issue May 17, 2014 · 3 comments
Closed

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

hiilppp opened this issue May 17, 2014 · 3 comments
Milestone

Comments

@hiilppp
Copy link

@hiilppp hiilppp commented May 17, 2014

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
Copy link
Member

@pjrobertson pjrobertson commented May 17, 2014

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
Copy link
Member

@pjrobertson pjrobertson commented May 17, 2014

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
Copy link
Member

@skurfer skurfer commented May 19, 2014

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.

@skurfer skurfer added this to the 1.2.0 milestone May 19, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants