I have no support/technical question and have seen the support category. (Be aware that direct support questions will be deleted.)
on
Which general topic do you have
When I search using search box in the Files app, I get a list of files/directories that match my request.
However, I haven’t been able to find a way to understand where the file is located in the hierarchy of documents.
I would have expected to be able to see the path in the “Details” section, but unfortunately it isn’t so.
The only way to understand where the document is, is to actually open it.
But when the search returns a lot of documents this is clearly not an option.
Is there a quicker way to see where the doc is?
I am also interested in finding my files after a search. Like you I have the problem, that I dont know where a file is located after searching, but in my case the files can be compressed files, which cannot be opened and will download on click. Maybe it would be a nice feature if there is an additional column for searches like “Path” or just include the path in the details view.
There is a small, very hidden way to get around this: open the details view and then the Activity tab. If you hover over the file name, the path will appear. But that can’t possibly be a solution. It’s just a workaround.
It would be great if it were displayed directly in the details or even in the file list!
Thank you @whisy !!
That’s a very nice find!
Unfortunately, it only works if there’s been activity on that file, and not all kind of activity… e.g. adding a file to the favorites is shown in the activities tab, but it does not show the location.
OK, maybe another workaround will help us then. Just paste the script attached here into your browser’s console (via F12).
You’ll then see the paths in your search results.
I’m not a professional programmer, though. This is just a quick and dirty workaround.
function injectPaths() {
const files = window._nc_files_pinia.state.value.files.files
const allEntries = Object.values(files).map(f => Array.isArray(f) ? f[0] : f)
document.querySelectorAll('tr[data-cy-files-list-row]').forEach(row => {
if (row.dataset.pathInjected) return
const name = row.getAttribute('data-cy-files-list-row-name')
if (!name) return
const entry = allEntries.find(f => f?.displayname === name)
const dir = entry?.dirname ?? '(Pfad nicht gefunden)'
const nameSpan = row.querySelector('.files-list__row-name-text')
if (nameSpan) {
const pathSpan = document.createElement('span')
pathSpan.style.cssText = 'display:block;font-size:0.75em;color:#999;'
pathSpan.textContent = dir
nameSpan.appendChild(pathSpan)
row.dataset.pathInjected = '1'
}
})
}
injectPaths()
const observer = new MutationObserver(() => injectPaths())
observer.observe(document.body, { childList: true, subtree: true })
(Disclaimer: I used AI to help me write the script)
Hi @whisy! Oh, nice workaround. What I’ve found that the first rows from other apps (eg, Tables, Notes) started to be shown as well. Is it possible to limit it somehow to files and fulltextsearch (it is already shown and useful)?
Hi @knedlyk ,
I’ve tried to reproduce this, but I couldn’t see the problem. Can you post a screenshot as an example?
I’m sure, we can limit this function, e.g. by using the URL as an trigger.
Also it is possible to modify the design by CSS or other smart tricks like a mouse over.
I would prefer to just make a little change in the fileapp itself instead this workaround, but I’m not familiar with vue.
You may be able to use the Versions tab in a similar way. All of my files regardless of their history have at least a “Current Version” listed. Hovering over that item will show the file path.
Thank you @scott-nj for your contribution.
However, this is not my experience: hovering over the “Current version” (or any version, actually) just displays “Current version” again.
I am running Nextcloud 32, maybe more recent versions have a different behavior.
I just discovered that copying the internal link from the detail view / sharing tab, and pasting it into your browser’s address bar, will take you directly to the folder containing the file.
Thank you @cbenoist !!
This is actually the most useful suggestion of all this thread, and it works beautifully!
That said, these are all wonderful work-arounds, but the whole point is that NC should have an immediate and much more intuitive way of solving this need.
Do NC developers browse these forum threads, at least sometimes?
