sfFinder cannot do relative searches on at least Windoze.
Whenever you regularize directory names, then all directory names end
with DIRECTORY_SEPARATOR. Then, in search_in() the stripping of
directories fails:
In this case, $dir already ends with DIRECTORY_SEPARATOR, so the
str_replace ALWAYS fails since $dir.DIRECTORY_SEPARATOR produces two
concatenated DIRECTORY_SEPARATORs. So, I simply removed the
catenation of DIRECTORY_SEPARATOR. The REAL solution is to either
make sure the $dir string ahs no terminating DIRECTORY_SEPARATOR or
else that you specifically remove it.
On Tue, Apr 1, 2008 at 12:31 AM, Joe Kelsey <nn7...@gmail.com> wrote:
> sfFinder cannot do relative searches on at least Windoze.
> Whenever you regularize directory names, then all directory names end > with DIRECTORY_SEPARATOR. Then, in search_in() the stripping of > directories fails:
> In this case, $dir already ends with DIRECTORY_SEPARATOR, so the > str_replace ALWAYS fails since $dir.DIRECTORY_SEPARATOR produces two > concatenated DIRECTORY_SEPARATORs. So, I simply removed the > catenation of DIRECTORY_SEPARATOR. The REAL solution is to either > make sure the $dir string ahs no terminating DIRECTORY_SEPARATOR or > else that you specifically remove it.
Many thanks for your "fix", i didn't have your bug on Windows, and
since you "fixed" it nothing works on my project... Now I must use a "-
r 8190" in my svn:externals so that my project can work...
Please *test* before making commits to the trunk, this is *very*
annoying to have such an unexpected bug : I lost only one hour before
I understood who was guilty (you) but I could have lost *very* more
time.
Please check again your patch, because this is not working at all. As
a proof, please look at this :
Note : between 8190 & 8288, there are only noel's commits ><
Note2 : there is nothing special in my admin generators, nor in my
config, and before your "fixes" it worked perfecly on Windows & Linux
(on 5 different machines to tell everything).
On 4 avr, 11:17, "noel guilbert" <noelguilb...@gmail.com> wrote:
> On Tue, Apr 1, 2008 at 12:31 AM, Joe Kelsey <nn7...@gmail.com> wrote:
> > sfFinder cannot do relative searches on at least Windoze.
> > Whenever you regularize directory names, then all directory names end
> > with DIRECTORY_SEPARATOR. Then, in search_in() the stripping of
> > directories fails:
> > In this case, $dir already ends with DIRECTORY_SEPARATOR, so the
> > str_replace ALWAYS fails since $dir.DIRECTORY_SEPARATOR produces two
> > concatenated DIRECTORY_SEPARATORs. So, I simply removed the
> > catenation of DIRECTORY_SEPARATOR. The REAL solution is to either
> > make sure the $dir string ahs no terminating DIRECTORY_SEPARATOR or
> > else that you specifically remove it.
I'm really sorry for the annoyance, and I've reverted this change to the revision r7757.
Be sure, I've tested this patch before commit it, and I haven't see any bugs in my environnement. And promise, I'll test my futures patches two, three, or even ten times if it's needed.
And again, excuse me.
On Fri, Apr 4, 2008 at 4:32 PM, nchambr...@mtpi.fr <nchambr...@mtpi.fr> wrote:
> Many thanks for your "fix", i didn't have your bug on Windows, and > since you "fixed" it nothing works on my project... Now I must use a "- > r 8190" in my svn:externals so that my project can work... > Please *test* before making commits to the trunk, this is *very* > annoying to have such an unexpected bug : I lost only one hour before > I understood who was guilty (you) but I could have lost *very* more > time.
> Please check again your patch, because this is not working at all. As > a proof, please look at this :
> Note : between 8190 & 8288, there are only noel's commits >< > Note2 : there is nothing special in my admin generators, nor in my > config, and before your "fixes" it worked perfecly on Windows & Linux > (on 5 different machines to tell everything).
> > On Tue, Apr 1, 2008 at 12:31 AM, Joe Kelsey <nn7...@gmail.com> wrote:
> > > sfFinder cannot do relative searches on at least Windoze.
> > > Whenever you regularize directory names, then all directory names end > > > with DIRECTORY_SEPARATOR. Then, in search_in() the stripping of > > > directories fails:
> > > In this case, $dir already ends with DIRECTORY_SEPARATOR, so the > > > str_replace ALWAYS fails since $dir.DIRECTORY_SEPARATOR produces two > > > concatenated DIRECTORY_SEPARATORs. So, I simply removed the > > > catenation of DIRECTORY_SEPARATOR. The REAL solution is to either > > > make sure the $dir string ahs no terminating DIRECTORY_SEPARATOR or > > > else that you specifically remove it.
When i read again my message, this is very rude. Not very adapted for
an free open-source project.
If you need help on correcting your patch, I can send more info on my
crash, what do you need most ?
On 4 avr, 17:11, "noel guilbert" <noelguilb...@gmail.com> wrote:
> I'm really sorry for the annoyance, and I've reverted this change to the
> revision r7757.
> Be sure, I've tested this patch before commit it, and I haven't see any bugs
> in my environnement. And promise, I'll test my futures patches two, three,
> or even ten times if it's needed.
> And again, excuse me.
> On Fri, Apr 4, 2008 at 4:32 PM, nchambr...@mtpi.fr <nchambr...@mtpi.fr>
> wrote:
> > Many thanks for your "fix", i didn't have your bug on Windows, and
> > since you "fixed" it nothing works on my project... Now I must use a "-
> > r 8190" in my svn:externals so that my project can work...
> > Please *test* before making commits to the trunk, this is *very*
> > annoying to have such an unexpected bug : I lost only one hour before
> > I understood who was guilty (you) but I could have lost *very* more
> > time.
> > Please check again your patch, because this is not working at all. As
> > a proof, please look at this :
> > Note : between 8190 & 8288, there are only noel's commits ><
> > Note2 : there is nothing special in my admin generators, nor in my
> > config, and before your "fixes" it worked perfecly on Windows & Linux
> > (on 5 different machines to tell everything).
> > > On Tue, Apr 1, 2008 at 12:31 AM, Joe Kelsey <nn7...@gmail.com> wrote:
> > > > sfFinder cannot do relative searches on at least Windoze.
> > > > Whenever you regularize directory names, then all directory names end
> > > > with DIRECTORY_SEPARATOR. Then, in search_in() the stripping of
> > > > directories fails:
> > > > In this case, $dir already ends with DIRECTORY_SEPARATOR, so the
> > > > str_replace ALWAYS fails since $dir.DIRECTORY_SEPARATOR produces two
> > > > concatenated DIRECTORY_SEPARATORs. So, I simply removed the
> > > > catenation of DIRECTORY_SEPARATOR. The REAL solution is to either
> > > > make sure the $dir string ahs no terminating DIRECTORY_SEPARATOR or
> > > > else that you specifically remove it.
On Fri, Apr 4, 2008 at 5:16 PM, nchambr...@mtpi.fr <nchambr...@mtpi.fr> wrote:
> When i read again my message, this is very rude. Not very adapted for > an free open-source project.
Yes, but you was right, as long as symfony will be a "professional framework", we can't break it. So we have to test it again an again to be sure it's still working.
> If you need help on correcting your patch, I can send more info on my > crash, what do you need most ?
What's your php version? Which apache/php distribution do you use?
> > I'm really sorry for the annoyance, and I've reverted this change to the > > revision r7757.
> > Be sure, I've tested this patch before commit it, and I haven't see any > bugs > > in my environnement. And promise, I'll test my futures patches two, > three, > > or even ten times if it's needed.
> > And again, excuse me.
> > On Fri, Apr 4, 2008 at 4:32 PM, nchambr...@mtpi.fr <nchambr...@mtpi.fr> > > wrote:
> > > Many thanks for your "fix", i didn't have your bug on Windows, and > > > since you "fixed" it nothing works on my project... Now I must use a > "- > > > r 8190" in my svn:externals so that my project can work... > > > Please *test* before making commits to the trunk, this is *very* > > > annoying to have such an unexpected bug : I lost only one hour before > > > I understood who was guilty (you) but I could have lost *very* more > > > time.
> > > Please check again your patch, because this is not working at all. As > > > a proof, please look at this :
> > > Note : between 8190 & 8288, there are only noel's commits >< > > > Note2 : there is nothing special in my admin generators, nor in my > > > config, and before your "fixes" it worked perfecly on Windows & Linux > > > (on 5 different machines to tell everything).
> > > > On Tue, Apr 1, 2008 at 12:31 AM, Joe Kelsey <nn7...@gmail.com> > wrote:
> > > > > sfFinder cannot do relative searches on at least Windoze.
> > > > > Whenever you regularize directory names, then all directory names > end > > > > > with DIRECTORY_SEPARATOR. Then, in search_in() the stripping of > > > > > directories fails:
> > > > > In this case, $dir already ends with DIRECTORY_SEPARATOR, so the > > > > > str_replace ALWAYS fails since $dir.DIRECTORY_SEPARATOR produces > two > > > > > concatenated DIRECTORY_SEPARATORs. So, I simply removed the > > > > > catenation of DIRECTORY_SEPARATOR. The REAL solution is to either > > > > > make sure the $dir string ahs no terminating DIRECTORY_SEPARATOR > or > > > > > else that you specifically remove it.
This is really very confusing. Your proposed "fix" does not seem to
address the given problem. You need to explore the system and find
out exactly why the $dir always (or only sometimes) has
DIRECTORY_SEPARATOR appended to its value and exactly when you should
either append or not append it. Is there some difference in the
windoze versus linux directory calls? Your fix completely throws away
the DIRECTORY_SEPARATOR usage and uses just '/' and '\\', which seems
wrong.
> On Tue, Apr 1, 2008 at 12:31 AM, Joe Kelsey <nn7...@gmail.com> wrote:
> > sfFinder cannot do relative searches on at least Windoze.
> > Whenever you regularize directory names, then all directory names end
> > with DIRECTORY_SEPARATOR. Then, in search_in() the stripping of
> > directories fails:
> > In this case, $dir already ends with DIRECTORY_SEPARATOR, so the
> > str_replace ALWAYS fails since $dir.DIRECTORY_SEPARATOR produces two
> > concatenated DIRECTORY_SEPARATORs. So, I simply removed the
> > catenation of DIRECTORY_SEPARATOR. The REAL solution is to either
> > make sure the $dir string ahs no terminating DIRECTORY_SEPARATOR or
> > else that you specifically remove it.