On Fri, 21 Jan 2005 08:48:44 +0000, Will Dean <firstname.lastname@example.org> wrote:
> There is a completely opposite way around which is to use the OS to tell us
> when something changes, then update the cache and tell the shell that it's
> changed. This seems like it would be better, but there are several
> problems with this:
> 1. I don't think that the FindFirstChangeBlahBlah functions are suitable
> for tracking a very large number of directories.
They're not. Try it once with a small test program on drive c:\ and
> 2. The shell itself uses FindFirstChangeBlahBlah to track items in
> currently-displayed folders. (This is how it knows to ask for new status
> when the text of a file changes.) If we were doing exactly the same
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. 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. 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
> 3. There are NTFS change journal notification techniqes which might be
> better than the FindFirstxxx functions, but they'd still suffer from the
> problem in '2', and they won't work on non NTFS drives.
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.
And of course they won't work on network drives.
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.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri Jan 21 10:24:45 2005