Problems with renaming of items, especially for new folders

[claell]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Expected behaviour

Renaming of items in Windows Explorer should work flawlessly

Actual behaviour

Error messages are sometimes displayed and when creating a new folder and naming it, the "new folder" folder is sometimes placed again next to the created folder.

Steps to reproduce

1. Use VFS (not sure whether it also is a problem without it) on Windows (not sure whether this also happens on other OS)
2. Create an item and immediately rename it
3. For new folder: Create a new folder and name it
4. See how the newly named folder is created. However, probably because already when creating the new folder and naming it, Nextcloud syncs the new folder (with the placeholder name "new folder"). After successfully creating the folder, the placeholder folder appears again.

Client configuration

Client version: 3.2.3

Operating system: Windows 10

OS language: German

Qt version used by client package (Linux only, see also Settings dialog):

Client package (From Nextcloud or distro) (Linux only):

Installation path of client:

Server configuration

Nextcloud version:

Storage backend (external storage):

Logs

Please use Gist (https://gist.github.com/) or a similar code paster for longer logs.

1. Client logfile: Since 3.1: Under the "General" settings, you can click on "Create Debug Archive ..." to pick the location of where the desktop client will export the logs and the database to a zip file. On previous releases: Via the command line: nextcloud --logdebug --logwindow or nextcloud --logdebug --logfile log.txt (See also https://docs.nextcloud.com/desktop/3.0/troubleshooting.html#log-files)

2. Web server error log:

3. Server logfile: nextcloud log (data/nextcloud.log):

[camilasan]

Duplicate of #3515. If you would like to get help, upload your logs too: https://cloud.nextcloud.com/s/8dMHFXDpWTSDGdw

[claell]

This does not seem to be a duplicate. I get the error from Nextcloud, not Windows Explorer. Furthermore, the folders can get created, but the Sync engine seems to mess things up sometimes.

[vasyugan]

This does not seem to be a duplicate. I get the error from Nextcloud, not Windows Explorer. Furthermore, the folders can get created, but the Sync engine seems to mess things up sometimes.

Technically, I can also create new folders, just that Windows initially names them "Neuer Order" ("New folder"), and then you enter the actual name that it should get, that's technically a rename/move because before that step the folder has already been saved as "Neuer Ordner". So, really, the problem I see is about renaming folders.

At the same time, a colleague of mine who also has enabled virtual files is unable open most file that are shown in Windows explorer. Instead, she gets a similar error message. So for now, the virtual files functionality still seems quite rough around the edges.

[claell]

@vasyugan For me the renaming works, Windows Explorer does not complain. However, I sometimes get a message from the Nextcloud Client complaining about an error (likely because the folder or file has been renamed while it synced it, so it thinks that it has disappeared and complains). Since I never get error messages from Windows explorer, I am a bit doubtful, whether we have the same issue (maybe a similar root cause, though). Additionally, as written above, in these cases the "Neuer Ordner" often reappears, likely because it gets synced back from the cloud. So then I have my renamed folder and the old "Neuer Ordner" folder.

For the problem of your colleague, see #3495, might be related.

[github-actions[bot]]

This bug report did not receive an update in the last 4 weeks. Please take a look again and update the issue with new details, otherwise the issue will be automatically closed in 2 weeks. Thank you!

[claell]

Nothing seems to have changed

[vasyugan]

Nothing seems to have changed

Same here.

[WhiteChairFromIkea]

Providing 100% reproducible script for developers to reproduce this issue. Just run the script and edit sleep values, or/and filecount.

DEL *.txt

echo hello > original_name1.txt
echo hello > original_name2.txt
echo hello > original_name3.txt
echo hello > original_name4.txt
echo hello > original_name5.txt
echo hello > original_name6.txt
echo hello > original_name7.txt
echo hello > original_name8.txt

sleep 2
ren original_name1.txt new_name1.txt
ren original_name2.txt new_name2.txt
ren original_name3.txt new_name3.txt
ren original_name4.txt new_name4.txt
ren original_name5.txt new_name5.txt
ren original_name6.txt new_name6.txt
ren original_name7.txt new_name7.txt
ren original_name8.txt new_name8.txt

echo hello2 > original_name1.txt
echo hello2 > original_name2.txt
echo hello2 > original_name3.txt
echo hello2 > original_name4.txt
echo hello2 > original_name5.txt
echo hello2 > original_name6.txt
echo hello2 > original_name7.txt
echo hello2 > original_name8.txt
sleep 2
ren original_name1.txt dup_name1.txt
ren original_name2.txt dup_name2.txt
ren original_name3.txt dup_name3.txt
ren original_name4.txt dup_name4.txt
ren original_name5.txt dup_name5.txt
ren original_name6.txt dup_name6.txt
ren original_name7.txt dup_name7.txt
ren original_name8.txt dup_name8.txt

DEL *.txt

Any rapid file operation (rename, delete) is messed up by nextcloud client itself, when dealing with many files at once. Just run this script, which renames/deletes 8 files. Adjust sleep times. On my PC, this script messes up nextcloud client with 100% repeatability after setting both sleep values to two seconds, as can be seen from 1:26. No *.txt files should be seen in the directory after this script.

See from 1:26:

https://user-images.githubusercontent.com/46539653/162410851-499a9e21-aa51-408b-97d7-da301785f6eb.mp4

What is interesting, it was sufficient to have sleep times set to 1 in another folder, deeper in folder structure.

WORKAROUND: I do "pause" syncing of nextcloud before any massive renaming operation, to keep my files safe.

Nextcloud version:

I am stuck at this version, because https://github.com/nextcloud/server/issues/3056#issuecomment-1092619556 and https://github.com/nextcloud/server/issues/30263 are not solved still (cannot risk to lose files in any way).

[WhiteChairFromIkea]

Please note, that another bug https://github.com/nextcloud/desktop/issues/3456#issuecomment-1092703994 can be seen at screencast above, at 00:50 and 1:31.

[WhiteChairFromIkea]

Another steps to reproduce (do everything quickly):

1. Download ~60MB zip file, containing bunch of photos (lets say 20 files @ 3MB) to vfs;
2. Extract zip to the same VFS;
3. Photos get started to sync;
4. Once extracted, quickly delete zip file (it disappears form the folder);
5. Wait till everything gets synced, check folder;
6. See how zip file reappears in the folder.

But see my https://github.com/nextcloud/desktop/issues/3513#issuecomment-1092681491 to get 100% working steps to reproduce instructions..

[metafarion]

I'm seeing this as well: Any file created or copied into the synced directory via the Nextcloud client and then renamed does change its name... but then a moment later, the original file reappears as well. I’ve also confirmed that it’s not just a one-sided or visual glitch; there are actually two real files on the server. Renaming either of these two files a second time succeeds normally. It’s only an issue when the file is “fresh”

This only occurs in SMB external storage mounts, not in native Nextcloud space, and only via the Desktop client, not the web interface, AND it also only happens if the originating user renames the file within a few minutes. If a new file is created and left for 5...ish minutes, it can be renamed without issue.

There is a parallel, but distinct phenomenon happening to new folders. A New Folder created on or copied to this same space will not create a duplicate, but will seemingly reject renaming, reverting to its original name. A second attempt succeeds, the same as for files.

I’ve observed this problem on Windows clients running Win 10 and 11 and on a Mac. The server is running Nextcloud 27.1.7, clients are all 3.12.1. The glitch is reliably reproducible with or without VFS enabled.

[Ceelight]

We also face this problem mentioned above: "Any file created or copied into the synced directory via the Nextcloud client and then renamed does change its name... but then a moment later, the original file reappears as well."

But this happens in native Nextcloud space via Windows Desktop Client.´

[metafarion]

This has stopped happening on my instance, and I don't know why. Server version is still 27.1.7, though client version is now 3.12.3

[roberix]

This has stopped happening on my instance, and I don't know why. Server version is still 27.1.7, though client version is now 3.12.3

Hi.

Yes they provided a fix in 3.12.3 for this issue.

Regards

rob

[metafarion]

Yes they provided a fix in 3.12.3 for this issue.

Oh that's cool then. Should we like.... close this or something?

[ServiceType]

We still have this issue. Server: NC Hub 8 (29.0.2) Client: 3.13.0

When creating a file or folder, the syncclient uploads as "New Folder". After renaming it stucks at synchronisation pending and sometimes i get following error:

The renamed files stay in the webinterface with the "original" name (name bevor renaming). In windows explorer the name changes. But this change never get uploaded. Multiple reboots an force sync doesn't help.

Virtual Files can't be disabled, because we use it for datashares with nearly 1 TB of data. "Always keep on device" doesn't help in our case.

Workaround for us: Move the file or folder outside of the syncfolger (eg. Downloads), wait until the windows client has deleted it and move it back. Then the Client creates a "new" file or folder an everything works well.

We also tested that on multiple notebooks.

[Ceelight]

Same here.

[PhilippSchlesinger]

@ServiceType @Ceelight the problem you are facing is most probably the same described in https://github.com/nextcloud/desktop/issues/6721

There is a fix and as described in https://github.com/nextcloud/desktop/issues/6721#issuecomment-2190947913, the corresponding changes are already contained in 3.12.6 and will be contained in 3.13.1

[PhilippSchlesinger]

@ServiceType @Ceelight the problem you are facing is most probably the same described in #6721

There is a fix and as described in #6721 (comment), the corresponding changes are already contained in 3.12.6 and will be contained in 3.13.1

3.13.1 got released recently.

[ServiceType]

Seems to work with 3.13.1 Thanks a lot.