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

This is a VERY weird problem. We have a Take Command batch file which at it's heart executes this command:

del /[d-30,1-1-80] /s /x /z /y /e /k s:\temp > "%Logfile"

What this command does is effectively delete files & folders over 30 days old. S:\Temp is a temporary location on our network and people know that files get deleted after 30 days.

We have recently migrated the server hosting the S: drive from Windows 2003 to Windows 2008.

Since then, user's have reported that their folder in S:\Temp (e.g. S:\Temp\Alex) has deleted before it should have, i.e. their swore blind that they had saved a file in there yesterday and it had gone today.

We suspected user error until we happen to notice that S:\Temp\Alex hadn't actually been deleted but had ended up with the hidden and system attributes set.

As I test, I've just restored S:\Temp from last weekends backup and S:\Temp\Alex is there.

Run the above command and bizarrely the S:\Temp\Alex folder gains the hidden & system attributes.

What is also perplexing is that right now, the delete command doesn't actually delete anything from S:\Temp\Alex (it does from other sub-folders) so it's doubly perplexing why the attributes are being changed.

Cheers, Rob.

TCC 11.00.44 Windows 2003 [Version 5.2.3790]
 
---- Original Message ----
From: rob.nicholson

| This is a VERY weird problem. We have a Take Command batch file which
| at it's heart executes this command:
|
| del /[d-30,1-1-80] /s /x /z /y /e /k s:\temp > "%Logfile"
|
| What this command does is effectively delete files & folders over 30
| days old. S:\Temp is a temporary location on our network and people
| know that files get deleted after 30 days.
...
Most likely problem: in the instance of TCC which executes it DEL is an alias.

BTW, you can specify a "negated range" with the aid of the exclamation mark ! thus:
/![d-29] - all files created more than 29 days ago (i.e., 30 days old or older).

--
Steve
 
Run the above command and bizarrely the S:\Temp\Alex folder gains the hidden & system attributes.
[Version 5.2.3790]

There isn't any code in the DEL command to change the hidden & system attributes. (There is one line that will turn off the read-only attribute if the first attempt to delete the directory fails.)

The actual file & directory deletions are all done with Windows APIs.

There are several possibilities here:

1) There's an alias interfering with your desired operation.

2) There's a plugin interfering with your desired operation.

3) Windows on the target machine has gotten mangled somehow.

4) TCC on the target machine has gotten mangled somehow.

5) There's a third-party app that is interfering with your desired operation.

Is this only happening in one directory?
 
>There's an alias interfering with your desired operation.

No, nothing there.

>There's a plugin interfering with your desired operation.

What kind of plugin?

>Windows on the target machine has gotten mangled somehow.

Doubt it... this is our main file server.

But what I will do is robocopy the folder to another server and try the same thing there.

>TCC on the target machine has gotten mangled somehow.

Possibly, will try re-installing later.

>There's a third-party app that is interfering with your desired operation.

File server is pretty basic Windows 2008 R2 x64 server.

>Is this only happening in one directory?

Actually, no - it occurs on several but not all of the sub-folders. I'll post some screenshots shortly.

Cheers, Rob.
 
Okay later... no plugins are installed. Here is the state of the directory before the delete command:

