How to unset Read-only attribute of directory

July 16, 2010 at 10:27:02
Specs: Windows

I am facing a problem with directory attribute. I have a script that creates a sub-directory inside a given dir.

For example, the script creates directory 'auto' inside G:\root\

The script then tries to MOVE a directory from a given location to G:\root\auto\

The problem is that when it tries to perform the MOVE operation, it gets ‘Access Denied’ message. After some investigation, I found that the issue was with the parent directory G:\root. If I unset the Read-only attribute of only the G:\root folder ('auto' directory’s attribute is left as it is), the script successfully performs the MOVE operation.

This script worked fine when I executed it for the first time. As this script is scheduled to run twice a day, I noticed that the script was failing at the MOVE operation every time.

I am not sure why this is happening. :( This is weird for me because the issue seems to be with the parent folder and not the child folder that is actually getting created. Is there any way to rectify this behaviour?

I am not sure whether ATTRIB command will work. I have to try it out.

Any suggestions?


See More: How to unset Read-only attribute of directory

Report •

July 16, 2010 at 12:22:49
The ATTRIB command should work.

ATTRIB g:\root -r should do it.

However, once the read only attribute is removed it should stay that way till something else changes it.


Report •

July 16, 2010 at 12:31:14
Do you have the same results if you just copy the folder and not move it [you can always delete the folder after the copy in your script]?

Report •

July 18, 2010 at 02:45:34
It’s finally working now.

After few more tests, I realized that the problem was not with the parent folder attribute. I modified my script to test whether the same error occurs when I try to create a directory just inside G:\ instead of G:\root. The same error came up again.

@StuartS: Thanks for your input!

I thought of adding “ATTRIB –r G:\auto” before performing MOVE operation; still nothing happened. Then I was sure that there might be some issue with the source folder itself; I was correct this time.

A log file in source folder was tied up to a process. After releasing that handle, everything is working fine now.

@wanderer: Your idea was good. This could have helped me narrow down to the open handle. I did not try this first as the folder was too big to copy. I thought of giving this a try later when I am exhausted with all other ideas. Thanks.

Thanks to both of you for your help.


Report •
Related Solutions

Ask Question