[Bug]: new files and folders being synced back from server after renaming them on the macOS client

[ffechner]

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

I (and other colleagues at work) experiencing strange behaviour of nextcloud desktop client for macOS when

• creating new folders
• duplicating folders or files
• and renaming the new folder/file immediately after creation/duplication.
  The new file/folder is synced immediately to the server while the user renames the file or folder.
  The renamed folder/file most of the time stays but the originally created/duplicated folder/file is being synced back from the server either in the meantime or up to 5 seconds after the file/folder was renamed and also synced to the server.
  On rare occasions (I only observed this twice) the renamed file/folder vanishes and get replaced by the originally duplicated one.

This behavior was first observed about 10 months or so back in early 2023 on my MacBook Pro M1 Max under macOS 12.6.4 and Nextcloud Desktop client 3.6.6 or 3.7.3 i think. It persists til this day with macOS 14.3.1 and DT-client 3.12.0.
Other colleagues have same issues on older and newer MacBooks (intel and apple silicon) too.

I searched the issues database and found similar behaviors for the windows client open since 2022 and the macOS client but with VFS enabled which we have not!

• [Bug]: Files are duplicated or being renamed automatically when syncing #5278
• [Bug]: Newly created folders dissapear/merge on creation #5420
• [Bug]: Can't rename files on MacOS Ventura (13.4.1) with VFS #5899

There are two feature requests being made wich could potentially circumvent this behavior:

• Only sync modified or new files after a customizable delay of no changes. #6203
• Feature Request: Delay sync by seconds (Synchronization Delay) #6366

I think the better way would be to track the local inode number + name for the folder/file being synced and check if it was renamed in the meanwhile before syncing back the file/folder from the server with the previous name and instead push the new name to the server (and subsequent clients)

Steps to reproduce

1. Go in an shared folder
2. Create a new folder in finder (command+N)
3. Rename this folder (return, enter new name than return)
4. A couple of seconds later the Newly created folder reappears besides the renamed one
   The same happens if you duplicate and rename the duplicated folder or existing file.

Expected behavior

The desktop client should recognise the renaming of the file/folder and not sync it back from the server because the old filename does not exist any more due to the renaming.

Which files are affected by this bug

any new or duplicated file/folder being renamed while syncing

Operating system

Mac OS

Which version of the operating system you are running.

several from 12.6.x to 14.3.x

Package

Appimage

Nextcloud Server version

25.0.3 (was same on 24.x)

Nextcloud Desktop Client version

3.6.6 - 3.12

Is this bug present after an update or on a fresh install?

Updated to a major version (ex. 3.3.6 to 3.4.0)

Are you using the Nextcloud Server Encryption module?

Encryption is Enabled

Are you using an external user-backend?

• Default internal user-backend
• LDAP/ Active Directory
• SSO - SAML
• Other

Nextcloud Server logs

No response

Additional info

No response

[TheRealTripleB]

I have observed the same problems in a similar environment

[kdoteu]

I can also observe this issue for some weeks now on many different windows machines. I tried a lot because not all clients and instances are affected.
Tried to restart all server stuff, client sutff, checked routing and firewall and delay. Everything seems to be working fine, but the bug occurs on some (getting more) windows-clients. And if it appeard once, it will appear everytime.

I thought sometime it is related to groupfolders. After reading your input I think there is something bigger?

[HHUBSS]

I can confirm this in Win11. If there is a delay sync parameter, it will be helpful at this time.

[TheRealTripleB]

I did some testing today and found that I can reproduce the problem very well with the current Nextcloud client 3.12.0git (build 20569), while the problem does not occur with the Nextcloud client 3.11.0git (build 19195). Can you also reproduce this or is it just me? The bug has definitely been around for a while but for me the bug was apparently fixed in version 3.11 of the client and broken again with the new version.
I have tested it under MacOS Sonoma and also noticed that with 3.12 the way the Nextcloud client is started at boot changes. Previously Nextcloud was added as a startup object in the system settings, now this no longer happens and a LaunchAgent is created.

