Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Delete command sets directory attributes to hidden & system

_HS_D________ F:\Data\temp\Andrew

If it is that simple to reproduce, why not try running Process Monitor as I suggested some days ago? If you filter on just this exact folder name it will record all filesystem operations on the folder. You can then see if Rex is right and all the API calls by TCC are identical. If so, and if no other process touches the folder itself, then you will have proved it is a Windows bug. And if you see a 'set attributes' call by some other process, you will have found the culprit. Process Monitor can be daunting if you let it rip on everything, but with a single specific target it will just show you what touches that target.
 
Hello,

I am sorry to revive this old thread from the dead, but has this ever been solved?

This was one of the first problems with TCMD12 that I noticed after my transition from 4NT8, but I decided I could live with it. (I included code to remove all unwanted attributes into my disk cleanup btm)

After reading through this thread, I created a btm file to reproduce the problem. In case anyone is still interested, see the contents of the attached zip file:

TestDA.btm is the batch. It will work on a directory %temp\TDA, which it will delete first, so be careful. It does accept one argument, a name for a file which keeps directories from being deleted.

I ran it once as TestDA.btm aaa.file > TestDA_aaa.log

This shows the directory attributes change starting at 17:41:05

The output of Procmon is in file Logfile.CSV. Interesting entry is at timestamp 17:41:05.0925476:

"17:41:05.0925476","tcc.exe","2800","SetBasicInformationFile","F:\Temp\TDA\AH","SUCCESS","CreationTime: 1601-01-01 02:00:00, LastAccessTime: 1601-01-01 02:00:00, LastWriteTime: 1601-01-01 02:00:00, ChangeTime: 1601-01-01 02:00:00, FileAttributes: HAN"

I ran the btm also as TestDA.btm zzz.file > TestDA_zzz.log

The log file is included, it shows that the directory attributes are not changed. So it looks like the attributes of the last file in the directory are transferred to the directory itself, when a del /x is executed.

And before I forget, my system is "TCC 12.11.70, Windows XP SP3"

Hope this helps

Ulrich
 

Attachments

  • TestDA.zip
    71.2 KB · Views: 204
>This is a known Windows bug.

I'm not going to deny this (although I wasn't aware there was a delete API call that can handle all the complexity of the command we are using) but I'm afraid that if you set yourself up as a utility provider, you have to work around bugs in the operating system, annoying as they are.

Something MUST have changed between Take Command v8 and the current version as one works and the other does not.
Cheers, Rob.

That is not the only possiblity.
You could easily have some malware or rootkit that is messing around Hidden & System attributes of directories and some funny interaction between TC8 and the later version (the malware might activate itself on the basis of registry changes).

The fact that TC8 "works" and the later TC "does not work" proves nothing.
Also, as a software developer, I have seen enough very strange behaviour over the years to conclude that "A works, B does not work => that there is something wrong with B" is oversimplistic and often wrong.

Cheers

Stephen Howe
 
Here see

http://www.pcmech.com/forum/network...d-all-files-folders-hidden-system-solved.html

Quote:
Here's a new one. I cleaned this WinXP computer of a virus by slaving it to a clean computer and running 3 different scans. I notice by the color of the folders that all the folders are Hidden. It appears that the virus changed the atributes of all the files and folders on drive C: to be HIDDEN SYSTEM files!

Could be something similar.

Cheers

Stephen Howe
 
TestDA.btm is the batch. It will work on a directory %temp\TDA, which it will delete first, so be careful. It does accept one argument, a name for a file which keeps directories from being deleted.

I ran it once as TestDA.btm aaa.file > TestDA_aaa.log

When I run it, TDA does not have the hidden or system attributes when it finishes.
 
When I run it, TDA does not have the hidden or system attributes when it finishes.

Yes, same here, if you only look after the batch is finished. But while it runs, in my example after the first "del /x" at 17:41:05, the directories AH, AHS, AS, H, HS and S get the according attributes. At the very end, everything is back to normal directory attributes. Does your setup behave differently?

I changed my batch file to stop after the first "del /x". Things changed differently than I expected: Now only the directory S gets the S attribute, the others do not change.

