When using pnpm tauri dev, a panic is thrown and the app was closed.

> pnpm tauri dev

> [email protected] tauri D:\Joshua\Code\Web\FileExplorer
> tauri "dev"

     Running BeforeDevCommand (`yarn dev`)
yarn run v1.22.19
$ vite

  VITE v4.3.9  ready in 3398 ms

  ➜  Local:   http://localhost:1420/
  ➜  Network: use --host to expose
        Info Watching D:\Joshua\Code\Web\FileExplorer\src-tauri for changes...
   Compiling file-explorer v0.0.0 (D:\Joshua\Code\Web\FileExplorer\src-tauri)
warning: unused import: `rayon::prelude`
 --> src\file_explorer\search.rs:6:5
  |
6 | use rayon::prelude::*;
  |     ^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: variable does not need to be mutable
  --> src\file_explorer\search.rs:39:21
   |
39 |                 let mut score;
   |                     ----^^^^^
   |                     |
   |                     help: remove this `mut`
   |
   = note: `#[warn(unused_mut)]` on by default

warning: `file-explorer` (bin "file-explorer") generated 2 warnings
    Finished dev [unoptimized + debuginfo] target(s) in 1m 05s
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src\file_explorer\mod.rs:74:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[0620/204033.047:ERROR:window_impl.cc(119)] Failed to unregister class Chrome_WidgetWin_0. Error = 0
🚀 A new version of Tauri CLI is available! [2.0.0-alpha.10]
 ELIFECYCLE  Command failed with exit code 101.
PS D:\Joshua\Code\Web\FileExplorer> pnpm update @tauri-apps/cli @tauri-apps/api --latest
Already up to date
Progress: resolved 193, reused 162, downloaded 0, added 0, done
Done in 7.3s
PS D:\Joshua\Code\Web\FileExplorer> pnpm tauri dev

> [email protected] tauri D:\Joshua\Code\Web\FileExplorer
> tauri "dev"

     Running BeforeDevCommand (`yarn dev`)
yarn run v1.22.19
$ vite

  VITE v4.3.9  ready in 1251 ms

  ➜  Local:   http://localhost:1420/
  ➜  Network: use --host to expose
        Info Watching D:\Joshua\Code\Web\FileExplorer\src-tauri for changes...
warning: unused import: `rayon::prelude`
 --> src\file_explorer\search.rs:6:5
  |
6 | use rayon::prelude::*;
  |     ^^^^^^^^^^^^^^
  |
  = note: `#[warn(unused_imports)]` on by default

warning: variable does not need to be mutable
  --> src\file_explorer\search.rs:39:21
   |
39 |                 let mut score;
   |                     ----^^^^^
   |                     |
   |                     help: remove this `mut`
   |
   = note: `#[warn(unused_mut)]` on by default

