Skip to content
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

Feature Request: Increase Custom Timeout Limit for Large File Uploads to specail conditional Cloud Storage #16587

Open
fuguiKz opened this issue Nov 26, 2024 · 2 comments

Comments

@fuguiKz
Copy link

fuguiKz commented Nov 26, 2024

Is your feature request related to a problem? Please describe.
Yes, the problem is related to large file uploads to cloud storage services (specifically China Mobile and Cailian Cloud) using Mountain Duck. When uploading files larger than 2GB, the upload often fails with a "423 Locked Error". The issue appears to be related to the cloud storage's response time after the file upload completes. While the upload itself may take 3-4 minutes, the system often waits for another 3-4 minutes to receive the "upload completed" confirmation from the cloud storage service, causing long delays. This is especially problematic when uploading large files, and current timeout settings (limited to 60 seconds) in Mountain Duck are insufficient to handle these long delays, making the process unreliable.

Describe the solution you'd like
I would like Mountain Duck to allow more flexible custom connection timeout settings, with the ability to set timeouts longer than the current 60-second limit. Ideally, users should be able to set a timeout of at least 5 minutes to accommodate situations where the cloud storage service takes longer to respond after uploading large files. This would improve the reliability of file uploads, especially for services that take time to process large files or perform security checks.

Describe alternatives you've considered
As an alternative, I have considered using other WebDAV clients, which allow for longer timeouts and thus make it possible to upload large files. However, those clients do not provide the same level of integration and ease of use with the cloud storage services I'm using (China Mobile and Cailian Cloud). Alist is the only viable option for mounting the cloud storage, but it primarily focuses on downloads rather than uploads. I would prefer to continue using Mountain Duck, as it offers a more user-friendly interface and greater functionality.

Additional context
It seems that the issue arises due to the cloud storage service's response time after the file is uploaded, potentially due to security or compliance checks on large files. Increasing the timeout setting in Mountain Duck would provide better compatibility with these cloud storage services and improve the user experience for those uploading large files.

Additionally, I understand that allowing for longer timeouts could lead to potential misconfigurations by some users. To mitigate this, I suggest implementing a prompt or warning to guide users toward reasonable timeout settings when adjusting this parameter.
image
If the proposal is not adopted, I hope you can guide me on how to modify the 60s limit of the timeout connection in the existing version.thanks
image

@fuguiKz
Copy link
Author

fuguiKz commented Nov 26, 2024

image I used a stopwatch on my phone to time it, and it did give an error after a one-minute timeout. I hope to increase compatibility for this special case. I really like using mountain duck and can't find any other stable alternatives

@fuguiKz
Copy link
Author

fuguiKz commented Nov 27, 2024

I tried to modify the local configuration file, but it seems that the mountain dock software has a logical limit on the number of seconds. Even if it is changed to 300s, only 60s is displayed and used. So can anyone help me solve this problem? If possible, I hope this proposal can be supported in the preview version.
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant