The path max_length limitation is well known, but interestingly enough Microsoft states that the 260 limit (including the "c:\" and line termination null char, so in effect it 256 chars from the current drive root) is not the maximum length possible for a path on Win32:
"Note The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length. The "\\?\" prefix can also be used with paths constructed according to the universal naming convention (UNC). To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the name of the computer and "share" is the name of the shared folder. These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory. Because you cannot use the "\\?\" prefix with a relative path , relative paths are always limited to a total of MAX_PATH characters. There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions because the file system treats path and file names as an opaque sequence of WCHARs. Any normalizations your application requires should be performed with this in mind, external of any calls to related Windows file I/O API functions. When using an API to create a directory, the specified path cannot be so long that you cannot append an 8.3 file name (that is, the directory name cannot exceed MAX_PATH minus 12). The shell and the file system have different requirements. It is possible to create a path with the Windows API that the shell user interface might not be able to interpret properly."
So if you are a Windows developer you can create and access paths way beyond the 260 char limits that will not be interpreted properly by the Windows shell. Wondering if the content on the long path end would still show up or not though!
Now I'm blogging on the subject only because the ghost of AKB #27481 is back to haunt me (this is a feature request I created and that I am following on now in the SMP 7 world). Checking now if the alternate download location is really just that now (because in the 6.0 world it really is just "alternate run location" as the files are downloaded in the default package delivery folder and copied across, then the task run from that alternate location).