warning: `file-explorer` (bin "file-explorer") generated 2 warnings
    Finished dev [unoptimized + debuginfo] target(s) in 1.52s
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("EOF while parsing a value", line: 1, column: 0)', src\file_explorer\mod.rs:74:62
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[0620/204440.510:ERROR:window_impl.cc(119)] Failed to unregister class Chrome_WidgetWin_0. Error = 0
🚀 A new version of Tauri CLI is available! [2.0.0-alpha.10]
 ELIFECYCLE  Command failed with exit code 101.
 ```

Why do I say that? Well, the reason your "explorer" is faster is because it is not up to parity with the windows explorer.

You don't scan for file attributes, that alone is a big time saver that you took, windows search scans for file attributes. I am all for third party file explorers, but not when they make absurd claims like this.

Yeah you could probably reach feature parity with the windows explorer and still have faster times, but the time savings you did would not be as big as now.

PS: I am not a windows fan boy, and I also hate the windows explorer's search speeds, but that doesn't mean I'll blindly agree that your explorer is faster.

Hey, I found your project cool, but noticed in the video you're saving the cache as a plaintext file, which could possibly be an issue for filesystems with very large amounts of data. Can you consider using Binary Serialization of the Cache file? I asked an A.I. search engine about this, and it referenced the serde_json and bincode crates.

This PR adds a pipeline that rejects files from a search based on filters and refactors to code to be more understandable and extensible.

All input is welcome. Note: Due to running rustfmt the commit is polluted. All the relevant work is in src-tauri/src/search.rs

Currently the workflow creates a new release every time the dev branch is updated. It would make sense that these executables are only built when changes are made to the main branch.

This PR is separated into 3 commits.

Added Unix Support

The first one is focused on removing previous assumptions about how file systems are laid out. The letters are substituted for mountpoints. This means that on unix systems where there's only one true root and everything is mounted on that tree the mountpoint will be a path relative to the root. On Windows the mount point is whatever lettered disk it happens to be given.

Along with adding mountpoints file system standard directories were added this allows for the react frontend to easily give the user a way to jump into them the same way it happens on other file explorers/managers.

Refactored code

This commit tries to encapsulate logic as long as it makes sense as well as make reasonable renames. The file system was flattened as the hierarchy was confusing to navigate, new modules should be created as needs arise.

Removed lettered assumption, used mountpoint instead

This commit removes the assumption that all disks have a letter assigned to them and instead uses mountpoints. This makes the frontend be in line with the work done on the tauri side.

Notice When testing this I've found that search panics when you haven't entered a disk yet, so if you merge this PR someone should create an issue for this (this is caused by an assumption about letters on search.rs that I haven't touched yet as not to bloat this PR)

Solves #13

Added a compiler to the project with github actions

This compiler works every time a change is made to the repository and takes around 20-30 minutes to compile.

Note:

The following file causes problems to compile it src-tauri/tauri.conf.json

https://github.com/vicentefelipechile/FileExplorer/actions/runs/5365212765/jobs/9733891266

Just a simple fix You can see the bug if you try to search before selecting a drive, the drive is set to "" and an unwrap none panics a thread

something like

thread 'tokio-runtime-worker' panicked at 'called Option::unwrap() on a None value', src/search.rs:88:59 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace thread 'tokio-runtime-worker' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/search.rs:85:34 thread 'notify-rs fsevents loop' panicked at 'called Result::unwrap() on an Err value: PoisonError { .. }', src/filesystem/cache.rs:48:48

I think this should be set to all mounts or the 0th by defualt, and outlined in the ui somehow

@conaticus

i think this may fix part of https://github.com/conaticus/FileExplorer/issues/26

The compiler fails because it does not have the necessary permissions to perform the compilation

To fix this, you have to configure your repository like this

Can we add more info in README.md file , for setting up project locally ?? Someone who is new to Rust or JS and wants to set up project locally will make it easy.

Addresses #6 by using serde_bencode and zstd libraries to encode and compress the Cache file in a more efficient format, taking less overall space on the disk.

Requires further testing, but seems to be working on Windows and Linux thus far.

Very small change that removes the windows bias ('\' is not a path separator on unix systems, this would result in the program erroring out on any of the file operations)

This PR makes the path canonical, meaning it expands the whole path to it's absolute path. So on most unix systems it would give you / or /home/user or whatever mountpoint is being used. On windows it would give you C:\\ or equivalent lettered disks.

A permissions error sometimes occurs when doing file operations such as deletions. Not sure what causes this but maybe to do with conflict with the file watcher for cache invalidation.

For some reason Tauri commands such as file creations pause for a few seconds before executing. This likely due to the main thread being used where it shouldn't.

The interval works well on most systems, but slower systems or systems with a bigger file system have the chance of not being able to recache in time for this 30s interval.

The best solution is to have a check to ensure that the previous recache is completed, and skip if it is not. We could implement an algorithm to check for file changes first, but these usually happen so often that it would be redundant.