I do not know what is going on, but I am pretty sure the problem is with TCMD 12. With 4NT 8, which I used before, this never happened

Ulrich
 
Yes, same here, if you only look after the batch is finished. But while it runs, in my example after the first "del /x" at 17:41:05, the directories AH, AHS, AS, H, HS and S get the according attributes. At the very end, everything is back to normal directory attributes. Does your setup behave differently?

If you have a test case that I can just run, I'll try it.
 
That is not the only possiblity.
You could easily have some malware or rootkit that is messing around Hidden & System attributes of directories and some funny interaction between TC8 and the later version (the malware might activate itself on the basis of registry changes).

The fact that TC8 "works" and the later TC "does not work" proves nothing.
Also, as a software developer, I have seen enough very strange behaviour over the years to conclude that "A works, B does not work => that there is something wrong with B" is oversimplistic and often wrong.

Cheers

Stephen Howe

Simplistic but I'm will to put money on the issue requires a change in TC rather than our entire infrastructure infected with some malware or virus that is only effecting the TC delete command.

I'm not going to say it's a bug in TC as it could have been caused by some breaking change in Windows that means that later versions of of TC behave in this way.

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".

Cheers, Rob.
 
> 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
 
I don't understand why you keep putting the blame on TC when the problem was reported over 5 years ago and in a situation where TC wasn't even being used.

Simplistic but I'm will to put money on the issue requires a change in TC rather than our entire infrastructure infected with some malware or virus that is only effecting the TC delete command.

I'm not going to say it's a bug in TC as it could have been caused by some breaking change in Windows that means that later versions of of TC behave in this way.

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".

For a refresher, please check the links I posted in March.

 
Still not reproducible here, which isn't surprising -- there is absolutely,
positively, NO code in DEL to set those attributes. I think you're looking
in the wrong place.

Well, if you say that what happened between 17:41:05.0925476 and 17:41:05.0932653 (according to my Procmon log file) has nothing to do with the hidden and archive attributes on the directory AH, then I will just have to believe you.

Ulrich
 
> Well, if you say that what happened between 17:41:05.0925476 and
> 17:41:05.0932653 (according to my Procmon log file) has nothing to
> do with the hidden and archive attributes on the directory AH, then
> I will just have to believe you.

I'm not saying that *something* isn't setting attributes on your system; I'm
just saying that it isn't TCC.

I went through your batch file and log and compared it to the TCC source
code, and I can only see one place where this could be happening (inside a
Windows shell API).

I've built a test version (12.11.72) that replaces that API call with a
different one. I uploaded the test version to the ftp site; download and
install this build and see if you can still reproduce the problem. (If not,
you've either got a Windows bug, a mangled shell, or some third party
intercepting that API.)

ftp://jpsoft.com/beta/tcmd.exe
ftp://jpsoft.com/beta/tcmdx64.exe

Rex Conn
JP Software
 
I've built a test version (12.11.72) that replaces that API call with a
different one. I uploaded the test version to the ftp site; download and
install this build and see if you can still reproduce the problem. (If not,
you've either got a Windows bug, a mangled shell, or some third party
intercepting that API.)

Thanks, that sure fixes the problem. No more crazy directory attributes! I think I will keep that version.

How can I decide which of the three possible reasons for the behavior I have? I plan to install a virtual machine with just Windows and the two different TCMD versions. That should at least rule out the 'third party' problem.

Thanks again

Ulrich
 
Simplistic but I'm will to put money on the issue requires a change in TC rather than our entire infrastructure infected with some malware or virus that is only effecting the TC delete command.
Cheers, Rob.

Yes but I posted another link which showed some recent Malware that did change the attributes of a directory. So you can't rule it out. I would check your PCs with various virus scanners, spyware scanners and rootkit scanners.

Stephen Howe
 
I plan to install a virtual machine with just Windows and the two different TCMD versions. That should at least rule out the 'third party' problem.

Done. Installed WindowsXP in Virtualbox. Tried to install TCMD12, it does not like SP1. Installed SP3, installed TCMD12.11.71. Tried my testcase, problem is there.

Installed TCMD12.11.72, problem is gone.

Installed 4NT8.02, tried my testcase, problem does not exist.
 

Similar threads

Back
Top