Why do I get error that filenames longer than 31 characters are unsupported?

I have had the "Names longer than 31 characters are not supported on the destination volume." problem since I upgraded my iMac to Mavericks. It is now on OS X 10.10.1 and the problem still occurs. Usually, at the same time it will have made many of my folders "read only". The only way I have been able to cure it has been to shut it off and then on again, a hard reboot. It is not caused by unauthorized characters in the file name or folder name.

I used to expect problems like this with Windows PCs, but not with iMacs.

I had this problem in OS X Mail, running Mavericks. I got the "more than 31 characters" error and I furthermore could not create a folder inside the folder in question. The problem turned out to be that the name of the folder began with a space! I removed the space, and saving from Mail worked once again. It's a pity, because I use the space at the start of files and folders to sort important items to the top of a directory. Doing this was not a problem until Mavericks. Anyhow, removing the initial space fixed it. Restarting Mail, rebooting the MacBook Pro, repairing with Disk Utility, setting Staff to read/write, etc did nothing.

Hmm. I often create files or folders with a space (or multiples) at the beginning in Mavericks, and have done so in every previous version of OS X, and Yosemite. No errors here.

We've seen multiple instances in this topic where users get this "error" message. All things other users can do without the error. I haven't been able to spot a pattern that fits all situations where this happens.

Interesting. Your reply prompted me to put the space back at the beginning of the folder in question, and this reproduced the error. Removing the space fixes it: no initial space, no error. It is totally reproducible and consistent in my hands.

In reading my post, I see I wrote Mavericks, but I meant Yosemite.

Problem description:

I have experienced the 31 character issue today. 2014-12-10.

Mavericks 10.9.5, 2011 macbook pro

Textedit decided to declare that 31 character and shorter file names were required. Textwrangler didn't have that issue with the same content and I was able to save the text to disk using Textwrangler with the file name I chose. And that being said, when I tried to save the file as 123.txt with textedit it failed as well stating something about file not found.

Thoughts:

This seems to be a bug in the code base if it is happening to many people. An insidious one at that perhaps. Or even worse maybe the beginning of a virus? I am not going to read through all of the posts but it would seem this might have to do with something the base applications. If mail can do this and textedit can do this as well what library do they share that textwrangler does not? That being said, there is some process in my activity monitor that doesn't have a name and is being run by root. (no name to me means malicious content)

Anyhow my machine cannot be said to be working as I think it should. I have been wondering why certain odd things have been happening lately. However from any practical standpoint the system is normal. I am also wondering if the drives have some bad sectors etc that need cleaning... Though I am at a loss on how to determine that out of the equation.

I am going to run time machine tonight and try to reset the system.

-light man

Same problem just occurred.

Yosemite and up to date. Saving file from Pages via Print to pdf and trying to overwrite previous file -- that is the longer file name already existed in the folder and Pages was picking up the name from there! Changing destination to Desktop resulted i saved file which was then manually copied to overwrite existing file with no problems.

even more "weirder" things happening under Yosemite 10.10.2 on my MPB 2013 "occasionally" -

=> from Mail to save an attached file opened in Preview by "export as PDF" :

- cannot save file with name >31 characters - cfr the many previous complaints

- cannot "save file because file does not exist"

- "volume is read-only" (sic !!!)

- instead of saving the file was sent to printer !!!

no cure by reboot/restart nor from "Save as" (with option key)

Hi,

I just found this thread - hopefully it's still active.

I just got this error in Pages 5.5.2 which is a very new Apple application, on a very new MBP Retina Mid-2014 model. No old OS9 filesystem.

The error with files not really being saved happened to me already multiple times in Pages, Keynote, Preview, and other non-Apple programs such as LibreOffice. In fact, the file not being saved error happens to me almost every time I try to save to a folder which is deeper than ~/Documents, and it's universal, i.e. happens with all programs.

The work-around is to save to ~/Documents and then move it. Sometimes a reboot prevents it for a few times until it starts happening again.

Can you help?

Yes, there are 2 work-arounds:

1) What you said, save the file to ~/Documents, them move the file later to the desired sub-folder, using Finder.

2) Mentioned elsewhere by others: when the error occurs, go in the Finder-like dialog that selects the file-save location, on the left-side pane, Click Documents, the continue to "re-traverse" the desired save path starting from your ~/Documents folder, and drill down to the desired directory. Speaking very loosely, it seems that the filesystem "forgets" some attribute and you can "re-teach it" by re-traversing the path from your Documents root, drilling down one directory at a time.

I have tried method (2) several times and it works. I navigated into the same directory that it said "could not save filenames longer than 31..." and doing so "seems" to "clear the bug out." Try it. What is the root cause? Beats me, it doesn't seem to be solved yet.

P.S. I have not seen convincing evidence that rebooting in itself solves the problem. The problem is intermittent on my system and rare.

P.P.S. This problem worries me greatly: if it happens on a "user file save" action, fine. But can it happen with a file save that is not user-initiated (i.e. the invisible things apps do in their everyday work), like cause a failed backup, or corrupt actions in the cloud, or... A failed file write could really propagate some very strange errors; you do not want your filesystem randomly deciding on occasion it will refuse to write a valid file.

I have seen this problem saving files where none of the directories (or filenames) have leading spaces.

While your experience was that changing the "space" changes the result, I am seeing the problem without having leading space in file or directory names, and tried to change other aspects of the filename did not solve the problem.

This works in Yosemite too 10.10.2 I only had to use that workaround one time, and the system then apparently corrected itself, allowing me to 'print to pdf' from Firefox with a very long name. Thanks!

Thanks Oregon Ducky - it worked for me.

I just moved the hidden drives as you suggested and straight away - a cure!

All fixed.

I'm travelling to Oregon (from London UK) later this year. I hope everybody in Oregon is as helpful as you!

Best wishes.

Ant

Thanks, Udo and Kurt. This solved my problem. I'm on El Capitan. The surprising thing was that having one of these special characters in a file name ANYWHERE on the hard drive will prevent me from saving a file with a long name anywhere else on the drive (saving from an Adobe CC app). OSX seems to allow the file names with characters that cause these problems, but then it will cause a problem later on when saving to that drive from specific apps.

I just want to note that this same type of behavior occurred using Yosemite (v10.10.5) to me yesterday when trying to save a pdf from Mail. I also could not transfer data back and forth from my GPS app to my GPS device. I did re-boot and it seems to be fixed. VERY STRANGE!

Just quickly tried the method Norbert suggested, many thanks, it seems to have worked. To note, I did not delete the entire Cache folder, just the ones relating to Safari subfolders. It seems to have worked, will do more observation.