I have a hundred or so images on my computer that have very long names, like 20-40 words long.
My computer has also started to behave a bit odd, like defaulting to folders I didn’t select, etc (hard to put in words.) If you have a name that’s too long for a file, does the computer automatically prevent you from even saving as such, or does it let you save but then the long name causes problems?
The limits depend on the operating system and its file system. In Linux on the ext4 file system (and most modern Unixes, the limit is 255 bytes on a file name, and there’s no limit on the path length. Windows apparently has a 256 character limit, including the file path (hmm, but further reading seems to say this is configurable in Win 10 and later to a 32K characters or so) .
I’ve never encountered a problem with the length of file or folder names on MacOS machines. It either will or won’t let you name a file with a name that long, but if it does it doesn’t seem to create subsequent problems.
Windows is different. Create a file with a longish filename, like “October 2017 thru December 2019 Single-Encounter Purchases, New Clients_final.pdf”. Process it (e.g., type the contents of it into a database or whatever) and then file it by dragging it to \Shared\2019\PostProcessing\DataEntry\Done; it may let you do so but then won’t subsequently let you open it in Adobe Acrobat or rename it, because the total file path is too freaking long for Windows to cope with. I dont know what the limitations are but it definitely has them and I’ve hit them at my place of employment pretty often.
Problems can also arise sometimes if you’re using an old app, that was written before whatever the current limits are. Probably not as big a deal nowadays, since long names have been a thing for a long time now, but it was often a headache back when MS-DOS was a recent memory (since MS-DOS only allowed 8.3 characters).
Same with old Mac applications that never got properly updated. I still use Timbuktu, and it’s a wonderful old beast with amazing backwards compatibility, but if you drag a file from one computer to another, the filename gets truncated to 32 characters (MacOS 9 limit) and ends with a tilde and a number.
It probably doesn’t apply, but at work we have a document management program that can have trouble with long names. When the documents are sorted into folders to make them easier to find, and then the folders are put into folders, etc., there can be a problem. The names of the documents get each of the folders’ names added to it and that can end up surpassing the character count of the field.
During training keeping doc names short was emphasized because the name could be fine when first entered, but too long when sorted into the existing folders.
Hint: in threads asking for computer advice, mentioning what OS & brand computer and general age / capability is very helpful. As well as mentioning your own skill level.
Assuming a PC running windows 10 or later and new enough to do so w decent perf. …
In later versions of Windows itself, long file names, and long path lengths (depth of nested folders with long names themselves) is simply not an issue.
Some older apps have trouble. Sme backup or cloud sync apps have trouble too. MSFT’s stuff does not.
If you’re having other weirdness long filenames and paths is not the true cause.
What does “defaulting to folders” even mean in the context of Windows?
Does this mean that, when you go to save a file (such as an image), the initial folder which shows up in the “Save” tool isn’t the folder where you would want to put it, or usually put such files (and, thus, you need to select a different folder)?
The OS itself will stop you from making a file name too long for the OS to deal with.
Individual applications might have problems with certain file names the OS is fine with.
The name of a file is a very interesting thing. Just what it is varies significantly between operating systems and the file systems they use. That alone tells you an important point. The operating system is not generally the file system. Modern operating systems support more than one file system and the nature of the name of a file can differ between the different file systems.
Unix systems of various ilk all tend to use the same basic abstraction of naming files. Which is at core a system where files do not have names at all. Rather there are directory entries that reference files. The same file may be referenced from more than one directory. No reference is any more the prime reference than another. Other operating systems and file systems can require that files carry their name, or even that files carry a universal identity the doesn’t change even when you move and rename it.
MacOS imported a whole slab of Unix when OS X came along. But previous Mac OS versions ignored case in file names. Unix file systems generally do not. There was an entire paper devoted to the rationale for handling file name conflicts that might occur between different supported file systems and the problem of case sensitivity. Very early system updates could fail due to exactly this problem. You can still get into trouble.
In the early days of SunOS/Solaris the system was updated to cope with very long path names (the entire string containing directories and file names) with the command shells updated to allow for vastly longer path names. All manner of nasties could arise as file names started to get longer. Since the shell in Unix usually expands file names out it was possible for crazy long command lines to be created. Internally programs needed to be able to cope with this as well. This became a much bigger problem as remotely provided network file systems became a thing.
The idea that file names are maintained in a separate database from the files is another possibility. The semantics of this are almost arbitrary. Often naming, authentication and access rights get managed in separate but overlapping ways. Remotely accessed file systems, over a whole gamut of protocols with all manner of slightly different semantics is yet more fun.
So, yes. Very long file names can cause arbitrary difficulties. The dominant operating systems, Linux, Windows and MacOS all support interrelated access to one another in various ways. Sorting out how this works is a non-trivial problem. Support for legacy file system formats just throws more difficulties in the way. There is an element of “you can’t get there from here” in all of this.
Untrue, unless the computers at work are just pretending to be running Windows 10. Or (I guess) if by “later versions of Windows itself” you mean Windows 11.
At least once a month I have to rename some folders to single-character filenames to be able to move or rename one of the files within them. Because they got dragged into a folder after processing that, in conjunction with the filename itself, makes the path too long. Can’t open the file. Can’t rename the file. Can’t delete the file. (Oddly one can COPY the file to the Desktop and open it there, but doing so leaves the original file, and the problem, intact).
Yep, same here, have to rename folders or files.
Could you be experiencing this issue?
Sure. That’s possible. My employer doesn’t give me the credentials to go poking around in the registry. The applications that won’t successfully open the files are Adobe Acrobat and Microsoft Excel; I would guess them both to be 64 bit applications but I’m not Windows-centric… still, I can probably invoke one of those “About” commands from the menus and find out after I log in later on today.
Would I be correct in assuming that if either of those apps are 64-bit apps, this HKEY isn’t the cause of the behavior?
Yes, but not quite just that - I mean it sends me to folders I’ve never been to before.
An example of such a folder name/path would be helpful if you can do that without disclosing secrets.
Within some of the common folder in Windows, e.g. “My Pictures” now called “Pictures”, “Desktop”, “Documents”, etc., there is more than one path to get there. Only one such path is the true physical one, the rest are various forms of alias. For normal use, the alias appropriate for your current version of Windows is all a non-techie user will ever see.
It may be that sometimes the long filenames are provoking errors in one app or another that expose you to either an old-version alias or to the true physical path to the very same folder(s) that you only know by another alias.
Excel is definitely 64-bit. Version 2208 Build 16.0.15601.20540 (64-bit) it says.
Acrobat, however, is 32-bit. It is possible that I am misremembering and the file path problem was only with Acrobat files and not with Excel files.
Which can lead to bugs when things don’t happen as expected. For instance, when all directory references to a file are removed, the file itself is supposed to be marked for deletion. This is done by each file containing a counter for how many directory listings it has, and every tool that can change a directory listing is supposed to update that count. But if the tools don’t work right for some reason, it’s possible to end up with an orphaned file, that doesn’t actually have any directory references pointing to it, but still exists. And it now can’t be deleted by any ordinary tools, because those tools are designed to not be able to delete a file without removing all of the directory references.
This is useful in that a file can’t be deleted out from under a running program that has it open.
When the program closes the file (possibly by exiting) the last reference is removed and the file is actually deleted.
Mostly a recent macOS user, but I get out and about sometimes. I waffle between terse file and folder names - in order to avoid path length problems discussed here, and then evocatively descriptive file and folder name patterns - which usually bite me down the road. One trick I HAVE learned is to put the file name IN the file - and date created! - easy in text and spreadsheets, variously clever in other formats. And to keep folder names succinct, but with an empty subfolder or stub text file whose name expands the description, in case some little birdie eats my breadcrumbs and I forget where I am.