-
Notifications
You must be signed in to change notification settings - Fork 800
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
VFS downloads until 0B is free on disk, then fails without any relevant error notice. #3505
Comments
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you! |
unstale |
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you! |
unstale |
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you! |
un |
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you! |
@claell is there free space monitoring? iirc there was? can the limit be bypassed with multiple transfers? on explorer, you can't copy a 2G file, if the destination doesn't have the space (1.5G available), but you can start the copy of 2 1G files at the same time; the same could be happening with VFS adding thousands of files one-by-one otherwise, gonna let it go stale |
This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you! |
This bug report is getting automatically closed due to no answer since the issue has been staled. Thank you! |
How to use GitHub
Expected behaviour
Sync stops with a relevant error
Actual behaviour
User didn't have image previews, so they proceeded to mark 'always keep on this device' for every directory. Them having more files than space available on the disk, the disk filled up. I got a call for 'gmail is not opening', disk had 0B free.
On the server side, I figured out some large directories, that would likely be not needed. Unchecking the 'Always keep on this device' on the 2, and afterwards, again after a reboot 'Free up space' on the folders. The directories were not deflated, no error is reported.
I'm left with:
a) delete the files via client, files are deleted on the server, then restore files on server (not reasonable here)
b) Remove the sync connection, and re-add it. Takes about 6h+ per 100G, most files are ~4-8MiB. Massive downtime.
Client configuration
Client version: 3.2.3
Logs
Refusing to provide logs due to sensitive filenames. #3189
The text was updated successfully, but these errors were encountered: