Why does Nextcloud restrict characters in directory names?

Nextcloud version (eg, 18.0.2): 18.0.4
Operating system and version (eg, Ubuntu 20.04): Debian 10
Apache or nginx version (eg, Apache 2.4.25): Apache/2.4.38 (Debian)
PHP version (eg, 7.1): PHP 7.3.14-1~deb10u1

Using nextcloudcmd, I cannot upload a directory with the name:

'Symphony No 3 in C minor "Organ", Op 78'

Nextcloud gives an error about an invalid character, although it does not identify which character. Presumably it is the double quote, as removing this avoids the problem. Linux does not have any objection to this as a directory name (with the double quote), nor does Apache. Why is it a problem for Nextcloud?

Steps to replicate it:

  1. Create a directory with the name above on a Nextcloud client
  2. Attempt to sync with the server
  3. Observe that an error message is shown saying there is an invalid character in the name

I think there are multiple reasons why these characters shouldn’t be used in file and directory names:

  1. Nextcloud is not restricted to run on Linux OSes only. Windows e.g. doesn’t allow to use quotes in file and directory names.
  2. Single and double quotes are usually used to mark the beginning and end of a string. Combinations of both can cause strange results when processing strings.

See also https://stackoverflow.com/questions/4814040/allowed-characters-in-filename

2 Likes

That is true but defeatist. The directory was created automatically by the Hyperion Records download manager, originally on a Windows machine. On the Windows machine, the directory is called:

Symphony No 3 in C minor (qu]Organ(qu], Op 78

This seems to be a generally understood convention. The directory is sync’d by pCloud, which shows it through a browser with actual double quotes. And when the directory is sync’d to a Linux machine from pCloud, it appears with actual double quotes.

Why can’t Nextcloud behave like pCloud?

Why can’t man walk on the water? At some point you have to find a level of negotiation which fits for most of the use cases and focus on it. You never will get a 100% match for all available options/functions on all OSes.

Have you ever asked MS why they are not supporting the same characters as Linux - most likely not. In the meantime you have to live with this small issues and rename the directories :wink:

Why so negative? Microsoft is a law unto itself. I don’t use Microsoft products if I can possibly help it. Presumably Apple, being based on Linux, is also perfectly capable of handling a full range of characters for directories.

Why should we be confined to the lowest common denominator? I’ve always taken the view that software should always be as generalised as possible, within practical limits, and not arbitrarily confined. In general, it seems reasonable to follow a principle of supporting the standards that exist in each client environment, unless it is impossible to do so.

It’s a general frustration that digital music, which ought to be capable of being hugely user friendly, is actually beset with any number of stupid limitations that make it far less usable than it might be. Messing with directory names that were set by a music provider is just one of them.

And pCloud is not a big outfit, which is competing in a similar space to Nextcloud. Asking to implement what appears to be a de facto standard is hardly asking anyone to walk on water.

I believe one of the reason to limit the number of characters/symbols in file names is related to the search engine indexing (not unlike the ASCII tables in the old DOS times)…

Maybe request to have a say under what name the downloaded file is saved?

Uugh, how did you come to this conclusion?

There are many filesystems out there (ext3/4, btrfs, ZFS, APFS, NTFS/FAT, and many others of different storage systems) and Nextcloud needs to cover all of them, otherwise client and server would not work together and doing of any magic like character changing is the root of complexity).

