Stefan Küng wrote:
> Robert Roessler wrote:
>
>> To quote someone who is well-known around here, "Look again"... :)
>
> Ok, lets:
>
> if (I->at(I->size()-1)=='*')
> {
> stdstring str = I->substr(0, I->size()-1);
> if (_tcsnicmp(str.c_str(), path, str.size())==0)
> return TRUE;
> if (str.size() && (str.at(str.size()-1) == '\\') &&
> (_tcsnicmp(str.c_str(), path, str.size()-1)==0))
> return TRUE;
> }
> else if (_tcsicmp(I->c_str(), path)==0)
> return TRUE;
> else if (I->size() && (I->at(I->size()-1) == '\\') &&
> (_tcsnicmp(I->c_str(), path, I->size()-1)==0))
> return TRUE;
>
>
>> AFAICT (and it's not *my* code), the compare at line 274 is exactly
>> equivalent to the compare at line 269 (part of the referred-to "if
>> complex" at line 264) - for Include patterns path\* and path\ .
>>
>> Once the prefix substring str has been pulled from the front of the
>> particular Include entry, it no longer contains the trailing * ...
>> which makes the 'n' compares at line 269 and line 274 equivalent.
>
> But you're forgetting that we're comparing against the paths we get e.g.
> from the shell.
I am not sure where you are going with this "reminder"...
> Example:
>
> path = "c:\usr\Test\file" // the path we're asked to check
> *I = "c:\usr\Test*" // line in the include paths
>
> First check (str is now "c:\usr\Test"):
> if (_tcsnicmp(str.c_str(), path, str.size())==0)
>
> This compares:
> "c:\usr\Test" against "c:\usr\Test", because only the first 11 chars are
> compared. And it evaluates to 'equal'. Which means: even if 'path' is
> much longer than the string in your include path, as long as the first
> part of the string matches, it's 'equal'.
>
> Second check (if no * is at the end of the include path):
> if (_tcsicmp(I->c_str(), path)==0)
>
> this will evaluate to 'not equal' since 'path' is longer than *I (the
> include path).
BUT, in the case I keep raising (path\ vs path\*), with an Include entry
of path\, the VERY NEXT compare, which WILL BE EXECUTED (since the prior
compare fails as you point out), results in 'equal'...!
AND, THIS compare (the final if in your snippet of code above) is
fundamentally incorrect... consider what it will do with an Include
entry of path\ and checked paths of pathA, pathAA, pathAAA, etc.
It will behave EXACTLY like path*, which it should NOT.
BTW, this could likely be fixed by changing the LAST "I->size()-1" in
your snippet to "I->size()"... although this fix MIGHT finally cause the
infamous path\ to not be equivalent to path\*, depending on whether
folder paths always have a trailing \ or not. ;)
>> Finally, given the difficulties with documenting and/or implementing
>> TSVNCache's current approach to Include/Exclude logic, perhaps
>> Apache's solution might be of interest: allow the user to supply the
>> test ordering semantics vis-a-vis the Order directive from htaccess
>> files?
>
> Given the fact that a normal user doesn't understand such an ordering, I
> think we should keep it that way.
Obviously a judgment call, and it is not my app, but clearly the
Apache-style semantic specification for specifying inclusion/exclusion
is more powerful (and complete) - but you are likely correct in
rejecting it because of the overkill factor. ;)
> And given the fact that with your help ( :) ) I realized that
> programming is harder than it looks, I'm going to ask my boss for a
> raise :)
Glad I could help - it *is* harder than it looks. :)
Which brings me to my final (for now) point: the TSVNCache executable
from rev 11400 DOES NOT WORK PROPERLY (on my XP SP2 system with NTFS).
In particular, the Include paths are absolutely not processed... it does
not matter WHAT I put in for the Include (or Exclude, for that matter)
list: *, x:\usr\Play\, random garbage - ALL that controls whether I get
a FALSE out of ShellCache::IsPathAllowed() is the Drive Type.
Further "proof" of this is supplied by the "Show excluded folders as
'normal'" setting: when all Drive Type boxes are unchecked, and this box
is CHECKED, all of my WC folders get the "unmodified" overlay.
This is direct observation of reality, BTW, not based on building and
instrumenting the code for the TSVNCache executable - while I would very
much like to do this, I am not sure I would live long enough to get all
the prerequisites installed, and I already have VS 2005... :)
Robert Roessler
robertr@rftp.com
http://www.rftp.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Thu Nov 22 04:38:57 2007