-
Notifications
You must be signed in to change notification settings - Fork 890
Open
Description
⚠️ Before submitting, please verify the following: ⚠️
- This is a bug, not a question or a configuration issue.
- This issue is not already reported on Github (I've searched it).
- Nextcloud Server and Desktop Client are up to date. See Server Maintenance and Release Schedule and Desktop Releases for supported versions.
- I agree to follow Nextcloud's Code of Conduct
Bug description
Bug environment/pre-conditions
In my local sync folder, there is 1 .pst file which is opened (exclusively) by MS Outlook (classic).
When the desktop clients starts syncing, the PST file leads to an unexpected error (a message appears to restart sync, but the next sync still runs into the very same problem)
Bug description
The bug itself is
- LOW PRIO: the lack of detection of the file as being locked which might lead to the following error
- expected: no error, but information about a temporarily locked file in ignore list
- HIGH PRIO: when other files are in queue to be synced (from local client to server as well as from server to local client), these files are NOT synced UNTIL I close the MS Outlook application which closes the exlusive lock on the .pst file.
Situation in OwnCloud Desktop client
OwnCloud correctly handles this issue with
- detecting the file lock
- showing the file in the ignore list with correct reason
- continues syncing for other files
Steps to reproduce
- Place a file (e.g. PST mailbox store) in a synced directory
- Open the file (exclusively?!) with an application (e.g. MS Outlook classic for .pst files)
- Change other files locally and/or server
Expected behavior
Nextcloud desktop client should
- correctly detect the file lock
- show the file in sync log as temporary locked and with correct reason
- continue syncing for other files
Which files are affected by this bug
*.pst
Operating system
Windows
Which version of the operating system you are running.
Windows 11
Package
Official Windows MSI
Nextcloud Server version
32.0.1
Nextcloud Desktop Client version
4.0.1
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 3.16.1 to 3.16.2)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
Are you using an external user-backend?
- Default internal user-backend
- LDAP/ Active Directory
- SSO - SAML
- Other
Nextcloud Server logs
Additional info
No response