Strange Access Denied Problem with Windows 7

[Joe Cool]

I got a new computer about six months ago that came with Windows Vista
Home Premium 64bit. Before that I had done all of my .NET development
either on an XP Pro VM or my former XP Pro computer at home. Shortly
after getting my new computer at home, I also got a license for VMWare
to be able to test my software on multiple platforms and
configurations.

I had wrote an application originally in VB.NET that was a simple
backup utility. It supports mutiple backup configurations. Any given
copnfiguration would define a backup which would be a list of files to
backup, a list of folders to backup and a target device and target
folder. It's a little more complicated than that but those are the
basics.

When a backup is run the user has the option to delete all files at
the target location, then after deleting them it copys all files and
folders specified to the target folder on the target device.

I am now converting this application to C#.NET in a Windows 7 64bit
VM. I ran into some strange access denied problems when trying to copy
files. At first I thought it was a Windows 7/Vista issue. I found out
how to install the application so that when it runs the user is asked
for administrator permission to run. But the problem turned out to be
more sinister.

I found that the problem is only with Windows 7, it doesn't happen on
Vista. IF you have a Windows Explorer window open and have selected
the target folder for the backup, THAT is what causes the access
denied problem. If you just leave Windows Explorer closed, then there
is never an access denied problem.

PLUS, I can switch over to the Windows Explorer window and delete the
file just fine by pointing and clicking.

Any ideas?

 

[Peter Duniho]

[...]
I am now converting this application to C#.NET in a Windows 7 64bit
VM. I ran into some strange access denied problems when trying to copy
files. At first I thought it was a Windows 7/Vista issue. I found out
how to install the application so that when it runs the user is asked
for administrator permission to run. But the problem turned out to be
more sinister.

I found that the problem is only with Windows 7, it doesn't happen on
Vista. IF you have a Windows Explorer window open and have selected
the target folder for the backup, THAT is what causes the access
denied problem. If you just leave Windows Explorer closed, then there
is never an access denied problem.

PLUS, I can switch over to the Windows Explorer window and delete the
file just fine by pointing and clicking.

Any ideas?

I haven't tested it extensively, but it sounds like Windows Explorer is
simply keeping a lock on the folder when it's selected. Which makes
some sense, in an awkward sort of way.

Personally, it's my opinion that Explorer should not stand in the way of
normal uses of the file system. It's there to provide a view on the
current state of the file system, and to do so without interfering with
the proper operation of other programs that use the file system.

But, to the extent that Windows Explorer can't do that job without doing
at least _some_ locking on the file system, there will always be cases
where activity in Explorer affects other programs.

For example, when you select a folder, Explorer (eventually) reports the
total size of the folder, which it do only by traversing the contents,
and while examining the contents may lock something, which implicitly
locks the entire sub-tree of the file system.

And depending on the extent to which Microsoft has decided to make
Explorer a more active "explorer", it will necessarily wind up doing
more locking. That aspect being a subjective choice in the
implementation of Explorer – the trade-off between Windows Explorer
being non-intrusive and it being able to present all the information to
the user that Microsoft wants it to – it's something that can easily
vary from one version of the OS to another.

For the specific question: it seems to me you could just delete the
_contents_ of the target folder, rather than the whole folder. You'll
still run the risk of something in the folder not being able to be
deleted, but the finer the granularity of the deletion, the lower the
odds of a problem.

Alternatively, you can just include in your error reporting to the user
a suggestion that they close any windows for applications that might be
using a file or folder that failed to delete, including windows in
Windows Explorer (you may need to do that anyway, since the underlying
problem is intractable…there will always be ways for the access
violation to occur).

Pete

 

[Joe Cool]

[...]
I am now converting this application to C#.NET in a Windows 7 64bit
VM. I ran into some strange access denied problems when trying to copy
files. At first I thought it was a Windows 7/Vista issue. I found out
how to install the application so that when it runs the user is asked
for administrator permission to run. But the problem turned out to be
more sinister.

I found that the problem is only with Windows 7, it doesn't happen on
Vista. IF you have a Windows Explorer window open and have selected
the target folder for the backup, THAT is what causes the access
denied problem. If you just leave Windows Explorer closed, then there
is never an access denied problem.

PLUS, I can switch over to the Windows Explorer window and delete the
file just fine by pointing and clicking.

Any ideas?

I haven't tested it extensively, but it sounds like Windows Explorer is
simply keeping a lock on the folder when it's selected.  Which makes
some sense, in an awkward sort of way.

That is my suspicion.

Personally, it's my opinion that Explorer should not stand in the way of
normal uses of the file system.  It's there to provide a view on the
current state of the file system, and to do so without interfering with
the proper operation of other programs that use the file system.
Agreed.


But, to the extent that Windows Explorer can't do that job without doing
at least _some_ locking on the file system, there will always be cases
where activity in Explorer affects other programs.

For example, when you select a folder, Explorer (eventually) reports the
total size of the folder, which it do only by traversing the contents,
and while examining the contents may lock something, which implicitly
locks the entire sub-tree of the file system.

And depending on the extent to which Microsoft has decided to make
Explorer a more active "explorer", it will necessarily wind up doing
more locking.  That aspect being a subjective choice in the
implementation of Explorer the trade-off between Windows Explorer
being non-intrusive and it being able to present all the information to
the user that Microsoft wants it to it's something that can easily
vary from one version of the OS to another.

For the specific question: it seems to me you could just delete the
_contents_ of the target folder, rather than the whole folder.  You'll
still run the risk of something in the folder not being able to be
deleted, but the finer the granularity of the deletion, the lower the
odds of a problem.

Actually the exception being thrown does mention a problem with a
specific file, the entire process of deleting the target folders and
files is by deleting the main backup folder a la:

Directory.Delete(pathToBackupFolder);

Alternatively, you can just include in your error reporting to the user
a suggestion that they close any windows for applications that might be
using a file or folder that failed to delete, including windows in
Windows Explorer (you may need to do that anyway, since the underlying
problem is intractable there will always be ways for the access
violation to occur).

Good suggestion. There doesn't seem to be any other way to handle this
situation.

I had hoped someone else may had seen this problem and figured out a
way around it.