Is it problematic to include spaces in file names?

Our corporate policy is to avoid spaces in filenames. And we do avoid spaces when loading files to our research repository and other systems. But in practice, on our local network servers, a lot of the non-IT people have a habit of creating local filenames with spaces. This does cause the occasional bit of confusion when someone quotes such a filename and fails to enclose it in brackets.

Our research repository also has 2 means of ingest of files; and each of them has different acceptable filename characters. One means accepts spaces and underscores, but not dashes; the other accepts dashes but not spaces or underscores (among other idosyncrasies)! So our recommended filename format for the repository is to use all lowercase characters, with numbers permitted (as long as not the first character), but no special characters.

Based on our experience, I'd strongly suggest spaces in filenames be avoided. It may be difficult to reinforce this at the local level, though.

The file naming conventions that I created for my organization say the following:

"File names should contain no spaces or special characters such as * . ” / \ [ ] : ; | = , < ? > & $ # ! ‘ { } ( ).

Some programming languages use spaces to signify the end of a character string, and many software applications don’t recognize file names that contain spaces. On the web, spaces are typically replaced with “%20” in URLs, and some browsers will 'throw away' anything after a space. Use the underscore symbol (_) or dash (-) in between words to represent a space, or use CamelCase and omit spaces from your file names altogether.

File names should only contain letters, numbers, underscores, or dashes. Special characters are often reserved for functions in scripting and programming languages, and using these characters in file names can cause problems."

I haven't run into specific problems with spaces personally, but this is a case of good digital object hygiene. For the most part, we've built systems to handle these kinds of problems and exceptions, but sometimes you bump into a hard limit or a piece of bad code. For example,

1. I've had an ingest fail because of a folder with 50,000 subdirectories. The drive I was transferring from allowed unlimited subdirectories. The drive I was transferring to allowed only ~32,000 subdirectories because it was formatted with ext3.
2. The Tennessee State Archives documented an error because files with extremely long names could not be ingested when they tested Safety Deposit Box in 2011 (page 2, http://www.mnhs.org/preserve/records/legislativerecords/docs_pdfs/TNTessella_Report_vFinal.pdf). I can't find documentation of the specific length, but I think some were over 200 characters long.
   "The filename issue is especially significant for us in that changing our filenaming structure would be a roadblock to the use of such a system. That structure is well-established and is used for a very large number of existing files, making a change on our end untenable."

In our diverse environment of computing systems, we have a lot of little quirks of what is and is not allowed between systems. Here's a good list of reserved characters that might be restricted in different systems. https://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words

A file may perform perfectly in one environment, but as it passes from use to preservation or one colleague to another, you can bump into quirky problems that require major workarounds.