Do long file and folder names matter?

As the subjectline says...does it matter how long the names are?

So, for eg., if I name a Word file as aaaaaaaaa_XXXXXXXX_333333333 and a folder in a similar fashion, would there be a problem?

I remember, not too well, once being told that long file and folder names do cause problems (at least they did when I was told so - say around Win 98 times).

Apologies if the question seems off the wall.

Cheers!

 

No, long filenames don't matter in any new operating system. If you don't go crazy with a 50 or 60 character filename (definitely keep it under 180 characters) and keep special characters out of file names, you should be fine. With very long file names and special characters you can get into trouble with some backup software (long names will be truncated) and some DOS applications, and also when nesting folders on a CD using ISO9660.

 

There is a hard-coded limit of 260 characters for path names. So if you exceed this limit, some programs might have trouble with it.

The reason for this 260 character limit is due to backwards compatibility - it was 260 characters in Windows 3.1 and so it's 260 characters in Vista, XP, 7, and every subsequent version of Windows. I believe that internally the OS can handle more - but it can't really ensure that it'll always work (again, due to backwards compatibility issues).

 

I'm kind of hoping for Microsoft to increase this limit. There are a lot of things that Microsoft is trying to do to maintain backwards compatibility, but at some point a line has to be drawn. Otherwise, progress would be hampered.

In a way, Windows 7's ability to run XP virtually would allow Microsoft to advance W7 without compromising backwards compatibility.

 

lol... if 260 chars isn't enough, it's time to move some of the info out of the filename and into the file...

 

problem is, it's a limit that gets compiled down into all programs and such. so every program would have to be changed and rewritten to allow for more than 260 characters. e.g. not gonna happen.

 

Windows technically can deal with longer pathnames. NTFS itself supports ~32k long paths, if I remember correctly.

But like davepermen said, too many applications have this limit hard-coded into them. Windows may be able to handle the long filenames, but a large proportion of applications won't. And what use is a filesystem if half your programs can't access your files?

 

Thanks guys for clarifying the matter! Makes sense!

@Swarmer...lol! well said!

 

jup. most applications that handle files are written like that

char filename[MAX_PATH]; // with max path beeing a constant, namely #define MAX_PATH 260

if a filename now would be bigger than maxpath, the application would, when loading the filename in there, have a buffer overrun. say hello to security holes.

i'd like to have longer filenames, but it aint gonna happen. at least as long as tons of code is still based on c / c++, where this still is the default way to handle a filename, sadly (or the wchar_t version, but 260 all the way).

apps would have to be recompiled.

what they could do, would be something like the dos filename support (8.3). so if a filename is too long, an app gets a shorter version virtually, to access that. but then again, we can just accept it as some "bad thing that doesn't hurt anybody".

the only moment i hit that problem is when extracting some illegal downloads into some subfolder. those are notorious for much-too-long filenames

jup, illegal downloads. there, i said it!

 

The limit of 260 is not just the file name but the entire PATH. So if you have large filenames inside large folder names, inside large folder names, inside large folder names etc. it can be pretty easy to hit that limit and then all hell breaks loose on some apps.

I was trying to help a client determine why their nightly backup was throwing strange errors about certain file names. Unfortunately the error was VERY obscure. But it came down to this 260 character limit.

But are we sure it is 260? I was thinking it was 255, for obvious reasons.

Gary

 

The MAX_PATH limit is 260 characters, according to this MSDN article - basically, 256 characters beginning with the first character of the first directory name and ending with the last character of the target file name, plus three characters for the drive letter and the ":\" characters that precede the first directory name, plus a terminating null.

 

Except that article also says:

So, I'm not sure what to think... 255/260 char limit is a bit short for the whole path, but 32767 chars is plenty.

 

Indeed; however, that is preceded by this statement:

I'd stick with the 260 character limit unless I knew specifically what functions in the Windows API can actually use an extended-length path. The remove file and remove directory functions don't use extended paths, as I have run across situations where a convoluted path has been constructed that exceeds the 260 character length, rendering the target file at the end of that path non-deletable (the simple solution is to map reachable directories to logical drives, move the current context to that new logical drive, from whence you will be able to reach down to a maximum of another 260 characters from the root of that new drive).

 

That makes sense. It is based on my suspicion of the string length limit being 255/256.

Gary

 

Yep. There is just so much legacy stuff and newer apps built to that old legacy to make it a tad dangerous to stray from it.

Gary

 

