one solution would be to rename the file on the client… but then you have two different files… or you have to rename it on the server as well
or you apply limits to file names on the server already (must exclude invalid characters on all supported clients). what should happen if the client tries to upload a file valid on this OS but invalid on server/other clients…
I think the problem must have been reported already or maybe addressed from the beginning by software architecture. your report shows the problem exist at least in some cases and could result in data loss. in my eyes it’s worth creating new issue to have discussion and better documentation.
Yeah, not really sure what you are expecting to be done about this. Its a limitation of the substandard OS you have chosen to use, not a limitation of nextcloud.
Expectation is to limit allowed characters in Nextcloud to those allowed in all three OSes Win/Mac/Linux by default.
Maybe have an option to allow all UTF8 characters, including a warning that this will lead to sync problems on Windows machines.
Reason: Nextcloud is a file syncing solution. Windows is the most popular OS at the moment. Nextcloud claims to use sane defaults. So the defaults should not create problems in syncing to Win machines.
…Still hoping that someone can point me to the issue on github…? I’ve seen it before but can’t find it anymore
I would second that. Because even when you not are using Windows for your self or in your organisation, you probably want to share files with people outside your home or organisation. Chances are high that these people use Windows. Default settings that take this into account would definitely be a useful thing.
If you find the issue on github, please let me know. I have quite a few “special” users, who repeatedly use characters that shouldn’t be used - after two emails already, and after several windows machines stopped synching because of this. (Very heterogenous client environment)
if you don’t find any issue on github just open one. maybe it worked good enough till now - so may it’s worth to give the devs a hint to existing edge cases you experience in real life… if they don’t fix them at least we got a reference and documentation on expected behavior.
I still maintain that this is something that must be addressed. Until then, I created a workaround for myself - maybe this helps others as well, so I will post it here - as well as on github:
When file is created, renamed, copied
and User is not member of Temp-Ban-Group
Run script rename 's/[\?\<\>\:\@\*\|\$]/_/g' /path/to/datafolder/%n && php /path/to/nextcloud/occ files:scan %o
This replaces any of the offending characters with an underscore, and then rescans the userfolder. This can take a while depending on the amount of files and folders. It also depends on the hardware. In my case I had to install rename with apt install rename.
This also seems to be working with group folders.
Edit: This does NOT work with folder names - only files! Flow currently can’t be triggered by folders being created/uploaded/renamed.
Welp, the windows client now at least gives error messages about illegal characters. I also gathered some commands and installed “rename”. Will write a script with these commands that triggers every night.
The commands I have gathered (also includes some legal characters):
Observe the -n after the rename command … this makes this a test run! Once you’re happy with the shown result, remove the -n.
Also the rename commands need to be cleaned up still for just the characters searched for?
Some commands must be run several times until all - for example - trailing periods have been deleted. i.e. “foldername with open sentence…” needs the trailing periods command to be run three times. Haven’t worked out the script yet.
This topic is really cumbersome.
With Nextcloud 30 you can deny those files on the server side but not automatically rename them. This creates new conflicts and confuses users, increasing friction and help desk usage.
Thanks for your script. It was really useful!
However, I had to fix some issues with the script, so I created two pull requests on your repository. Maybe you’d consider merging them…