Dataview request to select file.outlinks hosted in a folder

Help
1

Hi

I have a list of note hosted in “folder A”, those notes have links to other notes which are stored in several folders.

I would like to create a list of file.outlinks from the folder A which are stored in the folder B.

I tried this without success

list file.outlinks from "folder A" 
FLATTEN file.outlinks AS outlink
Where startswith (outlink, "Folder B/")

Any ideas?

Regards
Michel

2

The following query should work:

```dataview
TABLE length(rows) as "\#"
FROM "<FOLDER PATH A>"
flatten file.outlinks as Outlink
WHERE startswith(Outlink.path, "<FULL FOLDER PATH B>")
GROUP BY Outlink
SORT length(rows) DESC
```

Both folder paths should be the full paths, relative to the Vault.

Also added counts + sorting, which you can remove if not needed.

3

Be aware that meta(aLink).path could be different from aLink.file.path. The correctness of the first variant depends on the origin of that link, and it could easily have an empty, IIRC.

4

Hi, Thank you soo much. I just adapted to have a simple list

 ``` dataview
 List FROM "folrder A" 
 FLATTEN file.outlinks as Outlink 
 WHERE startswith(meta(Outlink).path, "Folder B") 
 GROUP BY Outlink SORT DESC

Have a good day

Michel
5

Could you elaborate/explain with an example please?

6

Sorry for taking so much time to get back to you, and now when I get back to you I can’t remember which real life case I experienced in the past where there was a mismatch between following a link versus what was shown when doing meta().

A simple example showcasing the difference:

A pure meta: `= meta([[f98437 link vs file.outlinks]]).path `
A followed link: `= [[f98437 link vs file.outlinks]].file.path `

In my test vault that’s the explicit link to the current file. In live preview this displays as:
image

As can be seen in the first case it doesn’t know the full path, as it hasn’t been expanded upon by Dataview yet, so it’s not a fully qualified link having resolved the path. In the latter case, we force the expansion of the link, and get a better result.

Using a not valid link like in this case:

[[NOT a valid link]] - A pure meta: `= meta([[NOT a valid link]]).path `
[[NOT a valid link]] - A followed link: `= [[NOT a valid link]].file.path `

You’ll also see a slight difference in the handling:
image

Will this affect your query in your vault? Most likely, but it can be an issue in some rare occasions. (Too bad I can’t really remember when I saw this in a real query, and not a constructed example… )

7

Thanks for following up with an example!

So it seems like the behavior is inconsistent between meta(<link>).path and <link>.file.path :

  • meta(<link>).path: Seems to just return the note basename.
    • equivalent to <link>.file.name
  • <link>.file.path: Seems to return the relative file path (relative to the Vault root).

Also, thanks for flagging that meta() still seems to work for “ghost links” (links to notes that don’t yet exist), whereas that standard <link>.file… doesn’t.

I’ll update my answer! Thank you, you’ve taught me something I didn’t know!

8

And you can actually also consider which way to approach testing for non-existent files using these differences. However, take a little care and do some fool proofing to check that you don’t get any positive/negative cases with either method (or that it errors in a good, acceptable way).

I’m thinking that doing something like default(aLink.file, false) as fileExists (or similar) could be a valiant and easy way to check, but I’ve not verified it against the metadataCache or similar for validity.

Further testing should executed, but I’m thinking along these lines to:

```dataview
LIST rows.file.link
WHERE file.outlinks
  AND any(file.outlinks, (link) => !default(link.file, false))
FLATTEN file.outlinks as link
WHERE !default(link.file, false)
GROUP BY link
```

This is a little rude, as it claims embedded files could be non-existent… But it do also show that a non-existing embed displays in the file.outlinks section (it seems) as verbatim text…