From: nki00 on
OK. I guess, I can't just make it either way :(

I had to write my own uninstaller. It is running with admin privileges but
when it tried to delete a file that was created by my own installer using
DeleteFile() API it returns ERROR_ACCESS_DENIED. I was under impression that
an admin could do that kinda stuff? To make matters worse I can't remove
that file using Windows Explorer either, it shows, "You need permission to
perform this action". I'm obviously missing something, but what?


From: Jackie on
nki00 wrote:
> OK. I guess, I can't just make it either way :(
>
> I had to write my own uninstaller. It is running with admin privileges but
> when it tried to delete a file that was created by my own installer using
> DeleteFile() API it returns ERROR_ACCESS_DENIED. I was under impression that
> an admin could do that kinda stuff? To make matters worse I can't remove
> that file using Windows Explorer either, it shows, "You need permission to
> perform this action". I'm obviously missing something, but what?
>

Are you sure that file isn't open in some process? Can you delete the
file after rebooting the computer, with either DeleteFile or Windows
Explorer?

--
Regards,
Jackie
From: nki00 on
> Are you sure that file isn't open in some process? Can you delete the file
> after rebooting the computer, with either DeleteFile or Windows Explorer?
>
> --
> Regards,
> Jackie


No, there's more to it. After doing some Google search here's what people
recommended (outside of API world):


1. Take ownership of the file, you'll need to use the takeown command. Here's
an example:

takeown /f <file_path>

2. That will give you ownership of the file, but you still have no rights to
delete it. Now you can run the cacls command to give yourself full control
rights to the file:

cacls <file_path> /G <user>:F



So, then I was trying to translate it into API calls. Here's what I came up
with:

1. For taking ownership, there's this example:
(That I have no idea what it does :)
http://msdn.microsoft.com/en-us/library/aa379620%28VS.85%29.aspx

2. For this one I had to improvise (with my limited knowledge of security
APIs). So please let me know if it's correct?

//NO ERROR CHECKS!

SECURITY_DESCRIPTOR* pSD = (SECURITY_DESCRIPTOR*)new
BYTE[SECURITY_DESCRIPTOR_MIN_LENGTH];

InitializeSecurityDescriptor(pSD, SECURITY_DESCRIPTOR_REVISION);

SetSecurityDescriptorDacl(pSD, TRUE, NULL, FALSE);

DWORD dwRes = SetNamedSecurityInfo(
strFilePath,
SE_FILE_OBJECT,
DACL_SECURITY_INFORMATION,
NULL, NULL,
pSD->Dacl,
NULL);

delete[] pSD;




After that the file seems to be going away, but still not in 100% of the
times.


After maybe a couple hours of mad mouse clicking I learned that Windows
Event Viewer and Service Control Manager (Control Panel -> Admin Tools ->
Services) keep a reference to my file and thus I was getting access denied.
Weird, because I thought in that case the last error would be different?
Also why don't they close file handles?


From: Jackie on
nki00 wrote:
> 1. Take ownership of the file

I am not sure but it sounds a bit extreme to try and force your way
through to delete the file. But I guess you could ask the user if s/he
wants to do that if the "normal" way fails.

I haven't dealt with permission on files before but I have used the same
APIs to allow a user to interact with an interactive desktop.

I can try to have a look through my code a bit later so I can't give you
an instant answer right now.

> After maybe a couple hours of mad mouse clicking I learned that Windows
> Event Viewer and Service Control Manager (Control Panel -> Admin Tools ->
> Services) keep a reference to my file and thus I was getting access denied.
> Weird, because I thought in that case the last error would be different?
> Also why don't they close file handles?
>

I am really not sure why this would happen if the process which opened
the file closed it or exited.
Is the process running under LocalSystem, by the way? Not sure if that
can have anything to do with it.

--
Regards,
Jackie
From: Matti Vuori on
Jackie <Jackie(a)an.on> wrote in
news:4c1f4c64$0$17479$c3e8da3(a)news.astraweb.com:
>> After maybe a couple hours of mad mouse clicking I learned that
>> Windows Event Viewer and Service Control Manager (Control Panel ->
>> Admin Tools -> Services) keep a reference to my file and thus I was
>> getting access denied. Weird, because I thought in that case the last
>> error would be different? Also why don't they close file handles?
> I am really not sure why this would happen if the process which opened
> the file closed it or exited.

I have for some time experienced locked files even though no process would
need to access the files.

But after I added to all my file access routines a loop to retry writing,
deleting etc. for a couple times, in a second or two it would always
succeed... I think the Windows API really should have built-in support for
retries, but as it does not, the programmer must implement it.

_Perhaps_ the same thing could help in this case.