Does windows have same maximum path lengths (name of directory entry) for different filesystems it mounts?

I have to know if a specific vulnerablity in TCL 8.4 affects Windows platform

The vulnerability is开发者_JAVA技巧: http://www.securityfocus.com/bid/15259/info As per the link:

Operating systems with no difference in the maximum path lengths among differing file systems are not affected by this issue

I am using TCL on windows and want to know if this vulnerablity affects TCL on windows and how ?

Further, how can a person exploit this vulnerability on Windows ?

Thanks

The windows header files define MAX_PATH - as 260 - as the usual maximum path size. This isn't really universally applied. There are a number of ways to bypass this limit, in which case the effective path limit is, well, unlimited. Or 32,767 characters. Whichever is shorter.

Naming, Files, Paths and Namespaces has more info.

While there exist common conventions regarding maximum file name and path length, certain file system drivers (or third-party file system implementations) might have their own limits which can be lower, than the commonly used ones.

That article does not mention any vulnerability of systems hosted on Windows to this at all; the standard recommended size of buffer to be allocated there is sufficiently long to hold any legal filename. This is specifically true for Tcl (Tk does not do directory scanning except via Tcl's interfaces).

Exploiting the vulnerability on Windows is going to be hard (and impossible with Tcl, which is very careful with buffer management). If you're on another platform, you are recommended to switch to a later patchlevel of Tcl; the current version is 8.4.19. (Actually, you're recommended to switch to the 8.5 series – currently 8.5.9 – as 8.4 as basically been EOLed; there will be maybe one more roll-up release on that branch but bugfixes are now only committed to 8.4 for critical things like demonstrated security issues or build-chain problems.)

Note that, since Tcl has never allocated buffers for holding a whole path directly anyway, it's not clear how this sort of thing could cause an exploit in the first place. The article does state that there is no instance of this issue in the wild.