Code:
[S:\Temp]attrib /a:d
____D________  S:\Temp\.settings
____D_______I  S:\Temp\Alex
____D_______I  S:\Temp\Andrew
____D________  S:\Temp\bin-debug
____D_______I  S:\Temp\Christine
____D_______I  S:\Temp\Claire
____D________  S:\Temp\DJG
____D________  S:\Temp\Ewen
____D________  S:\Temp\EXBACK
____D_______I  S:\Temp\George
____D________  S:\Temp\GL
____D________  S:\Temp\Helen
____D________  S:\Temp\html-template
____D________  S:\Temp\Infusion
____D________  S:\Temp\Jo
____D________  S:\Temp\Jo 2
____D________  S:\Temp\Karen
____D_______I  S:\Temp\KerryA
____D________  S:\Temp\libs
____D_______I  S:\Temp\Liza
____D________  S:\Temp\Logon
____D________  S:\Temp\Lorna
____D________  S:\Temp\Lucy
____D________  S:\Temp\Mark H South America 2011
____D________  S:\Temp\michelle
____D________  S:\Temp\MMPC
____D________  S:\Temp\Nycomed
____D________  S:\Temp\PC141
____D________  S:\Temp\QXV site images
____D_______I  S:\Temp\Raf
____D________  S:\Temp\Raf2
____D________  S:\Temp\Repl
____D________  S:\Temp\Rich G
____D________  S:\Temp\Rob N
____D________  S:\Temp\Rob N.bak
____D________  S:\Temp\Sally C
____D________  S:\Temp\Sally O
____D________  S:\Temp\Sharron B
____D_______I  S:\Temp\Simon
____D________  S:\Temp\Simon J
____D________  S:\Temp\src
____D_______I  S:\Temp\Stuart H
____D________  S:\Temp\Tina
____D________  S:\Temp\Trend
____D________  S:\Temp\UCB
____D_______I  S:\Temp\US Pics
____D_______I  S:\Temp\Vicky
____D________  S:\Temp\VSERVER003

Then this command is executed:

Code:
[S:\Temp]del /[d-30,1-1-80] /s /x /z /y /e /k s:\temp
3,989 files deleted, 5372600k deleted

And the result afterwards:

Code:
[S:\Temp]attrib /a:d
____D________  S:\Temp\.settings
_HSAD_______I  S:\Temp\Alex
_HSAD_______I  S:\Temp\Andrew
____D________  S:\Temp\bin-debug
_HS_D_______I  S:\Temp\Christine
_HS_D_______I  S:\Temp\Claire
___AD________  S:\Temp\DJG
____D________  S:\Temp\Ewen
___AD________  S:\Temp\EXBACK
____D_______I  S:\Temp\George
___AD________  S:\Temp\GL
_HS_D_______I  S:\Temp\Helen
____D________  S:\Temp\html-template
_HS_D_______I  S:\Temp\Jo
____D________  S:\Temp\Jo 2
_HSAD_______I  S:\Temp\Karen
_HS_D_______I  S:\Temp\KerryA
_HSAD_______I  S:\Temp\Liza
____D________  S:\Temp\Lorna
____D________  S:\Temp\Lucy
_HSAD_______I  S:\Temp\michelle
___AD________  S:\Temp\MMPC
_HS_D_______I  S:\Temp\Nycomed
____D________  S:\Temp\PC141
___AD________  S:\Temp\QXV site images
____D_______I  S:\Temp\Raf
____D________  S:\Temp\Raf2
___AD________  S:\Temp\Repl
___AD________  S:\Temp\Rich G
____D________  S:\Temp\Rob N
____D________  S:\Temp\Rob N.bak
_HS_D_______I  S:\Temp\Sally C
____D________  S:\Temp\Sally O
____D________  S:\Temp\Sharron B
____D_______I  S:\Temp\Simon
____D________  S:\Temp\Simon J
____D________  S:\Temp\src
____D_______I  S:\Temp\Stuart H
_HS_D_______I  S:\Temp\Tina
____D________  S:\Temp\Trend
____D________  S:\Temp\UCB
_HS_D_______I  S:\Temp\US Pics
_HS_D_______I  S:\Temp\Vicky

Something is setting the hidden & system attributes on the folders.

Cheers, Rob.
 
Hi Charles,

Does that TEMP directory itself have any funky attributes set?

Nothing obvious:

Code:
[S:\]attrib /a:d
____D________  S:\Brightside
____D________  S:\Informed
____D________  S:\Library
____D________  S:\Medea
____D________  S:\Pantaleon
____D________  S:\PMA
____D________  S:\Temp
 