I can confirm that Vista insists on 255 characters for a path name. I had an app screw up and nest folders 50-100 levels deep. Vista complained that it couldn't delete them because the file names were too long. I also couldn't rename them from Explorer . I had to kill Explorer and manually rename everything from the command prompt.

 

Even though it's a moot point at this stage, you should also have been able to mount the deepest directory you could reach as a drive, and then use that as a new "root" starting point to get beyond the 255/260 limit on the path length from the actual root of the drive you were working on.

 

Wow, that's pretty bad that Explorer can't handle it. I'm not surprised there are some third-party programs that barf on long paths, but I thought Explorer would at least be able to handle them.

 

I have ran into the same problem before using XP and I used Shyster's method to fix it.

 

It is odd, particularly since it appears that Internet Explorer can handle full 32k character path names, as mentioned in this thread I found from a google search.

 

Maybe someone forgot to update it.

 

I don't think that's odd! It prevents users from creating too long directory paths using Explorer, which is completely logical. Wait... well, somewhat... you can still create them, but you can't make use of them using Explorer.

Just the way you can't access "C:\Documents and Settings", which is on purpose.

 

I always thought that was more of a bug than a feature. Since Windows Vista, "C:\Documents and Settings" no longer exists - it was relocated to "C:\Users" and an NTFS junction created in its old place. An NTFS junction is supposed to redirect you to the "real" folder location, but Windows Explorer doesn't handle it properly for some reason and gives you an Access Denied error instead.

 

no, i think it's fine that way. it isn't ment to be browsed by you and thus you're not granted the right. only if an application gets configured into "xp compatibility mode", then it gets special rights granted to those junctions.

at least, it could be that way. i have no need for xp compatibility mode, so i haven't tested out

 

Exactly - you can create a 32k character length path with IE, but then you'll be unable to access, or delete, that file using Explorer, unless you know how to deal with a too-long path in the first place. That's a bit backwards, if you ask me; Explorer should have had that capability before IE, not after.

Can't access "C:\Documents and Settings" how? I can get to it in a variety of ways.

EDIT: Nevermind; I realized what you were getting at after I read sc4freak's post (and then tried it out myself, with the same result).

 

I don't think it's a matter of not having the right permissions. I think it has something to do with the nature of a junction point itself. I just checked out the permissions for the junction point "c:\Documents and Settings" on my _Vista machine, and the administrator account I set up has almost a full set of privileges, including permission to list and traverse that junction point.

When I logged into that account, I got the access denied error if I tried right-clicking directly on the icon for the junction point; however, when I opened up a console window (good ole cmd) and ran the command

Code:

dir "c:\Documents and Settings\Administrator"

, I got the directory contents for the real path "c:\Users\Administrator" so it would seem that the role of a junction point is to act as some sort of a reminder to the file manager to replace the old "documents and settings" part of the path with the new path.

It's all mysterious at this point because I've not found anything that really tells me what a junction point really is, and how it works under the hood, just some fancy hand-waving about what it's used for.

 

Go to MSDN and search for junction points.

They have been a part of NTFS for a long time. They serve the same function as aliases in unix, except they aren't as fully featured.

The "C:\Documents and Settings" Junction point serves to redirect legacy programs (anything not written for Vista basically) to the User directory.

 

Yup, yup, and yup. What I'm looking for is something along the lines of a Windows.Internals type of discussion of junction points.

 

That seems strange. One would think that older file systems would just use the 8.3 system and truncate each folder or file with a "~" at the end (i.e C:\Progra~1\ for C:\Program Files)

 

The reason for this is legacy compatibility. Many poorly written applications have the folder for user data hardcoded as "C:\Documents and Settings". Because that has been changed in Vista (the official path is now "C:\Users"), Microsoft put that fake "C:\Documents and Settings" in. That you can not access it that easily is on purpose, because otherwise software that for example creates a graphical presentation of the filesystem or backs up data would use "C:\Users" as well as "C:\Documents and Settings", so it would see these as two separate directory paths with the same contents.

Vistas filesystem is also meant to be language independent. While on my German version of Vista the user data path is also "C:\Users", Explorer shows it as "C:\Benutzer". The reason for this is that from Vista on special desktop.ini files can be used to tell Explorer what name it should display for a particular file or folder (this is also a security problem, as you can tell explorer to display "notes.txt" for a file that actually is "virus.exe", for example).
Also, I have "C:\Documents and Settings" as well as "C:\Dokumente und Einstellungen", because that's what it was called in the German version of XP - in XP, these folders were language dependant. So Microsoft changed that so that it's now ALWAYS "C:\Users", even if you install Vista on D:. Good for all these developers of poorly written software...