You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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
The text was updated successfully, but these errors were encountered:
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
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.
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.
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
The text was updated successfully, but these errors were encountered: