2023-05-17 19:27:46 +02:00
|
|
|
<script>
|
|
|
|
import { createEventDispatcher } from "svelte";
|
|
|
|
import IconBlock from "../../file_viewer/viewers/IconBlock.svelte";
|
2024-08-30 16:17:48 +02:00
|
|
|
import { fs_thumbnail_url } from "../FilesystemAPI";
|
2024-03-15 22:16:28 +01:00
|
|
|
import TextBlock from "../../file_viewer/viewers/TextBlock.svelte";
|
2023-05-17 19:27:46 +02:00
|
|
|
let dispatch = createEventDispatcher()
|
|
|
|
|
2024-08-09 13:02:07 +02:00
|
|
|
export let nav
|
2023-05-17 19:27:46 +02:00
|
|
|
</script>
|
|
|
|
|
2024-02-16 14:50:34 +01:00
|
|
|
<slot></slot>
|
|
|
|
|
2024-08-09 13:02:07 +02:00
|
|
|
<h1>{$nav.base.name}</h1>
|
2023-05-17 19:27:46 +02:00
|
|
|
|
2024-08-09 13:02:07 +02:00
|
|
|
<IconBlock icon_href={fs_thumbnail_url($nav.base.path, 256, 256)}>
|
|
|
|
Type: {$nav.base.file_type}<br/>
|
2023-05-17 19:27:46 +02:00
|
|
|
No preview is available for this file type. Download to view it locally.
|
|
|
|
<br/>
|
|
|
|
<button class="button_highlight" on:click={() => {dispatch("download")}}>
|
|
|
|
<i class="icon">download</i>
|
|
|
|
<span>Download</span>
|
|
|
|
</button>
|
|
|
|
</IconBlock>
|
|
|
|
|
2024-08-09 13:02:07 +02:00
|
|
|
{#if $nav.base.path === "/me/.search_index.gz"}
|
2024-03-15 22:16:28 +01:00
|
|
|
<TextBlock>
|
|
|
|
<p>
|
|
|
|
Congratulations! You have found the search index. One of the
|
|
|
|
filesystem's dirty little secrets.
|
|
|
|
</p>
|
|
|
|
<p>
|
|
|
|
I needed a place to store an index of each user's files so I could
|
|
|
|
make them searchable. Now, there are search databases like
|
|
|
|
ElasticSearch and such, but that's a lot of work to set up and
|
|
|
|
maintain.. Instead I opted to simply put the full path of every file
|
|
|
|
in your filesystem in a text file. That's what you're looking at
|
|
|
|
here. That can add up to a lot of data, but since the paths usually
|
|
|
|
have a lot of repetitive elements it compresses incredibly well.
|
|
|
|
You'd be hard-pressed to grow this index over even 1 MB. Honestly,
|
|
|
|
this search system is incredibly efficient, I'd be surprised if
|
|
|
|
EleasticSearch could even match it.
|
|
|
|
</p>
|
|
|
|
<p>
|
|
|
|
This file is updated 10 minutes after the last time you modify a
|
|
|
|
file on your filesystem. So if you're constantly uploading and
|
|
|
|
deleting files your search index might never update and you will be
|
|
|
|
left with stale search results.
|
|
|
|
</p>
|
|
|
|
<p>
|
|
|
|
If you delete this file then search will stop working until the file
|
|
|
|
is regenerated 10 minutes later. If you replace this file with a
|
|
|
|
different file then that file will be overwritten 10 minutes later.
|
|
|
|
And if you replace this file with a directory with the same name
|
|
|
|
then search will stop working completely until you delete the
|
|
|
|
directory (yes, I tested this case).
|
|
|
|
</p>
|
|
|
|
<p>
|
|
|
|
Each time you type a search term in the search dialog this file gets
|
|
|
|
decompressed and searched on the fly. There is no trickery here, the
|
|
|
|
file simply gets read line by line. Modern CPUs are incredibly good
|
|
|
|
at searching for text. I benchmarked it once, I don't remember the
|
|
|
|
exact numbers but it was somewhere along the lines of one gigabyte
|
|
|
|
of text per second. Fast enough to be unnoticeable even if you have
|
|
|
|
millions of files in your filesystem.
|
|
|
|
</p>
|
|
|
|
</TextBlock>
|
|
|
|
{/if}
|
|
|
|
|
2023-05-17 19:27:46 +02:00
|
|
|
<style>
|
|
|
|
h1 {
|
|
|
|
text-shadow: 1px 1px 3px var(--shadow_color);
|
|
|
|
line-break: anywhere;
|
|
|
|
}
|
|
|
|
.icon {
|
|
|
|
display: inline-block;
|
|
|
|
vertical-align: middle;
|
|
|
|
}
|
|
|
|
</style>
|