[ffechner]

I've had this problem happen for the last several months now. Ive updated to the most recent version 3.12.0 (build 20569) only last week (feb. 26th I think) but had this happen before.
I've checked with the desktop client config backup that the Nextcloud client creates and these were the versions (all stable versions and the approx. time frame) all the way from 3.6 that I ran - which I think all had this problem in ever increasing frequency of occurrence:
09/2022 - 12/2022 3.6.0 , 3.6.1, 3.6.2
01/2023 - 03/2023 3.6.4 , 3.6.5, 3.6.6 , 3.7.1 , 3.7.3
04/2023 - 06/2023 3.7.4 , 3.8.0, 3.8.1, 3.8.2
08/2023 - 09/2023 3.9.1 , 3.9.2, 3.9.3
10/2023 - 12/2023 3.9.4, 3.10.0 , 3.10.1 , 3.10.2
01/2024 - 03/2024 3.11.0 , 3.11.1 , 3.12.0, 3.12.0

[ffechner]

OK, I had a little time this morning and installed the older version 3.11.0git (build 19195) to verify #6500 (comment) and was surprised that the odd behavior I outlined above does indeed not happen in this version. One thing I noticed though was a small delay after duplicating an existing folder right before I could rename it. I'm not sure if this version did behave back when like it does right now – interesting! I think Its worth investigating the differences between the versions.

[kdoteu]

Problem is still reproducable with the actual 3.12.1. And I can confirm the issue isn't reproducable with the 3.11.3 release.

[stullekovski]

Same here with my current set up. Hope for a soonish fix. :)

Nextcloud version: 27.1.5.1
Nextcloud Client: 3.12.1 (no difference if “virtual” or “download” client mode)
Operating system and version: Win 11 Pro
Groupfolder

[robinkloeckner]

Same problem on multiple Windows 10 Pro machines.

Nextcloud: 28.0.3
Nextcloud Windows Client: 3.12.2
Groupfolder

[thejohnha]

Same issue with Mac and Windows clients in similar environment as OP and follow up posters.

[ccauet]

We (~10 people using the same nextcloud instance) see the same. All working with the macOS client in the newest version (3.12.2)

[Seankim13]

This issue will be resolved by updating to version 3.12.3

[kdoteu]

This issue will be resolved by updating to version 3.12.3

will or is?

can't find any hint in the release notes.

[bbceg]

3.12.3 didn't fix it for me on Windows 11 (and neither did 3.13.0).

I have only managed to reproduce it in an "External storage" location.

1. Create a file (e.g. test.txt)
2. Copy that file (creates test - Copy.txt)
3. Rename the second file (e.g. test-2.txt)
4. "test - Copy.txt" reappears after a few seconds.

What seems a little odd is that it occurs even if you wait a second or two for the copied file to sync (green tick and all) before renaming the file.

I used to have the same problem with new folders reappearing after renaming them but I'm struggling to replicate that at the minute.

[Cosirax]

I've got a similar behavior. When creating a new folder manually or programms saving temporary files (and deleting them) they are going to be synced backwards. So this means:

When creating a folder and while creating renaming it after updating the current folders there are two new folders the one renamed and the folder "new folder".

[marcotrevisan]

Just for the records: on macOS there's a brand new vfs implementation based on Apple's FileProvider framework.
Please check #6656, which includes the download link.

The new implementation may still suffer from some "youth bugs" but since it relies on the FileProvider API, it has an entirely different approach.
Hope this helps.

[josiaslg]

Windows 11 (updated until today).
Nextcloud 3.13
The same problem described here.
I revert to 3.11.x

[thejohnha]

It seems this bug has re-appeared for me. Hub 7 v28.0.6 (snap version) and macOS client v3.13.0
Anyone else also experiencing this after a server upgrade?

[kdoteu]

For testing purpose I turned off VFS for my clients clients :)

