Re: UdmSearch: file: URL indexing bug in mnoGoSearch 3.1.9 / udmSearch 3.0.23

2001-01-30 Thread Alexander Barkov 

Hi!

Finally I've checked your patch. Now indexer works as expected.
Thanks you very much!



Kaspar Brand wrote:
 
 Hi,
 
 when experimenting with udmSearch/mnoGoSearch, I encountered the following
 bug when indexer processes file: URLs. While indexer correctly processes
 file names containing special characters (which are escaped by %XX
 sequences), it fails to do so when the *directory* part (dirname) of the
 URL, i.e. given the following URLs -
 
 file:/directory1/file%201  ("/directory1/file 1")
 file:/directory%202/file2  ("/directory 2/file2")
 
 indexer will mistakenly treat the second URL as a directory, which means it
 rewrites it to "file:/directory%202/file2/" and tries to read its
 (non-existing) directory contents. The overall result is that indexing such
 files fails with status 500 (Internal Server Error).
 
 Fixing this bug is simple (I'm attaching a patch for mnoGoSearch 3.1.9). I'm
 not really proficient in C, but as far as I can see, this patch fixes the
 problem. (In short: UdmFILEGet() in proto.c now uses "openname" [the
 unescaped form of the current directory] instead of "filename" [the escaped
 form] when putting together the directory name and the entries it reads from
 it. This prevents it from mistakenly recognizing file entries as
 (sub-)directory entries. I can elaborate on this fix if anybody is
 interested.)
 
 Hope this helps. And yes, I like mnoGoSearch. Nice thing.
 
 Regards,
 Kaspar
 
 __
 If you want to unsubscribe send "unsubscribe udmsearch"
 to [EMAIL PROTECTED]
__
If you want to unsubscribe send "unsubscribe udmsearch"
to [EMAIL PROTECTED]

UdmSearch: file: URL indexing bug in mnoGoSearch 3.1.9 / udmSearch 3.0.23

2001-01-28 Thread Kaspar Brand 

Hi,

when experimenting with udmSearch/mnoGoSearch, I encountered the following
bug when indexer processes file: URLs. While indexer correctly processes
file names containing special characters (which are escaped by %XX
sequences), it fails to do so when the *directory* part (dirname) of the
URL, i.e. given the following URLs -

file:/directory1/file%201  ("/directory1/file 1")
file:/directory%202/file2  ("/directory 2/file2")

indexer will mistakenly treat the second URL as a directory, which means it
rewrites it to "file:/directory%202/file2/" and tries to read its
(non-existing) directory contents. The overall result is that indexing such
files fails with status 500 (Internal Server Error).

Fixing this bug is simple (I'm attaching a patch for mnoGoSearch 3.1.9). I'm
not really proficient in C, but as far as I can see, this patch fixes the
problem. (In short: UdmFILEGet() in proto.c now uses "openname" [the
unescaped form of the current directory] instead of "filename" [the escaped
form] when putting together the directory name and the entries it reads from
it. This prevents it from mistakenly recognizing file entries as
(sub-)directory entries. I can elaborate on this fix if anybody is
interested.)

Hope this helps. And yes, I like mnoGoSearch. Nice thing.

Regards,
Kaspar



__
If you want to unsubscribe send "unsubscribe udmsearch"
to [EMAIL PROTECTED]

UdmSearch: file: URL indexing bug in mnoGoSearch 3.1.9 / udmSearch 3.0.23 - here is the patch

2001-01-28 Thread Kaspar Brand 

Hi,

sorry, I forgot to attach the patch in my previous message. Here it is.

Regards,
Kaspar

 mnogosearch-3.1.9-FILEGet.patch