Strange Access Denied Problem with Windows 7

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?
0
Joe
2/25/2010 9:25:59 PM
dotnet.languages.csharp 1931 articles. 0 followers. Follow

2 Replies
1111 Views

Similar Articles

[PageSpeed] 57

Joe Cool wrote:
> [...]
> 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
0
Peter
2/25/2010 9:48:21 PM
On Feb 25, 4:48=A0pm, Peter Duniho <no.peted.s...@no.nwlink.spam.com>
wrote:
> Joe Cool wrote:
> > [...]
> > 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. =A0Which 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. =A0It'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. =A0That 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. =A0You'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.
0
Joe
2/26/2010 12:05:47 AM
Reply:

Similar Artilces: