Re: [xslt] create Directory bug in libxslt for W32

On Wed, Dec 01, 2004 at 07:19:59PM -0600, Aleksey Gurtovoy wrote:
> Daniel Veillard writes:
> > On Tue, Nov 30, 2004 at 03:10:38PM -0600, Aleksey Gurtovoy wrote:
> > > Thomas Fischer writes:
> > > > Hi folks,
> > > > i found a bug in libxslt and Daniel Veillard told me, that's
> > > > a win only bug and he can't help   :o<
> > > > 
> > > > The Bug occurs, when i try to create a directory via command
> > > > line parameter --output (like "xsltproc -o does_not_exist/res ...")
> > > > or via <exslt:document href="does_not_exist/res"
> > > > 
> > > > Anybody knows a workaround or patch for this problem?
> > > 
> > > See the attachments for the latter (against the current CVS).
> > 
> >   I do not understand the first patch nor the associated
> > side effects. On windows the file path separator is '\' why is this
> > wrong and need to be removed.
> I agree that the patch is a little controversial, but only due to the fact 
> that 'xmlParserGetDirectory' is used to extract directory paths from both 
> URI/URLs _and_ file system paths. For the former the running platform is 
> irrelevant; for the latter it's not (obviously). I'm not that familiar with
> the libxslt/libxml2 codebase to be able to say in how many cases when a
> function is passed a 'filename' argument it actually _is_ a native 
> filesystem path (as opposite to a URL), but I assume that at least some 
> of them are. Of course you're in much better position to answer this.
> In any case, my take on the issue is that, ideally, all current calls
> to 'xmlParserGetDirectory' should become calls to either 
> 'xmlParserGetURIDirectory' or 'xmlParserGetFileDirectory' (both currently 
> non-existent), the latter differing from the former in that it would 
> respect the running platform's conventions.
> Does it make sense to you?

  yes, except if xmlParserGetURIDirectory is by all means the same as
xmlParserGetDirectory then I would rather indicate in the doc that it should
be used on URI and not change the name. The API is already huge. I also
don't know exactly where xmlParserGetFileDirectory should be called, 
i.e. where we are sure that the name for the resource is garanteed to
be a file path.

  I'm not fond of the other suggestion to use either '/' or '\', 
in the function, people are using things like\bar
and I prefer to not introduce more ambiguity in the way we process
file paths and URIs.

  On a related note someone should look at the new IETF draft for file URIs

and try to see if we can improve the implementation on Windows to support
all the file convention that they list.


Daniel Veillard      | Red Hat Desktop team
veillard redhat com  | libxml GNOME XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]