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 warmerdam, 14 years ago

Cc: Even Rouault added
Keywords: vsi added

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.

comment:2 by des4maisons, 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 Jukka Rahkonen, 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 Jukka Rahkonen, 9 years ago

Resolution: wontfix
Status: newclosed

No opposite reactions within a month, closing.

Note: See TracTickets for help on using tickets.