> But no matter what the cause is, only jpsoftware can realistically fix
this. Can
> you imagine approaching Microsoft with a support call that goes "We've got
a
> problem with a 3rd party tool that worked in earlier versions of their
> software but not in the later versions?". I suspect the response will be
> "Contact the vendor".
As I've said, there are three problems here:
1) I cannot reproduce it (tried it on 5 systems and three different versions
of Windows).
2) Nobody else can reproduce it either.
3) There is absolutely, positively, NO code in DEL that is changing
directory attributes. This isn't a matter for debate; it is a fact.
The only possible explanation I can think of is a Windows API problem on
your systems. Either something in Windows itself, or more likely (since
nobody else has had any success in reproducing this) something that is
injecting code into the Windows shell (or TCC), or hooking the APIs. Not
necessarily a virus; there are a number of apps (antivirus, shell managers,
etc.) that do this (though TCC is *not* one of them).
If you are not deleting to the recycle bin, TCC calls the Windows
DeleteFile API, and then calls the shell SHChangeNotify API (which is
required to alert the Windows shell that something changed).
If you are deleting to the recycle bin, TCC calls the shell SHFileOperation
API.
(If you are specifying a delete at the next reboot, TCC calls MoveFileEx,
but that doesn't seem to be the case in your example.)
The thing is -- those shell calls haven't changed since 4NT 8 (which kind of
shoots holes in the "Windows itself" theory).
Rex Conn
JP Software