[BUG?] "file://" deleted after renaming file via right-clicking file path

Vinho

Hi @ctietze!

I discovered to my satisfaction that renaming files via right-clicking the file path not only works for files in the media folder linked to with the ![]() syntax, but also for files linked to with file://. But: If I rename a file linked to with file://, the latter strangely is deleted after the renaming and needs to be added again in order for the link to work.
I guess that's not how it should be?

Best, Vinho

Vinho

Related question that just occurred to me: Is there actually any advantage of linking to files with file:// instead of ![](), or even disadvantages? So far I had assumed that the latter only works for files in the media folder, which actually isn't the case.
An advantage of ![]() seems to be that it handles relative file paths, which file:// doesn't. Any other differences?

ctietze

Thanks for the report! Wasn't aware the URL scheme was stripped for file:// URLs!

@Vinho said:
An advantage of ![]() seems to be that it handles relative file paths, which file:// doesn't. Any other differences?

Basically this is the difference.

The path inside the (...) can be a fully qualified URL or a POSIX file path. The latter supports relative file names in some tools, including The Archive. A fully qualified URL with scheme, domain, path, etc. should be more robust. http://foo.com/bar.png or ftp://... or file://... are all the same in that regard.

With redards to. portability, I'm not sure how Windows would handle either file:// paths or Unix-style file/paths with forward slashes. So the most robust would probably be just ![](filename.png) without the use of subfolders, which has its own drawbacks.

FWIW, I think it's a bad idea to put file paths to things that are not images inside ![](...). Most tools will just bail if the image cannot load, but you never know.

For links to, say, a .pages document I'd personally use <file://..../doc.pages> instead if I had to, i.e. regular file links instead of image syntax. But I'd rather not be in that situation and don't yet have non-image 'attachments' to my notes, so I'm not sure what the best course of action would be. <./media/file.pages> isn't recognized as a relative file link. But maybe it should.

---

I personally just don't want to see the whole of file:///Users/myuser/path/to/notes/media/file.png if I can get away with media/file.png.

Vinho

@ctietze I understand, thanks for your thoughts.
Will stick to my current practice of just using ![]() for things in the media folder then (images and possibly videos), which are supposed to be loaded. Contrary to you I've got a lot of other material (PDFs etc.) to link to in my zettelkasten as well – will continue using file:// for that.

ctietze

@Vinho Well, one could make a point for treating PDFs as an image with multiple "slides" For this implementation, I'm leaning on the fact that Apple offers image loading from PDFs, so from a pragmatical standpoint, that's ok. -- MP3s or DOCX or .keynote files, these I would reference differently.