This isn’t really a DT problem, but looking for a solution here is more realistic than hoping Microsoft might do something.
On opening an Excel file (via the share button and tapping on, or long-press and selecting open in from the Excel icon) from DTTG3 files with certain characters in the file name cannot be opened.
Acrobat, for example, will happily accept files with > in the file name (I didn’t test any others).
Is there any chance of an automated workaround for this?
Do you anticipate having many of these files?
Oh, about 10,000 I recently changed my naming convention to reflect whether a document was to or from x (using, you guessed it, < and >)
But maybe I’ll just recently revert the changes
Yeah, switching back now is a good idea.
I’ve had this issue with Microsoft apps no matter where they come from. I think it’s either Microsoft’s decision to stick with old-school naming requirements or because they engage OneDrive while the document is being worked on, even if the doc doesn’t reside in OneDrive (there was a bug for a few months that led to slow downs when editing Word docs that seemed impacted by Internet speeds, which has me thinking they use the cloud for some of the document handling). OneDrive rejects names that have have certain special characters upon upload, so that adds to my theory, but I’m not at all sure it adds up.
Thanks, I think that makes sense! I didn’t for a moment think to check whether special characters would cause any problems before renaming all my files. Silly me.
This is yet another reason why we are strict in our suggestion of only using spaces, hyphens, underscores, and periods in filenames.
I was out to lunch when you wrote that post. Those posts. Damn
Although I don’t totally agree with DT’s definition of unwanted characters in files: /,:,<,>,|, ?, * are generally not a good idea on Mac OS (and other Unixes). Some are path separators (:,/), others are shell metacharacters. < any > in particular are used to redirect input and output. Having those in filenames makes it unnecessarily difficult to run shell commands on them.
May be you could use Unicode arrows instead? Though they are a lot harder to type, obviously.
The bare minimum is the safest bet.
Im wondering about → and ← (Unicode 2192 and 2190), for example. They could convey the same meaning as > and <, without the problems for shell processing.
“Bare minimum” in the context of characters in IT has for a long time be the synonym for “known and used in the US”. Now we have Unicode and might overcome these historical limitations
Yes, I agree. I think this is a Microsoft issue.
Another strange one with Excel: if you 2 files of the same name, you can’t open both at the same time even if these two files are located in different directories (and of course they are in different directories since a directory can’t have files with the same name!).
It makes me wonder what old programming code is Excel still using?