[S:\]fileacl temp
S:\temp;COMPANY\Domain Users:RWXD
S:\temp;BUILTIN\Administrators:F[I]
S:\temp;CREATOR OWNER:U/F/F[I]
S:\temp;COMPANY\Domain Users:RX[I]
S:\temp;NT AUTHORITY\SYSTEM:F[I]

My beady eye is drawn towards good-old CREATOR OWNER but I don't know why...

Cheers, Rob.
 
I'm having a similar issue on one of my network drives; subdirectory attributes get set for no good reason that I can see. In my case it definitely isn't Take Command -- most of these folks don't even have it, alas. I have two rather vague theories at this point: one, the attributes are inherited from the parent directory (which itself had some funky attributes set, until I cleared 'em a few days back); two, good ol' Windows explorer may be flipping bits for its own obscure purposes; many of the changed directories seem to contain DESKTOP.INI files. Of course it could be some combination of the two, or something else altogether....
 
In my case it definitely isn't Take Command -- most of these folks don't even have it

Same here -it's just me that has it installed locally.

I have two rather vague theories at this point: one, the attributes are inherited from the parent directory (which itself had some funky attributes set, until I cleared 'em a few days back); two, good ol' Windows explorer may be flipping bits for its own obscure purposes; many of the changed directories seem to contain DESKTOP.INI files. Of course it could be some combination of the two, or something else altogether....

I concur with your thoughts here - I didn't see Desktop.ini files in there but I did see quite a few empty folders with just Thumbs.db which is hidden and system.

I don't have another tool handy that could do the same thing - which is why I like Take Command of course ;-)

Cheers, Rob.
 
BTW - what is your host operating system? Is it Windows 2008? This same command used to run without a hiccup on Windows 2003 but we migrated to Windows 2008 a couple of months ago.

Cheers, Rob.
 
Found this...

Ms-news.net

It doesn't provide an answer but shows the problem has been around for at least 4 years.
 
Found this...

ms-news.net/f3706/random-shared-folders-are-changing-attributes-1799330.html

It doesn't provide an answer but shows the problem has been around for at least 4 years.

Another one from 2006.

winserverkb.com/Uwe/Forum.aspx/windows-server/18591/Hidden-and-system-attribute-randomly-appearing-on-folders

Hmm, intriguing. If jpsoft want me to try a debug version of TC to track this down, I'm game.

Cheers, Rob.
 
BTW - what is your host operating system? Is it Windows 2008? This same command used to run without a hiccup on Windows 2003 but we migrated to Windows 2008 a couple of months ago.

This is a Windows 2003 server; all of the users accessing it should be running Windows 7, but I can't absolutely swear that's always the case.

Are you by any chance making these the users' "Documents" folders? I.e. pointing the Personal value under User Shell Folders at the network subdirectory?
 
rob.nicholson:
| JohnQSmith:
|| Found this...
||
|| ms-news.net/f3706/random-...s-1799330.html
||
|| It doesn't provide an answer but shows the problem has been around
|| for at least 4 years.
||
|| Another one from 2006.
||
|| winserverkb.com/Uwe/Forum...ing-on-folders
|
| Hmm, intriguing. If jpsoft want me to try a debug version of TC to
| track this down, I'm game.

The problem seems to be with Win2003 and Win2008 file servers, and not related to any JPsoft product. My guess is that there is a piece of bad software in those platforms, causing the problem. I seriously doubt TC could do anything about the issue, other than periodically clearing the H and S attributes by brute force. Of course, those attributes are not relevant if users expect them and thus use commands to "see through them". In Windows Explorer you can choose the option to view hidden objects, and every file and directory handling command in TCC has at least one option to ignore the H and S attributes. AFAIK CMD has that ability, too. That's the work around I would use.
--
Steve
 
I would recommend using Process Monitor from www.sysinternals.com. You would set it to filter on S:\TEMP contained in the pathname (otherwise it continuously displays every file and registry access in the whole system). This will tell you precisely what filesystem calls are being made, and by what process. You might need to run it on the server as well as the system where you are running the batch file, if they are different.
 
Since TCC isn't involved in this problem, I don't know how a debug version would help you.

Err, because it's Take Command that's carrying out the delete operation?

Okay, so it's calling Windows API to perform the delete but only you know whether it's walking through the tree one file at a time, checking timestamps and then deleting the file if it matches. Then checking for empty folders and removing those. Or whether there is an API call to do all of that in one go. Or do you delete the files all first and then delete the empty folders?

So a debug version could do something like this:

BEGIN
Make a note on the attributes on each of the folders at the root
Each time the Windows API is called, check if the attributes have magically changed
END

Kind of thing...

Cheers, Rob.
 
Err, because it's Take Command that's carrying out the delete operation?

Okay, so it's calling Windows API to perform the delete but only you know whether it's walking through the tree one file at a time, checking timestamps and then deleting the file if it matches. Then checking for empty folders and removing those. Or whether there is an API call to do all of that in one go. Or do you delete the files all first and then delete the empty folders?

TCC asks Windows to delete them one at a time (because Windows doesn't support extended wildcards or regular expressions).

So a debug version could do something like this:

BEGIN
Make a note on the attributes on each of the folders at the root
Each time the Windows API is called, check if the attributes have magically changed
END

Well, yes, but we already KNOW the attributes have been magically changed. What we don't know is whether they were changed internally by Windows or by some third-party app that's hooking the file system. And a debug version of TCC won't shed any more light on that.
 
Well, yes, but we already KNOW the attributes have been magically changed. What we don't know is whether they were changed internally by Windows or by some third-party app that's hooking the file system. And a debug version of TCC won't shed any more light on that.

I've just used robocopy to take a mirror image of S:\Temp to another server but this time hosted on Windows 2003 (not Windows 2008) and the same problem occurs.

So that shoots down my idea that it was a problem introduced with Windows 2008...

Just about to restore from backup again and reset the permissions on the entire tree.

Cheers, Rob.
 
The problem seems to be with Win2003 and Win2008 file servers, and not related to _any_ JPsoft product.

I have a bit of bad news here... I've found a copy of TC v8.02.94 and executed the same command and it doesn't have the same problem. It's deleted the files older than 30 days and left the attributes alone.

The problem therefore appears to occur with later versions, v11.00.44 in this case.

Cheers, Rob.
 
> The problem therefore appears to occur with later versions,
> v11.00.44 in this case.

I'm 100% certain this is NOT a TCC issue. There's only one Windows API to
delete a file, and v8 / v11 / v12 are going to do it exactly the same way.
And there's certainly a large amount of evidence that it happens without
TCC.

There is absolutely, positively, no code in DEL that changes directory
attributes.

Rex Conn
JP Software
 
I'm 100% certain this is NOT a TCC issue. There's only one Windows API to
delete a file, and v8 / v11 / v12 are going to do it exactly the same way.
And there's certainly a large amount of evidence that it happens without
TCC.

There is absolutely, positively, no code in DEL that changes directory
attributes.

Rex Conn
JP Software

Hi Rex,



I'm sorry - I disagree:
  • Basic Windows XP virtual machine
  • Install TC v8 - works fine
  • Install TC v11 - attributes changed randomly to RH
How if an old version worked and the new ones don't can it not be a bug in Take Command?

I'm a software developer. If somebody reported a problem in our software saying "It worked fine in v10 but breaks in v10.1", no matter where the bug actually lies (e.g. an operating system change exposes/creates the flaw in later version), it's still a bug in our software.

I've just tested with a trial copy of v12 and the same issue occurs.

Tests carried out on both Windows 2003 Server and Windows 2008 Server.

Cheers, Rob.
 
I'm sorry - I disagree:
  • Basic Windows XP virtual machine
  • Install TC v8 - works fine
  • Install TC v11 - attributes changed randomly to RH
How if an old version worked and the new ones don't can it not be a bug in Take Command?

I'm a software developer. If somebody reported a problem in our software saying "It worked fine in v10 but breaks in v10.1", no matter where the bug actually lies (e.g. an operating system change exposes/creates the flaw in later version), it's still a bug in our software.

I have to disagree with your disagreement:

1) This is a known Windows bug.
2) TCC is calling a single Windows API to do the deletion, which is either DeleteFile or SHFileOperation, depending on whether you're deleting to the recycle bin. That doesn't leave a lot of opportunity for me to "fix" a Microsoft bug.