But doesn’t the original post prove that Nextcloud can’t create a folder with a quote (") in its name?

If that is true, what is left of your interoperability argument?

And what exactly all those file systems’ abilities have to do with the limitations of applications like Nextcloud?

If you can create a file with a very long name e.g. 300 characters on your local device and the storage can only have filenames with max. 255 characters. How to handle it?

Same for characters like ". The server, the scripts, the sql statements, the storage, all of them must be able to handle this character.

OK… And?

Why can’t Nextcloud create a folder with " in its name?
Or did the original poster do something wrong…?

I tried to explain what can cause trouble and therefor there are limitations.

No, but he is trying something which is not possible at the moment and the system is telling this to him.

Feel free to write a good feature request at GitHub to achieve that function.

EDIT:
Just tried something on MacOS. See
Bildschirmfoto 2020-05-23 um 23.44.58

It has been uploaded to the server:

On windows this is not possible. So the client responds with an error:

@counterpoint Hope this explains it for you.

I didn’t get any of the explanations but I can live with that…

You argue with the use case, I answered you with arguments technical side. Maybe that doesn’t work this time.

But I have interesting news.
Just created a folder with " on my client and it has been synced to the server.
Will check on monday what the clients on Lin and Win are doing.

Maybe the user is right and we found a bug/missing feature in “nextcloudcmd”.

Every application has (might have?) limitations in terms of what characters can be used…

Google uses " as a special character meaning whatever is in between two of them has to be in the search result. In essence, you can’t search for "…

Outlook for the web (OWA) can have an exclamation mark (!) in the password but NOT a question mark (?) - at least in the implementation at my work…

Applications have limitations (how about that for an eureka)…

Double quotes are definitely not allowed in directory and file names on Win10:

grafik
grafik

1 Like

I don’t think pCloud can sync on and off this folder from a windows computer :
‘Symphony No 3 in C minor “Organ”, Op 78’

@counterpoint

After my almost 40 IT years and having grown up with MSDOS, I still try to avoid any characters beyond a-z, A-Z, 0-9, dot, dash and underscore in file- and folder names -

Sure, nowadays this is totally antiquated and sometimes annoying, but on the other hand it saves a lot subsequent issues :innocent:

Recently, I ran into an issue where Nextcloud 18 refused to stream a video I‘ve received by public link. Omg - how much time took it before I recognized that the simple reason was a single quote character in the video‘s file name… (and obviously a bug in nextcloud, as the video plays without objection when clicked directly instead by the link)

But it again confirmed my vintage habit… :innocent:

2 Likes

I try avoiding underscore as well.
Old Windows server (either 2000 or 2003) didn’t like names with underscores in it…

I believe Nextcloud applies the “lowest denominator” - what is not supported on even one platform (Win/Mac/Lin), is not supported at all… Or at least using it is asking for trouble… Safe approach…

It was worst when using ownCloud on a IIS Server !
You can’t use accents !
Because PHP is using UTF-8 and windows storage use a Windows-iso charset that is different than utf-8 charset.
BOOM the server goes.
From this day i learned Linux Server.

1 Like

At the top of this post I notice the problem folder name contains a comma. In this case the folder name was created by software. It is really poor that software designed for Windows assumes the data will only ever live on a Microsoft filesystem. Nextcloud does not like commas - two of my file syncs failed with an ‘Invalid argument’ error for files created in software. It took a while for me to figure this out as my eyes are not so good these days. I do not use punctuation in filenames except for _ (underscore) and - (dash). It is also a long standing habit for me as an IT engineer looking after a variety of operating systems to keep names as short as possible and never to put spaces, punctuation or uppercase characters in file names. Windows is ok with this but other systems designed to carry out powerful file operations will see the space as an indication of a following file name, and quote marks single and double invite some systems to try and interpret the contents as code variables.

We used to have massive problems with people creating deep multi-nested folders to logically distribute and differentiate their data and not realising the path is part of the filename as far as the operating system is concerned. Windows would let you create these deep-nested structures and later on complain the folders and files did not exist if you tried to do anything with them as they exceeded the 255 character limit on file names.

I fully understand that people want to use intelligible language to name things and do not want to forever rename files created by software they use. If you want to negotiate complex file manipulations across systems though you need a different mindset.

So the best advice is to keep folder names and filenames short and avoid all punctuation. It is an IT Operator habit to always avoid the use of upper case characters as well in file and folder names. A rule of thumb that will never let you down. Some operating systems do not distinguish between upper and lower case characters in names while others do.

So I understand the irritation of posters above. You want a straightforward and flexible system that means you can free your mind for creativity and not be bogged sown on the arcane mechanics of computer filesystems and naming rules. But the computers themselves are literal and rule bound. It is all a lot more simple these days - I see the folder name with all the information in it is inside single quotes which makes it acceptable to Linux as a folder name. I would never risk such a format though and if I wanted to have a descriptive name like that I would use dashes and no spaces or punctuation. It might not look like standard language but it will still be intelligible to humans and machines. Of course once AI gets a firm grip we will never have to think about this kind of problem again - the thing is we may never have to even think again …