[Bug]: Regression in 4.0.8 – Sync error "Error transferring ... server replied: Not Found" on MS Access lock files (.ldb)

[tuefue]

⚠️ 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

The client fails to handle Microsoft Access lock files (.ldb) correctly, resulting in persistent "Error transferring ... server replied: Not Found" sync errors. This was working as expected in version 4.0.7, but the issue appeared immediately after updating to 4.0.8.

Steps to reproduce

1. Update (or install) Nextcloud Desktop Client 4.0.8 on Windows 10.
2. Open any .mdb file within the sync folder using MS Access.
3. MS Access creates a temporary .ldb file.
4. .ldb file gets stuck in syncing state (blue arrows icon)

Expected behavior

The client should sync .ldb files as ordinary files.

Which files are affected by this bug

.ldb

Operating system

Windows

Which version of the operating system you are running.

Windows 10

Package

Official Windows MSI

Nextcloud Server version

32.0.6.1

Nextcloud Desktop Client version

4.0.8

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

[mgallien]

@tuefue I would need some logs to understand what could be the issue
I do not have access to Ms Access
can you send them ?

[mgallien]

for reference
https://learn.microsoft.com/en-us/troubleshoot/microsoft-365-apps/access/lock-files-introduction
apparently .ldb files are supposed to be used to allow concurrent access to a database and would be written by every user having access
so for direct shared access to a database, they need to be accessible y the other users but I am unsure what kind of file system level locking is used to prevent concurrent access to the lock files
unsure what it could mean in the context of synchronizing (ignore them or sync them)

[tuefue]

Logs are attached (logs.zip). I’ve removed some sensitive data. The files of interest are test.mdb and test.ldb. Is this enough?

We store .mdb (.accdb) files in shared folders for collaboration, for this reason .ldb (.laccdb) synchronization is important to us. I do not know what the hidden pitfalls were in version 4.0.7, but it used to be OK for us.

[tuefue]

@mgallien The bug is still reproducible in version 33.0.2. I’d like to clarify one point: we use .ldb files to indicate that the database is locked by a user, as we edit the database one person at a time. Please treat .ldb files the same way as .mdb files.