5

I have BAT scripts which are nothing tricky and work fine on XP. But on Win 7, about 1 in 5 executions of mkdir following rmdir give a mystery Access Denied. E.g.

S:\TLIB importing\! Curtains\2 To process>rmdir temp3allout /s /q

S:\TLIB importing\! Curtains\2 To process>mkdir temp3allout
Access is denied.

After this, when I try in Explorer, it has no problem making that directory. Running thatBAT again usually succeeds.

Any idea what's going on here?

Win XP disc was a regular 2Gb drive. Win 7 disc is a 2Gb Intel RST RAID1 array with caching and flushing disabled http://i.imgur.com/Ohqkg2t.png .

ChrisJJ
  • 1,904
  • 1
  • 24
  • 34
  • The file system hasn't finished deleting the directory yet. Sometimes this will happen synchronously, i.e., before the `rmdir` command completes, but sometimes there will be a very short but nonzero delay. (In XP it was always synchronous, IIRC.) If possible, avoid deleting and immediately recreating directories; if you can't avoid it, you'll need to detect the failure and retry. – Harry Johnston Aug 20 '14 at 02:38
  • 1
    @Harry, I'm really surprised to hear that such a breaking change was made to the OS, but it certainly fits with my observations. Thanks. Please enter that as an answer so I can accept it. – ChrisJJ Aug 21 '14 at 12:48
  • 1
    The deletion completes when the last handle is closed. That hasn't changed. Usually, it's anti-virus software that is holding the directory open and preventing the deletion from completing. – Raymond Chen Aug 21 '14 at 22:25
  • @RaymondChen: I know that was always the case at the kernel layer, but it seemed to me that `DeleteFile` used to wait for the deletion to complete before returning. I never ran across this issue in XP or earlier and I'm not aware of any reports from anyone else predating Vista either. OTOH, I suppose that might be because Vista forced changes to the way anti-virus software works rather than because of any changes to the DeleteFile function itself. – Harry Johnston Aug 23 '14 at 02:04
  • @RaymondChen, I don't see prevention of completion. And if I'm getting delay of completion, then that's not itself a problem. But if rmdir is failing to wait for completion, then that is a problem. rmdir is defined to remove a directory, not to schedule removal for some time in the future. – ChrisJJ Aug 24 '14 at 19:29
  • DeleteFile never waited for deletion. It marks the file as "delete when the last handle is closed". – Raymond Chen Aug 24 '14 at 19:36
  • @Raymond, no problem there, because that accords with docs: "DeleteFile function marks a file for deletion on close." But I see no such for rmdir. – ChrisJJ Aug 25 '14 at 23:17
  • @ChrisJJ Oh you mean this paragraph? "[The RemoveDirectory function marks a directory for deletion on close. Therefore, the directory is not removed until the last handle to the directory is closed.](http://msdn.microsoft.com/en-us/library/windows/desktop/aa365488(v=vs.85).aspx)" – Raymond Chen Aug 26 '14 at 03:47
  • @Raymond. Not at all. That's in a programmer's reference for an API function. The docs for the user command rmdir http://goo.gl/ make no mention of the delay, or of your API function for that matter. – ChrisJJ Aug 27 '14 at 13:28
  • The `rmdir` command apparently uses `RemoveDirectory` to get its job done. Naturally, any limitations of `RemoveDirectory` also apply to `rmdir`. And `RemoveDirectory` uses the I/O stack. Naturally, any limitations of the I/O stack also apply to `rmdir`. It's turtles all the way down. – Raymond Chen Aug 27 '14 at 14:22
  • @Raymond, The rmdir command apparently uses RemoveDirectory to not get its job done. ;) – ChrisJJ Aug 28 '14 at 14:04
  • see how you can [wait in a batch script](https://stackoverflow.com/q/1672338/1791065) – Alexandru Marculescu Mar 07 '18 at 08:59

2 Answers2

6

This happens when the file system hasn't finished deleting the directory yet.

Sometimes this will happen synchronously, i.e., before the rmdir command completes, but sometimes there will be a very short but nonzero delay. (In XP it was always synchronous, IIRC.)

If possible, avoid deleting and immediately recreating directories; if you can't avoid it, you'll need to detect the failure and retry.

You should probably also test and if necessary retry the rmdir; sometimes rmdir runs into the same problem and fails to delete the entire directory tree.

Harry Johnston
  • 33,445
  • 6
  • 56
  • 142
  • I'm not entirely sure that is true, from procmon logs it appears things like Windows Defender and Windows Search Indexer/change journal will attempt to access it just before the delete resulting it in being locked. – paulm Dec 13 '18 at 12:11
  • @paulm, that's typically what has caused the delay, yes. But the only reason the delay affects the script this way is that rmdir is asynchronous. (If it were synchronous you might expect it to fail anyway because the directory is locked, but that will only happen if the background process [doesn't use oplocks](https://blogs.msdn.microsoft.com/oldnewthing/20130415-00/?p=4663) and would result in a different failure pattern anyway.) – Harry Johnston Dec 13 '18 at 18:25
0

Because that directory or file in that directory is open in some editor,first you have to close that file/directory from editor and then try.

These error usually comes when we create some directory and then delete it,but it is partially deleted and we create new directory with same name.

Prathmesh Kulkarni
  • 1
  • 1