When I paste a file path into Add Link the link doesn’t work. It only works if I browse for the file.
Simply pasting the file path worked well in previous versions.
Just tried this, played with it a bit, and here’s some information about that function.
File and No prefix paths ultimately need to look like this:
file:///C:\path\to\file\name.txtThat is, it needs to be a fully-qualified URL for a local filename.
So when you paste a path, and don’t do anything else to it, and click on “file” for a prefix (the prefix is the “file://” part of the link), you’ll get
file://C:\path\to\file\name.txtOnly 2 slashes after file. Those don’t work. You need 3 slashes for the link to work.
If you paste a path (from File Explorer, say), and click “No prefix”, you’ll get:
C:\path\to\file\name.txtand because it doesn’t have “file:///” in front of it, that’s not going to work either.
BUT… if you’re browsing files in your web browser, and “copy link location” from there, “no prefix” should work just fine (to start, type “file:///C:/” into your browser’s address line and navigate from there; right-click the filename you want to link to, “copy link location”, and you now have the fully-qualified URL).
If you click on file for a prefix and paste a copy of the OBJECT (from file explorer, say) you’re linking to into the dialog box, a slash will be prepended to the path, and the resulting link will work (with at least one exception).
However, if you copy the path to a .scrivx file, the link will not work. Not sure why. I mean, Scrivener is open, and it’s the designated handler for those, so why should it not respond to the Windows request to open that?
This is a “bug,” so to speak, because most won’t want such a persnickety function, but otoh, “linking” implies using a web-type system. Remember: fully-qualified URL as the result, or the link doesn’t work. And the function contains almost no smarts in terms of fixing the path into a correct URL.
Hope that helps.
This works fine in 1.9.9.0, so I’m filing it as a bug.
I’m not using the beta, but in v. 1.9.9, I do find that it is still necessary to insert a / manually into the Link dialogue when linking to a File. I’m eagerly looking forward to the release of v. 3; but it will be mildly disappointing if this clunker is not fixed.
Not if you select No prefix.
I think they changed the thing from using two systems to one. So it no longer recognizes a Windows path, but it will recognize a local file URL. If you select “file” it’ll need an extra slash in front; if you select “No prefix” you’ll need “file:///” in front of the Windows path, and I have no idea how a network drive will behave.
Ah, brilliant! Sorry I missed that.
So, they’re making it more complex and clunkier than it was? If you select file, then it seems to me the program ought to format the link properly for a local file URL. And how many writers (as opposed to tech people) would know to put “file:///” in front of a pasted path? But maybe I’m still confused.
No, you’re not confused. I had that thought myself.
First, a little bit of sarcasm [sarcasm]“Dang those pesky *nix folks for creating a standard that is completely different from “The Microsoft Way”. You’d think they had an OS that came before Windows or something.”[/sarcasm].
Yep, the “file:///” is part of the URI specification: w3.org/Addressing/URL/uri-spec.html. Interestingly enough, Microsoft has built that specification into Windows (at least since Windows 7, maybe earlier) and you can test it out using the Run command (which I just spent the last hour or so doing). FWIW, the “file:///” URI is only applicable to local files (mapped network drives as well since they are local resources). It does not work with non-mapped network drives. That is where UNC comes into play - more confusion. Example: a file (test.txt) on the server “foo” subdirectory “bar” that has a mapping to a drive letter “g” can be reached via “file:///g:/bar/test.txt” (note the slashes are reversed from Windows norm). If the network location is not mapped (no drive letter), then “file:///foo/bar/test.txt” will not work because the URI spec says that it only works with local files - prevents folks from using “file:///” to download password file stores from a remote server for instance. However, Microsoft also has UNC (not sure if Scrivener will recognize a UNC path to a file, I haven’t tried it yet) which will get unmapped local network resources assuming you have permission to access that resource. So, “\foo\bar\test.txt” will work from the command line (Run command) - note the slashes are Windows norm.
FYI:
file://mw/roger share/OPS/images/cover.jpgworks for UNC: \\MW\roger share\OPS\images\cover.jpg
Discovered this by browsing for the drive from the dialog box.
But technical details aside, the question that hit me as I figured all that out was, essentially, “Is this too technical for most users?” And I confess, I don’t have an answer.
yes, by about 93 million miles.
Good to know. Will have to play with this.
I’d have to say “Yes.” on technical specs alone. I’m pretty techy and still had to work on it for about an hour to “get it”. Judging by experience in the computer industry in general and browsing both the L&L forums and the Scrivener Facebook pages, the average user doesn’t know or really care where the files are saved to. They just want to be able to access them when they need them (and most don’t even remember the file name they saved it as - “Isn’t that why I have a computer?”. Windows and OS X both try to help by thoughtfully designating a “Documents” folder per user, but we’ve all seen the users that know of only one place to save things (the desktop) and the horror it is to look upon that kind of “organization”.
Thanks, all, good to know I’m not that confused! I don’t like having to add slashes, but I at least know that I have to do it, and more or less why. I really hope they’re able to program the final version so that pore, iggerant lit’ry types don’t have to jump through unnecessary hoops.