Bugcheck 19 with Adobe Indesign

Indesign.exe process sends a create of a very large file path in IRP (much more than 260 characters), the file name actually is some piece of programming code:

\********************
*****************************************************
\


----------------------------------------------------------------------------------------------
It overrides the MS guidelines for having 260 characters in a file path. Can we expect valid file names to be longer than 260 characters? How does NTFS handle such names?

> It overrides the MS guidelines for having 260 characters in a file path.

That is a Win32 limitation (I think). The system API allows for any path
name that can be described by a UNICODE_STRING so that max path is 2^15
32,000 characters or so.

Of course you can construct paths which are longer that that by doing
relative opens in which each file name is 32K characters long.

I, for one, would be astonished if NTFS (or any other Microsoft kernel
product) didn’t handle this.

Of course once you have one of these there’s not much you can do with it
(for instance I would be somewhat surprised if Explorer managed to do
anything sensible)

Can we expect valid file names to be longer than 260 characters?
Yes, you should always assume that someone (and hopefully it will be someone
in your test team) will push the System service APIs to the extreme.

/Rod

The 32K limit is the length of the entire path, not a single element. The full path has to fit inside a UNICODE_STRING. I think I remember discovering empirically that NTFS limits a directory to 255 characters, but that was quite a while ago, and I wouldn’t testify to that being absolutely true without repeating some experiments that I don’t have readily to hand.

Both explorer and cmd.exe try pretty hard to stay under the 260 char full path limit. You can use cmd to create a really deep path by renaming a directory to a really long name, but you can’t CD into it once you’ve created it. Once you’ve created a path that exceeds 260 chars total, in order to remove it from the FS, you have to reverse the process by renaming each long element, until the longest full path in the tree is shorter than 260.

I haven’t tried anything like that on anything newer than Windows 7.

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
The Security Intelligence Company
A LEADER in Gartner’s SIEM Magic Quadrant (2012-2014)
Perfect 5-Star Rating in SC Magazine (2009-2014)
BEST SIEM: Information Security Magazine & SearchSecurity.com 2014 Readers’ Choice Awards

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Friday, March 27, 2015 4:00 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Bugcheck 19 with Adobe Indesign

It overrides the MS guidelines for having 260 characters in a file path.

That is a Win32 limitation (I think). The system API allows for any path name that can be described by a UNICODE_STRING so that max path is 2^15
32,000 characters or so.

Of course you can construct paths which are longer that that by doing relative opens in which each file name is 32K characters long.

I, for one, would be astonished if NTFS (or any other Microsoft kernel
product) didn’t handle this.

Of course once you have one of these there’s not much you can do with it (for instance I would be somewhat surprised if Explorer managed to do anything sensible)

Can we expect valid file names to be longer than 260 characters?
Yes, you should always assume that someone (and hopefully it will be someone in your test team) will push the System service APIs to the extreme.

/Rod


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Correct, the maximum component length in NTFS is 255 characters. That’s for a file or a directory.

The maximum component length can vary from file system to file system. The following link mentions this and also has other good information about file names and path names:

https://msdn.microsoft.com/en-us/library/aa365247.aspx

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Phil Barila
Sent: Friday, March 27, 2015 7:53 AM
To: Windows File Systems Devs Interest List
Subject: RE: Re:[ntfsd] Bugcheck 19 with Adobe Indesign

The 32K limit is the length of the entire path, not a single element. The full path has to fit inside a UNICODE_STRING. I think I remember discovering empirically that NTFS limits a directory to 255 characters, but that was quite a while ago, and I wouldn’t testify to that being absolutely true without repeating some experiments that I don’t have readily to hand.

Both explorer and cmd.exe try pretty hard to stay under the 260 char full path limit. You can use cmd to create a really deep path by renaming a directory to a really long name, but you can’t CD into it once you’ve created it. Once you’ve created a path that exceeds 260 chars total, in order to remove it from the FS, you have to reverse the process by renaming each long element, until the longest full path in the tree is shorter than 260.

I haven’t tried anything like that on anything newer than Windows 7.

Phil

Not speaking for LogRhythm
Phil Barila | Senior Software Engineer
720.881.5364 (w)
LogRhythm, Inc.
The Security Intelligence Company
A LEADER in Gartner’s SIEM Magic Quadrant (2012-2014) Perfect 5-Star Rating in SC Magazine (2009-2014) BEST SIEM: Information Security Magazine & SearchSecurity.com 2014 Readers’ Choice Awards

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Rod Widdowson
Sent: Friday, March 27, 2015 4:00 AM
To: Windows File Systems Devs Interest List
Subject: Re:[ntfsd] Bugcheck 19 with Adobe Indesign

It overrides the MS guidelines for having 260 characters in a file path.

That is a Win32 limitation (I think). The system API allows for any path name that can be described by a UNICODE_STRING so that max path is 2^15
32,000 characters or so.

Of course you can construct paths which are longer that that by doing relative opens in which each file name is 32K characters long.

I, for one, would be astonished if NTFS (or any other Microsoft kernel
product) didn’t handle this.

Of course once you have one of these there’s not much you can do with it (for instance I would be somewhat surprised if Explorer managed to do anything sensible)

Can we expect valid file names to be longer than 260 characters?
Yes, you should always assume that someone (and hopefully it will be someone in your test team) will push the System service APIs to the extreme.

/Rod


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer


NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

> Correct, the maximum component length in NTFS is 255 characters. That’s

for a file or a directory.

I didn’t know that, thanks. As a random question does that include the
stream and attribute or is that different?

Nonetheless I maintain that any filter *has* to be able to handle and
component of any size up to the 32k Char limit as per the interface: there
are more filesystems than just NTFS. But this does not seem like a
particularly onerous restriction.

As for the FQP as I think about it it has to be limited to 32kchar because
of various API limitiations (MJ_QUERY_INFORMATION et al), I apologise for my
misdirection.

Filters have a limit which is slightly less than this because filter manager
has to construct an FQP including the device name (and, potentially, share).

/Rod

It’s the file name.

The actual value is obtained from the file system via the IRP_MJ_QUERY_VOLUME_INFORMATION operation, with the FileFsAttributeInformation. It returns the size in the following structure:

typedef struct _FILE_FS_ATTRIBUTE_INFORMATION {
ULONG FileSystemAttributes;
LONG MaximumComponentNameLength;
ULONG FileSystemNameLength;
WCHAR FileSystemName[1];
} FILE_FS_ATTRIBUTE_INFORMATION, *PFILE_FS_ATTRIBUTE_INFORMATION;

Not just filters, but really any software that wants to work properly on Windows.

The MAX_PATH_LEN is an MS-DOS inherited restriction. People who don’t insist on living in the MS-DOS world still can read the Win32 documentation that discusses this (specifically, review CreateFileW - and note that names with “\?” are not subject to the MS-DOS limitation).

It does make writing software like this annoying, but it’s not onerous and doing so ensures that your code works properly. Failing to do so has a nasty tendency of creating security holes in your driver.

Tony
OSR

> That is a Win32 limitation (I think).

…and there is no such limitation if the name is Unicode and uses \?\ prefix


Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com