Quantcast

"Very" long path name support under windows

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

"Very" long path name support under windows

Bugbuster
Dear all,

I have already posted this question a while ago, but I just noticed it has never been accepted by the mailing list. And I don't know how to make it accepted today. I do feel sorry for this double-posting.

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 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"

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).

I am looking for a solution when using GDAL utilities with system calls from a JAVA application
Is there a way to deal with this limitation under windows ? Should we use the 8.3 naming convention ? And how ?

Thanks for your help.
Philippe

P.S. :
* Env. : Windows 7 or Windows 8 64-bit
* GDAL V2.0.2
* Using Cygwin Mintty windows : directory names are not shortened to 8 characters
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Very" long path name support under windows

Even Rouault-2
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
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Very" long path name support under windows

Bugbuster
Hi Even,

thanks for your long and detailed answer. I have plenty of information I can play around with.

In fact, I managed to "cd" to the desired directory within a Cygwin Mintty windows. In this window, I do not have the "8.3 Windows renaming". In that way, I mimicked what I get with a system call from a JAVA program.

I will try to see what we can do with the "utilities as library methods" way as you say. We just need to upgrade to Gdal V2.1 :-)

Thanks again for your help.
Philippe
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Very" long path name support under windows

Damian Dixon
Hi Even, Philippe,

Windows has two types of paths.

The first is essentially the codepage and is about 260 characters.

The second is the unicode pathname which is probably around 32k characters. I can't remember the actual limit.

The cmd line and explorer only use the 260 character limit.

So a unicode program can create a path that is not particularly useable via the cmd line or via explorer. cygwin bash shell works though.

You have to use the win32 unicode versions of the file open etc... to use the nice long paths.

Regards
Damian


On 23 November 2016 at 16:57, Bugbuster <[hidden email]> wrote:
Hi Even,

thanks for your long and detailed answer. I have plenty of information I can
play around with.

In fact, I managed to "cd" to the desired directory within a *Cygwin Mintty*
windows. In this window, I do not have the "8.3 Windows renaming". In that
way, I mimicked what I get with a system call from a JAVA program.

I will try to see what we can do with the /"utilities as library methods"
way/ as you say. We just need to upgrade to Gdal V2.1 :-)

Thanks again for your help.
Philippe



--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Very-long-path-name-support-under-windows-tp5297074p5297164.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev


_______________________________________________
gdal-dev mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Very" long path name support under windows

ianinKL
http://https://msdn.microsoft.com/en-us/library/windows/desktop/aa364963(v=vs.85).aspx Microsoft has a very succinct summary of the issue and how to address it:
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Very" long path name support under windows

morgancooper
This post has NOT been accepted by the mailing list yet.
Same situation was for me before but when i installed Long Path Tool, my computer became free from any problems.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: "Very" long path name support under windows

morgancooper
This post has NOT been accepted by the mailing list yet.
In reply to this post by ianinKL
Same situation was for me before but when i installed Long Path Tool, my computer became free from any problems
Loading...