[gdal-dev] "Very" long path name support under windows

[Even Rouault]

Philippe,

> I bumped into a problem under windows (Win7 or Win8 64 bits). I try to
> manage an image which directory name is "very long" (more than 260 chars) :
> 
>    cd C:\VeryLongDirectoryPath
>    gdalinfo Image.tif

I experimented a bit, and the truth is that Windows itself poorly supports such situation.
The explorer refuses to create long path names, so indeed I had to use Linux to create a zip
with long file names and unzip it on Windows with 7z...

Not sure how you managed to cd to a very long path.

>From Windows cmd, I tried to cd to my above long file path :

C:\Users\W7\dev\gdal\veeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeee>cd eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
The filename or extension is too long.

The only way I got to it was to copy&paste the directory From the Explorer but it
used a 8.3 filename trick to remain < 260 chars :

C:\Users\W7\dev\gdal\VEEEEE~1\EEEEEE~1\EEEEEE~1\eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeerylong>

and from there gdalinfo works.

> 
> I get the following message :
> "Error: Current working directory has a path longer than alloowed for a
> Win32 working directory.
> Can't start native Windows applications from here
> 
> gdalinfo: File name too long"

Not sure if it is an intrinsic limitation of Windows, or maybe the utilities
should use an alternate main entry point (a Windows unicode one ?) than the
C main() currently used.

> 
> I have the same problem when using system calls from a Java application.
> 
> I know there is a "legacy" limitation under Windows environnement, which
> limits total filename length to  MAX_PATH (i.e. 260 chars). However, many
> applications are not subject to this limitation (e.g. 7z).

When I added the Sentinel 2 driver in GDAL 2.1, I had to deal with this 
limitation since datasets have very long names (a newer revision of the format
will come with smaller filenames by the way) so there's some *limited* support
for long filenames.

>From a Python console:

>>> gdal.Open("c:\\users\\w7\\dev\\gdal\\veeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeee\\eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\\eeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee\\eeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee
eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeerylong\\byte.tif")
<osgeo.gdal.Dataset; proxy of <Swig Object of type 'GDALDatasetShadow *' at 0x00
00000001FECF90> >

Internally this works by adding automagically the \\$\ prefix in the implementation
of the Open() and Stat() methods. (For some reason using a filename with the explicit
 \\$\ doesn't work in the current implementation.)

This should also hopefully works from the Java bindings (nothing Python 
specific here). But you probably cannot use the utilities through system
 calls in that situation. You'd have to use the "utilities as library methods" way.

See the gdal.Translate(), etc methods in
http://gdal.org/java/org/gdal/gdal/gdal.html#Translate(java.lang.String,%20org.gdal.gdal.Dataset,%20org.gdal.gdal.TranslateOptions)
(no nice doc, just function signatures)

and

https://trac.osgeo.org/gdal/wiki/rfc59.1_utilities_as_a_library

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com