You should check your configuration and make sure that v8 and v11 are using the same options.

The only thing that I could do about this would be to save all the attributes before deletion, and then restore everything after the deletion. This seems excessive (and really slow) when it's only happening to a tiny fraction (thus far, 1) of TCC users. (You could do the same thing in an alias, or if you know you don't have any hidden directories when you start just do an ATTRIB -R -H after the DEL.)
 
>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.

Test was done like this:
  1. Build clean Windows XP VM in VMware workstation
  2. Use ROBOCOPY with /MIR /SEC commands to make a mirror image of the temp folder
  3. Snapshot the VM
  4. Install TC v8 and run del /[d-30,1-1-80] /s /x /z /y /e /k temp
  5. Files over 30 days old deleted and attributes of root folders not touched
  6. Restore snapshot
  7. Install TC v11
  8. Re-run ROBOCOPY to recreate the folder exactly
  9. Run the same del command and attributes of root folder changed
>That doesn't leave a lot of opportunity for me to "fix" a Microsoft bug.

Why okay in TC v8 and not in TC v12 is the key question.

>You should check your configuration and make sure that v8 and v11 are using the same options.

Indentical base OS and default TC options. Not sure what specifically to check in TC re: options.

>or if you know you don't have any hidden directories when you start just do an ATTRIB -R -H after the DEL.)[/QUOTE]

