Path and file name maximum length 2

[ovs8]

Hi there,

From what I understand NTFS's maximum path length is 256 characters. Does this include file name or not? And conversely, the file name limit of 256 characters - does it include directory path?

Seems like it does. I created a long path on our network (~245 charactes). Then I created an MS Office file. I was able to name it with shorter names and could not name it with longer names when filename+directorypath exceeded 256 characters.

Any ideas?
thanks,
Oleg

 

[Lemon13]

ntfs can more (32k) but win-api only 256b

 

[strongm]

The actual limit is 260 characters, and it is a Windows API limit rather than NTFS itself. And whilst the path limit is 260 characters no individual element in the path (eg a folder name or file name) can be longer than 255 characters

>Does this include file name or not?

Yes, it does; Microsoft actually define a path as containing the filename

 

[kmcferrin]

Interesting. I had recently run into some issues with extremely deep directories (over 260 bytes in the path) on a Windows-based file server, and couldn't figure out how they managed to actually created the directories. Someone mentioned the possibility of using a Mac, and since the limit is in the Windows API rather than the filesystem, that makes sense.

But I've got to wonder why they would design a filesystem for an OS that was capable of storing longer paths than the OS was capable of using. Seems like a recipe for problems down the road.

 

[porkchopexpress]

I remember reading that this can happen if the file is created through a share that is lower down the file structure, then when you attempt to access the file from the root of the drive using the GUI you encounter issues.

 

[itsp1965]

I have had this problem occur on many contracts that I have supported in the past. User education doesn't help, they still create long-winded files and pathnames. Then they complain that they can't open, modify, delete files and they flood the helpdesk, who doesn't know any better and pass it on to either security teams (thinking it's an access problem) or to the server teams (thinking it's a server disk issue)
The solution to accessing these files is to use the good old DOS SUBST command which will create a pseudo-map to the folder as follows;

SUBST X: \folder\subfolder1\sub2...\subx

From there just go to X: and then you will be able to dig down further and manipulate the files/folders accordingly.

 

[kmcferrin]

Yeah, that would work, but the problem that I had was with a script that I wrote that walked the directory structure and archived files older than a certain age. IIRC, this structure had literally millions of files in it and thousands of subfolders, so mapping to some point further down the tree each time that I came across the problem would have been problematic. Just the log files for the scans were around 600 MB.