Opened 14 years ago
Closed 9 years ago
#3609 closed defect (wontfix)
VSIFileManager::GetHandler does not NormalizePath when determining handler
Reported by: | des4maisons | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | default | Version: | 1.7.2 |
Severity: | normal | Keywords: | vsi |
Cc: | Even Rouault |
Description
In port/cpl_vsil.cpp, line ~621, NormalizePath is not called before comparing pszPath with each filesystem handler's prefix. Therefore the following will return the default handler, instead of the VSIMemFilesystemHandler:
VSIFileManager::GetHandler("\vsimem\hello");
The last slash is converted to a forward slash before comparing, but the first slash is not.
This is inconsistent with VSIMemFilesystemHandler::Open, which normalizes the entire path before using it.
Change History (4)
comment:1 by , 14 years ago
Cc: | added |
---|---|
Keywords: | vsi added |
comment:2 by , 14 years ago
I am currently using the vsi stuff in a Windows application at a very low level, to replace calls to open, etc. The rest of the application expects '\' as directory separators, and so having a '/' in the filename might have broken things.
I do however believe that in my particular case, using "/vsimem\" as a prefix will work both with my code and gdal (though it looks rather terrible, and I would have expected it to work with "\vsimem\").
I filed the bug because everywhere else I looked in gdal, the path was _completely_ normalized before being used, but the code for GetHandler only changes the _last_ slash, which seemed inconsistent and not intended.
comment:3 by , 9 years ago
If I understand right, the problem is that a normalized path looks ugly, but is works. If system works with the ugly path I would suggest to close the ticket as invalid.
comment:4 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
No opposite reactions within a month, closing.
Even and I are hesitant about doing manipulations to the path before doing the handler prefix checks. What circumstance do you imagine would result in an application passing something prefixed with \vsimem\ instead of /vsimem/?
The internal GDAL code which uses /vsimem/ is careful to use forward slashes instead of backslashes. Since the paths will never come from an operating system level call, I'm not sure why operating systems would be coming up with this with backslashes.