Will Dean wrote:
> At 10:24 21/01/2005 +0100, you wrote:
>
>> I don't think that's true. If it would use that API, every filechange
>> would result in an immediate change in the explorer view. But that's
>> not the case.
>
>
> Raymond Chen says that's how it works...
>
>> If the program changing the files
>> (adding/removing/modifying them) doesn't notify the shell about the
>> change, explorer sometimes takes several seconds until the view
>> matches the filesystem again.
>
>
> Yes, but I *think* that's to do with how it aggregates change requests,
> not how it detects the changes.
>
>> I can see that especially when building
>> the language packs while the exploerer shows the /bin folder.
>> What it really does it to check every few seconds the whole folder
>> which is visible in the explorer and then refreshes the view if
>> necessary.
>
>
> It's probably relatively easy to settle this with WinDBG and filemon,
> but I certainly don't think it polls the visible files for their dates.
>
>> Those NTFS journals aren't 'life', i.e. they can't be used to monitor
>> changes in realtime. They're made for backup programs, synchronizers
>> an the like.
>
>
> OK, I hadn't looked at them in detail, but I wasn't terribly keen on the
> idea.
>
>> And of course they won't work on network drives.
>
>
> No, I don't think they're a great idea.
>
>> Even though this looks brilliant, I think we still need a small cache
>> in the shell extension part too. Otherwise we have to make too many
>> IPC calls. I'm guessing we keep the 'one file' cache shared between
>> all overlay handlers, and maybe the SVNAdminDir cache.
>
>
> I agree with you about the 'one file' cache, though it needs to have a
> very short lifetime to stop it becoming stale. I have currently
> implemented this on the front of my cache, but as you say, that's the
> wrong side of the IPC, really (though I ought to benchmark the
> named-pipe RTT to see if it's a big deal).
Also, if named pipe performance is a problem, you could use
an alternative IPC mechanism, such as a shared memory section,
either for the whole cache, or just for this small part.
I quite confident that shared memory would be fast enough :-)
Thanks,
Joseph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Fri Jan 21 15:47:43 2005