DosTips.com

Hi,


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?


Regards,
GC

Every directory has the read-only attribute by default. I'm virtually certain this is not your problem. You can move a directory, but you can't overwrite an existing directory using MOVE.
Try to remove the old "auto" directory in the destination path using RD /S /Q

Regards
aGerman

Thanks for your reply aGerman.

I already kept that check in the script; if the folder already exists, the script deletes it recursively and then creates a new folder with the same name. After few more tests, I too 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 ('auto') just inside G:\ instead of G:\root. The same error came up again.

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


Regards,
GC