"Process a path as a null-terminated string. The maximum length for a
path, including a trailing backslash, is given by MAX_PATH. The Unicode
versions of several functions permit paths that exceed the MAX_PATH length
if the path has the "\\?\" prefix. The "\\?\" tells the
function to turn
off path parsing. However, each component in the path cannot be more than
MAX_PATH characters long. Use the "\\?\" prefix with paths for local
storage devices and the "\\?\UNC\" prefix with paths having the
Universal
Naming Convention (UNC) format. The "\\?\" is ignored as part of the
path.
For example, "\\?\C:\myworld\private" is seen as
"C:\myworld\private", and
"\\?\UNC\bill_g_1\hotstuff\coolapps" is seen as
"\\bill_g_1\hotstuff\coolapps"."
So applications are able to create paths that have path longer than 255
characters by changing the working directory to something long (perhaps
using multiple mkdir/chdir) and creating the file there, or by specifying
the full path with the unicode/"\\?\" hack.
Cygwin doesn't do either.
I talked about this with one of the Cygwin contributors, Chris January (who
has a unicode filename support patch for cygwin pending btw), but he
suspected that even if cygwin supported total path lengths greater than
MAX_PATH (255), many application would break, since they don't support so
long file names. (Perhaps rising cygwin MAX_PATH to something higher, and
recompiling the apps would help.)
Btw, this is not a problem for just cygwin apps. Many other windows apps
can't access the long path files (virus scanners, backup software have been
tricked by this.) And not only long paths. You can create files like
"c:\prn" or "a:\lpt1" with the \\?\ hack, and that confuses
even explorer
(this perhaps has been fixed since.).
Getting back to rsync/cygwin - it can't access filenames with unicode
(different char set) letters in them either. As I said, Chris January has
created an UTF8 patch for cygwin that addresses this, but it hasn't been
merged so far.
-- v --
v@iki.fi
