Anybody home?
The reported bug concerns also every attempt to create
a directory via command line output parameter. Example:
test.xslt:
==========
   <xsl:stylesheet version="1.0"
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   >
     <xsl:template match="/">hello</xsl:template>
   </xsl:stylesheet>
command line:
=============
   xsltproc -o test/test.txt test.xslt test.xslt

xsltproc -V:
============
   Using libxml 20615CVS2219, libxslt 10112CVS965 and libexslt 810CVS965
   xsltproc was compiled against libxml 20615, libxslt 10112 and libexslt 810
   libxslt 10112 was compiled against libxml 20615
   libexslt 810 was compiled against libxml 20615

Works for me !

paphio:~ -> xsltproc -o does_not_exist/res tst.xsl tst.xsl
paphio:~ -> cat does_not_exist/res
<?xml version="1.0"?>
hello
paphio:~ ->

Daniel

> paphio:~ ->
         ^
         ^
         Are you sure you use w32 (not cygwin!)   ;o)

(under cygwin it works for me too)

ohhh, it's a Windows only bug ! I didn't realize that,

okay, but I can't test it myself, maybe you should post to the list
about that.

Daniel

Thomas is right, the same symptoms under "pure" windows for me.

So, what can we do? Which Information is needed?

Thanks for any help!

Andreas

Th.-Fischer, andreas: is this still an issue?

daniel: *ping* - can you answer andreas' question how to provide information?

thanks everybody! :-)

No idea, I don't have any Windows box around ... can't test, won't fix
myself, but I take patches especially if discussed on the list (since
basically I can't test said patches)

Daniel

Hi,

I have the same problem and like to help. Is the bug still open or not currently processed ?

Trying to figure out where the problem is in comparsion to cygwin, I guess it is the difference
between slach and backslash of the URI.

So it would be helpful to hint me where to reqwrite the URI and if there is a function for it which ?

Lothar

Try the latest release. I believe this issue was related to another that was fixed in 2.6.30

Did you mean the libxml2 version (2.6.30) ?

Sorry, yes. Also in combination with libxslt 1.1.22. The original bug reported here works fine for me, so see if you still have problems with the latest releases

I have copied the xmlIO.c file from 2.6.30 and it had helped with one exception:

I do use Open Watcom compiler (1.3) on my development machine. And therefore I have made
some extentions to be able to compile both, libxml2 and libxslt. This way I tried to copy only
that file I guessed to solve my problem.

The exception is, that there is propably a bug in xmlWrapStatUtf8. I have added some lines
to fall back to native version when compiled under Open Watcom. 

The bug happens due to passing a reference to a struct stat variable to a function handling
with struct wstat. This results into a buffer overrun I think and kills the contents of at least
the path pointer variable.

To make a full bugfix, I think I need to repackage a copy of the contents of the wstat structure into
the stat structure and propably convert WChar strings back to Utf8 and pass the copy to _wstat(),
or anything that has not the same size.

I have another question: Do you like to have the changes I made to compile libxslt with the
Open Watcom compiler (only a DLL version yet) ?

I have made special extentions to get exports of some functions without touching them.

If there is no way to help you adding Open Watcom support, I need to add the code in my vendor
directory on my CVS to track my changes.

Here is the function with bugfix:

static int
xmlWrapStatUtf8(const char *path,struct stat *info)
{
#ifdef __WATCOMC__
	return xmlWrapStatNative(path, info);
#else
#ifdef HAVE_STAT
    int retval = -1;
    wchar_t *wPath;

    wPath = __xmlIOWin32UTF8ToWChar(path);
    if (wPath)
    {
       retval = _wstat(wPath,info);
       xmlFree(wPath);
    }
    /* maybe path in native encoding */
    if(retval < 0)
       retval = stat(path,info);
    return retval;
#else
    return -1;
#endif
#endif //__WATCOMC__
}

A lot of information there :).
First, based on what you are saying, is this bug currently fixed and your issue is just the needed Watcom changes? If so, this bug should be closed.

Secondly, can you send the Watcom related information, issues and suggested changes to the list? Might possibly also get some comments from other Watcom users.

Well, running the style sheet in the original comment of this bug with xsltproc (Using libxml 20632, libxslt 10124 and libexslt 813), I get no abc subdirectory of the current directory.

And that's on Fedora 9 with libxslt-1.1.24-1.fc9.i386

Sorry, nonsense, I forgot to add input file. No, I cannot reproduce the original issue here. This bug should be probably closed.

GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/libxslt/-/issues/

Thank you for your understanding and your help.