Onedrive downloads all files
Describe the bug
I'm using OneDrive to sync my documents. It's a standard setup, where my my docs are under
C:\Users\<user>\OneDrive\Documents.
Problem is: When I go to this folder using Spacedrive, Onedrive begins to download all the files.
Furthermore, Spacedrive is only displaying the downloaded files.
I don't know what happens when the files are downloaded completely, since I don't have enough space to let them download.
Reproduction
- Open Spacedrive
- Go to the Onedrive Documents folder
- Watch your system drive get full
Expected behavior
Spacedrive should display the files without them being downloaded; only downloading them when they are used in any way (Details, Opening, ...).
Platform and versions
Windows 11 Pro, Version 10.0.22631 Build 22631
pnpm: 8.11.0
No rust installed
Stack trace
No response
Additional context
No response
When indexing a location, Spacedrive needs to download files to generate thumbnails + collect metadata about them - there's not really a way to do this without downloading the files. Perhaps the files should be deleted after their metadata is collected?
I've got two ideas / thoughts about that.
Chunk download & delete
Just like you wrote, download the files (preferably in chunks of 5-10 files or smth like that), index and delete them. Onedrive would probably warn the user, but nothing blocking. The obvious problem is that always downloading them is kinda much, especially with a lot of files. Furthermore, already downloaded files would need to remain on the system; don't know a good way to determine whether or not it was already there.
Notice and 3rd party support
Until there is support for clouds (which should include Onedrive?) you could display a notice. Filtering Onedrive paths shouldn't be that much (since they are almost always in the same spot). The note could say something like "This would download all the files. Please wait for cloud support; are you sure you want to continue?".
In any case it would be nice to have a notice or prompt before entering the Onedrive folder and your system crashes cause it's full. At least till there (maybe) is a solution. Thank you for your work and support.
I can confirm this issue.
I'm not syncing my documents, pictures, etc to Onedrive, but has an Onedrive folder where Onedrive files is synced to. I store about 150Gb in my OneDrive, and I don't need those files on my computer If I need them, I'll download them. and if it is a one-time use, I'll free up the space again afterward.
I would love to see this solved. As I think this is a great file explorer, but because of the OneDrive issue, I can't use it right now :(
When indexing a location, Spacedrive needs to download files to generate thumbnails + collect metadata about them - there's not really a way to do this without downloading the files. Perhaps the files should be deleted after their metadata is collected?
While I couldn't find a way to get thumbnails from on-demand files ~~, you can get metadata from them using GetFileAttributesEx. I threw together a very rough proof of concept in Rust and confirmed that using this function doesn't trigger a download of on-demand files.~~
~~Edit: I submitted an issue at https://github.com/rust-lang/rust/issues/121189 on the issue within std::fs::metadata~~
In my testing, it turns out that calling std::fs::metadata does not trigger a download on OneDrive. So getting metadata is easy enough without triggering a download. Other things that require a read like getting a thumbnail could be skipped if a file is detected to be on-demand.
In my testing, it turns out that calling
std::fs::metadatadoes not trigger a download on OneDrive. So getting metadata is easy enough without triggering a download. Other things that require a read like getting a thumbnail could be skipped if a file is detected to be on-demand.
This is cool to know. We will keep this in mind for the official integration. Optionally generating thumbnails sounds interesting. Spacedrive will most likely need the original file for generating more information about the file though. I am sure the endpoints are limited (information wise)