That will be an okay workaround if we cannot fix the core bug.

Cheers, Rob.
 
I'm sorry - I disagree:
  • Basic Windows XP virtual machine
  • Install TC v8 - works fine
  • Install TC v11 - attributes changed randomly to RH

Do you mean that you're finding directory attributes randomly changed immediately after running the command (script?) in TC v11? Or just that you find attributes mangled at some time after running the command in v11?

--
Charles Dye [email protected]
 
Do you mean that you're finding directory attributes randomly changed immediately after running the command (script?) in TC v11? Or just that you find attributes mangled at some time after running the command in v11?

--
Charles Dye [email protected]


Hi Charles - immediately after running the command:

>attrib /a:d temp
____D________ F:\Data\temp\.settings
____D________ F:\Data\temp\Andrew
____D________ F:\Data\temp\bin-debug
____D________ F:\Data\temp\DJG
____D________ F:\Data\temp\Ewen
>del /[d-30,1-1-80] /s /x /z /y /e /k temp
xyz files deleted
>attrib /a:d temp
____D________ F:\Data\temp\.settings
_HS_D________ F:\Data\temp\Andrew
____D________ F:\Data\temp\bin-debug
____D________ F:\Data\temp\DJG
____D________ F:\Data\temp\Ewen

Cheers, Rob.

PS. It's not random as such - restore the folder and run the command again and the same folders are effected. It's just random in that not all the folders in Temp are effected.
 
PS. It's not random as such - restore the folder and run the command again and the same folders are effected. It's just random in that not all the folders in Temp are effected.

Well, that's really bizarre.... Does the problem follow the data? If you put Andrew's files in Ewen's folder and vice versa, does Ewen's folder get hidden instead of Andrew's?
 

Similar threads

Back
Top