Some time ago, a very weird issue was reported to me about a Nextcloud system. The user uploaded a file with an “ö” on a SMB share that was configured as an external storage in the Nextcloud server. But when accessing the folder containing the file over WebDAV, it did not appear (no matter which WebDAV client was used). After ruling out the usual causes (wrong permissions, etc…), I analyzed the network traffic between the WebDAV client and the server and saw that the file name is indeed not returned after issuing a
PROPFIND. So I set some breakpoints in the Nextcloud source code to analyze if it is also not returned by the SMB server. It was returned by the SMB server, but when the Nextcloud system requested more metadata for the file (with the path in the request), the SMB server returned a “file not found” error, which lead Nextcloud to discard the file. How can it happen that the file is first returned by the SMB server when listing files but then the server suddenly reports an error when requesting more metadata?
Special characters must be second only to time, dates, and timezones when it comes to weird behaviour in code.
File under yet another annoying and avoidable problem. In the hardware and safety critical world standard tests and protocols and certifications exist. It’s time for the software world to catch up.
I imagine a few “legends in their own minds” and corporations getting fat of the hamster wheel of broken code and unnecessary duplication won’t want this level of accountability. Nobody does but I prefer problems to be fixed and stay fixed before they are a problem I get to hear about…