Failed to create the automatic updater temp folder: Access to the path 's.png' is denied.

We need more information. What versions are you using (wyUpdate, AutomaticUpdater, etc.). Right click each file and click Properties, then click the Details tab.

When in the update process is that happening? During the update steps? When you're checking?

Can you reproduce this?

I'm using 2.6.16.4, although it is a custom build that you sent me to handle not elevating when updating outside of the user's profile directory when the directory already has permissions.

The operating system is Windows XP Service Pack 3, the user is a local admin. The update is happening via AutomaticUpdater. The application being updated is a Windows Service.

Try using our version of wyUpdate & AutomaticUpdater. Use 2.6.18. Tell me if you still get the problem.

Ok, I'll do that and see whether it it still a problem.

I have wyUpdate using a custom self update location. Is the wyUpdate.exe version built by wyBuild the latest? The version number of wyUpdate.exe is 2.6.18.0.

No, the latest is 2.6.18.3, you can download that here. Just extract it from the wyu file.

The next version of wyBuild will include the latest version of wyUpdate, but we had to make an early release to fix some critical self-update bugs.

I have updated to 2.6.18.3 and the problem still happens. This issue only occurs with updating the Windows Service application on this computer. There is a normal Windows application on the same computer that also uses wyUpdate and it updates without any problem.

Restarting the computer doesn't fix this issue so the computer is permanently stuck at this version. This is bug I urgently need to fix before I can deploy my application to users.

Did you clear out the cache folders? Try that:

rmdir /s /q "%userprofile%\wc"rmdir /s /q "%appdata%\wyUpdate AU"

Is the problem still happening? If so,:

1. When in the update process is that happening? During the update steps? When you're checking?
2. Is wyUpdate 2.6.18.3 installed with your app and *that's* causing the problem? Or do you have your old custom version and it's failing when wyUpdate self-updates?
3. Can you reproduce this on other computers?
4. Can you send us an example app that reproduces this behavior?

I had previously cleared those folders after reading through other issues on the forum. Also I just double checked again that 2.6.18.3 is being used by both applications. This issue only happens on this computer.

The Windows Service is running under the LocalSystem account. I just tried switching its account to the Administrator and the Windows Service application successfully updated. Does that give you any clues about what is going wrong?

Your "%userprofile%\wc" command will clear updates for the currently logged in user. What about clearing updates for the LocalSystem account?

I tested another update after switching the Windows Service back to Local System (this is what the service will run as by default when deployed to users) and it is once again breaking with the same error message.

Clear these 2 folders:

C:\Windows\System32\config\systemprofile\wcC:\Windows\System32\config\systemprofile\AppData\Roaming\wyUpdate AU

I cleared the first directory but I couldn't find the second directory on the computer, but it looks like it didn't matter because the Windows Service is now successfully updating. Thanks for your help.

It looks like each update was creating a directory in systemprofile\wc with one char from a GUID that gradually grew until the GUID was complete, at which point the error started to occur. Will this issue happen again in future after many updates?

It looks like each update was creating a directory in systemprofile\wc with one char from a GUID that gradually grew until the GUID was complete, at which point the error started to occur. Will this issue happen again in future after many updates?

This was a bug with old versions of wyUpdate -- so, no it shouldn't happen again.

Hi there,

I am a colleague of JamesNK. We are still seeing new folders getting created in the C:\Windows\System32\config\systemprofile\wc folder when using wyUpdate 2.16.8.3 in the same manner as before. I.e. each update results in a new subdirectory with one char from a GUID appended to the longest name of any existing subdirectories in the wc folder.

When you say that the problem shouldn't happen with this version of wyUpdate do you mean that these subdirectories shouldn't be getting created, or do you mean that wyUpdate will not bomb out once it has reached a full-GUID-length subdirectory name?

Cheers,Tana

When you say that the problem shouldn't happen with this version of wyUpdate do you mean that these subdirectories shouldn't be getting created, or do you mean that wyUpdate will not bomb out once it has reached a full-GUID-length subdirectory name?

Both. We haven't been able to reproduce it with 2.6.18.4. If you can make a small example that reproduces this behavior please send it to me.

If you can't reproduce this, then let me know and we'll figure something out.

Hi again,

I am not able to make an example like you requested unfortunately.

However, I downloaded the wyUpdate source code and managed to identify the problem. The following code throws an UnauthorizedAccessException (Access to the path 's.png' is denied) at Directory.Delete and then swallows the exception:

void bw_DoWorkDeleteTemporary(object sender, DoWorkEventArgs e) { try { //delete the temp directory Directory.Delete(TempDirectory, true); } catch { } ....

I checked the ACL on the temporary folder and it looked fine. I then discovered that the s.png and the t.png files in the temp directory were marked as readonly. When I manually changed them to writeable and reran the code above via the debugger I found that the folder was deleted correctly.

I did some further investigation and it appears that these image files are packed into the .wyc file by wyBuild with readonly set to true on them. I am guessing that it is wyBuild setting them to readonly as I found the source files on disk in the wyBuild program files directory and they are writeable.

So I guess the next question is, how best to fix the problem? Change wyBuild to not make the image files readonly, or change wyUpdate to either delete all files from subdirectories first or mark them all as writeable?

Aside from that I don't know that the exceptions should just be swallowed by the temp directory cleanup code, especially as the side affect is that wyUpdate may just stop working for some people eventually, like we experienced. Alternatively if you do decide to continue swallowing the exceptions then the temp directory naming strategy should be changed so that directory names aren't constrained to the length of a GUID.

Could you please give me your recommendation, and when you think you would likely be able to address it? I guess for now I can make a custom build of wyUpdate or unpack the .wyc files, change the files to be writeable, and then repack them.

Cheers,Tana

We're looking into this.

Hi Wyatt, any update on this?

We're fixing wyUpdate to delete temp folders if they contain read-only files. Unfortunately we had overlooked this. Thanks for reporting this.

Hi,

Has this fix been included in a new wyUpdate build yet, or has it been scheduled to be included in a new build? If so which one?

Cheers,Tana

We haven't released it yet.

Are you able to give any indication of when this would be included in a release please?

Hi Wyatt,

Just chasing this up again. Has this been scheduled for a release yet? As time goes on it is becoming more and more likely to affect other wyUpdate users as well.

Cheers,Tana

It will be coming with the next wyUpdate version. This is an entirely avoidable bug, though. The way to avoid it is to not include read-only files in the client.wyc. (That is, any theme file you include must be read/write before clicking "Build wyUpdate:).

Hi there,

I am a colleague of JamesNK AND Tana, and wanted to find out if there was any update to this.

Wyatt,

Sorry for my previous reply. I hadn't seen your final statement of

"The way to avoid it is to not include read-only files in the client.wyc. (That is, any theme file you include must be read/write before clicking "Build wyUpdate:)."

So can you clarify? Is it the WyBuild program which is swapping these to read-only?

No, wyBuild doesn't change files to read only. Just verify any files that wyBuild will be including in your client.wyc file are not read-only.