forgot to mention:
This applies to building SRC680_m26 branch, though I don't think that the source
version makes any difference here ...

@fs: Thanks for the debugging :-) I'll produce a fix this evening.

Oops, I meant 1.1.2.

New title to reflect the problem.

First: This is a W32-4nt problem ;-)

The problem is that somewhere between findutils 4.1-? and 4.1.7-4 find lost
the ability to use/evaluate paths with backslashes.

I see at least four possibilities to fix this:

1. Require find from 4.1-?

2. put $(subst,\,/ data) in every makefile that uses $(FIND)

3. write a wrapper for find that transforms the arguments and calls find
   for USE_SHELL=4nt. 

4. write a generic DOS->POSIX wrapper and define FIND like:
   FIND=$(UNWRAPCMD) $(FIND) in winenv.bat

vq->ause: I'd propose 3. if you agree I'll produce a small perl script.

I guess this qualifies as P2.

mere interest: Is there a general rule how cygwin tools should handle
backslashes when *not* called from within a cygwin shell?
IIRC, some tools accept backslashes, and some don't, which is somewhat
inconsistent, isn't it?

up to now, all cygwin tools that i evaluated treated the "\" as part of the
filename. this caused problems when using wildcards but worked fine for most
operations.
if this is a general shift, we might even require some kind of general wrapper
for cygwin tools used in a 4nt environment.
if it's just a problem of "find", we might just wrap this one.
hjs->vq: could you check if the most common commands (cp, mv, cat, touch) still do?

OK, something is strange here, I just updated all my cygwin packages
to the latest and greatest and did some tests.

In bash:
--- bash ---
quetschke@Baltasar /home
$ find ../tmp -name *.test
../tmp/ooo.test

quetschke@Baltasar /home
$ find ..\\tmp -name *.test
..\tmp/ooo.test

quetschke@Baltasar /home
$ find c:\\cygwin\\tmp -name *.test
c:\cygwin\tmp/ooo.test

quetschke@Baltasar /home
$ find c:/cygwin/tmp -name *.test
c:/cygwin/tmp/ooo.test
--- bash ---

In cmd.exe:

--- cmd.exe ---
C:\cygwin\home>c:\cygwin\bin\find ..\tmp -name *.test
..\tmp/ooo.test

C:\cygwin\home>c:\cygwin\bin\find ../tmp -name *.test
../tmp/ooo.test
--- cmd.exe ---

Hmmm, I don't see a problem here. I guess there was always the output
of mixed '\' and '/' when you use DOS notation.

vq->fs: Can you check the file attributes?

2nd try, I thought that com is maybe a reserved name, in cmd.exe:

C:\cygwin\home>c:\cygwin\bin\find ..\com\sun\star -name *.test
..\com\sun\star/ooo.test

Got it!

My d: drive is FAT32, there I get:

D:\home>c:\cygwin\bin\find ../com/sun/star -name *.test
../com/sun/star/ooo.test

D:\home>c:\cygwin\bin\find ..\com\sun\star -name *.test
/usr/bin/find: ..\com\sun\star changed during execution of /usr/bin/find

ause or fs, can anyone of you please check if it works with network drives?

I'll post this problem to the cygwin list later.

I'm puzzled when this problem was introduced, the findutils package changed
in 2002 to 4.1.7-4, but maybe nobody ever tried to build OOo on FAT.

Actually if one builds with the TEMP var pointing to a directory on a FAT
drive I know (there is an issue somewhere) that you cannot do rebuilds,
because the flagfiles (can) have filedates that are off by one second.

For now, I'd say: Don't use FAT drives at all.

> My d: drive is FAT32
strange indeed! Kudos for finding this :)

> ause or fs, can anyone of you please check if it works with network drives?
I won't have access to a machine with both cygwin and network access before thursday

> I'm puzzled when this problem was introduced, the findutils package changed
> in 2002 to 4.1.7-4, but maybe nobody ever tried to build OOo on FAT.

May "working" cygwin installation may indeed be older than this, I originally
used it to build Mozilla quite some time ago.

> For now, I'd say: Don't use FAT drives at all.

Okay, that's ugly, since it may require me to migrate a 30GB partition to NTFS
(which it should be nowadays), but if that saves me trouble, I may do so.

did some tests here too. find (4.1.7-4) fails on FAT32 and network volumes if
the searchdirectory contains backslashes AND begins with "..". a directory below
the current location works fine.

> Okay, that's ugly, since it may require me to migrate a 30GB partition
> to NTFS (which it should be nowadays), but if that saves me trouble,
> I may do so.
Well, you can use the old find, or I can send you a patched find from
the findutils 4.1.7-4 sources, it would disable the inode comparison
for the top directory entry.

I hope that I get aswers in the cygwin mailing list and that this is
fixable without disabling this check.

Amazingly enough that there is an inode emulation!

The good news is I pinpointed the problem in the cygwin1.dll, see:
<http://cygwin.com/ml/cygwin/2004-03/msg01210.html>.

The bad news is that some people think the problem is not
worth to fix, quote: "speed disadvantage for nebulous gain."

Maybe a good diplomat is needed. Is Joerg around ;-)

Uh. Looks like they're very reluctant, indeed. Can we convince them with
"OpenOffice.org is not going to use cygwin anymore!!!!1" ? :) Or, more
diplomatic: Fixing this would allow using cygwin in heterogenous environments,
where cygwin tools and other command line tools (now knowing about slashes) are
mixed. Just an idea.

Some lobbying might help ;-) Pointing out that there are "real-world"
applications that currently fail might also help, but saying that you
get this problem when you mix cygwin and 4nt might not help :-)

Just FYI, the needed fix is already in cvs.

cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/src diff -u -r1.289 -r1.290
src/winsup/cygwin/path.cc

vq wonders: Manche Leute muss ich nicht verstehen ....

Actually I am  around ;-)

But seeing that there already is a fix in Cygwin cvs, I think there is not much
more we need to (or can) do.

I propose that we close this issue as WONTFIX. In the build documentation we
should tell people that a certain (range of) findutil version(s) don't work. IOW
they should go back to older working findutils until the mentioned patch is
released.

Probably we should not actually CLOSE the issue until the cygwin patch is
available and we have verified that it actually solves our problem.

Hmm, I just wanted to try this lobbying ... (not with Jörg's eloquence :), but
who knows what it's good for).

Okay, I'll happily close this as <whatever> (I suppose WONTFIX comes closest).
Volker, do you mind adding an "Important note 9" to
http://tools.openoffice.org/dev_docs/build_windows.html#BuildRequirements?

Yes, we can resolve the issue. In general I'm not that happy with the WONTFIX
state. If a user runs into this problem and sees a WONTFIX, that might lead
him to the impression that this is an unfixable problem.

If we resolve as FIXED, even if "we" didn't fix it, but external resources,
this comes closer IMHO to the fact that now there exists a solution for
this problem.

Opinions?

And, yes I'll update the build instructions after a cygwin 1.5.10 is released.
(It is due this week, I don't want to confuse the people even more with
something like they have to get very old findutils and manually install it
to .. )

I'm fine with FIXED, when 1.5.10 is out.

so, is that correct That this also affecting 1.1.1 & Other windows version ? 
and the work around is ? 
edit the makefile.mk at  rvpapi/java/makefile.mk
Replace $/ with $\

or wait for cygwin 1.5.10

Thanks

Created attachment 14398 [details]
find.exe 4.1, from an older cygwin package

set target to 1.1.3

D:\>c:\cygwin\bin\find.exe .\tmp -name *.test
.\tmp/file.test

OK, works in cygwin 1.5.10.

close