Should we open a extra issue for the windows versions?

[camilasan]

Could you try 3.13.2 just released? It has a fix for it.

[bbceg]

Worked for me, thanks @camilasan👍

[Occhioverde]

Today I went to a client that uses Nextcloud on their macOS devices and observed this exact same issue on the latest version of the client with Virtual Files available on the website (3.13.2).

In order to gather some useful data to share, I restarted their MacBook, created a new folder named test and after a minute or so renamed it to prova. The folder then disappeared from Finder and the Nextcloud web interface showed it with the old name and a "Pending" message in place of its size.

Here is the debug archive exported from the Virtual Files tab in the client:

Not providing enumerator for container with identifier NSFileProviderTrashContainerItemIdentifier yet as account not set up
Not providing enumerator for container with identifier NSFileProviderTrashContainerItemIdentifier yet as account not set up
Sending extension account ID [email protected]
Received configure account information over client communication service
Nextcloud account set up in File Provider extension for user: dbonomi at server: https://cloud.avvocatodanielebonomi.it
Received configure account information over client communication service
Nextcloud account set up in File Provider extension for user: dbonomi at server: https://cloud.avvocatodanielebonomi.it
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Could not get notifyPush websocket dbonomi https://cloud.avvocatodanielebonomi.it, polling.
Could not get notifyPush websocket dbonomi https://cloud.avvocatodanielebonomi.it, polling.
Successfully started Realm db for NextcloudFileProviderKit
Finished reading serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi for user: dbonomi https://cloud.avvocatodanielebonomi.it
Finished recursive change enumeration of working set for user: dbonomi https://cloud.avvocatodanielebonomi.it. Enumerating items.
Processed 0 new or updated metadatas, 0 deleted metadatas.
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Finished reading serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi for user: dbonomi https://cloud.avvocatodanielebonomi.it
Finished recursive change enumeration of working set for user: dbonomi https://cloud.avvocatodanielebonomi.it. Enumerating items.
Processed 0 new or updated metadatas, 0 deleted metadatas.
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Sending extension account ID [email protected]
Received configure account information over client communication service
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Cleaning up local file metadatas for unmaterialised items
Cleaning up local file metadatas for unmaterialised items
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Set up enumerator for user: dbonomi https://cloud.avvocatodanielebonomi.it with serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi
Could not get item parent directory metadata for metadata.
ocID: 01090883oc7ol3ejaau2,
etag: 66acb9a6dd312,
fileName: test,
serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi/test,
account: dbonomi https://cloud.avvocatodanielebonomi.it,
Not modifying item: 01090883oc7ol3ejaau2 as item not found.
Could not get item parent directory metadata for metadata.
ocID: 01090883oc7ol3ejaau2,
etag: 66acb9a6dd312,
fileName: test,
serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi/test,
account: dbonomi https://cloud.avvocatodanielebonomi.it,
Could not get item parent directory metadata for metadata.
ocID: 01090883oc7ol3ejaau2,
etag: 66acb9a6dd312,
fileName: test,
serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi/test,
account: dbonomi https://cloud.avvocatodanielebonomi.it,
Not modifying item: 01090883oc7ol3ejaau2 as item not found.
Could not get item parent directory metadata for metadata.
ocID: 01090883oc7ol3ejaau2,
etag: 66acb9a6dd312,
fileName: test,
serverUrl: https://cloud.avvocatodanielebonomi.it/remote.php/dav/files/dbonomi/test,
account: dbonomi https://cloud.avvocatodanielebonomi.it,
Cleaning up local file metadatas for unmaterialised items

This specific test and log is relative to a MacBook Air M3 2024 with macOS Sonoma 14.6, but it's reproducible on an iMac Retina 2020 with macOS Sonoma 14.5.

[bbx-github]

I have the same issue

• OS Linux
• Desktop Client Version 3.12.7 (Appimage)
• Desktop Client Log: [..]Local file changed during sync.