VMware Horizon Community
atoerper
Enthusiast
Enthusiast
Jump to solution

Writable Volume behavior with Deleted files

We are seeing strange behavior when Writable volumes are enabled and how it handles deleted files. Here is the scenario:

-User copies from from Directory A to Directory B

-User deletes file from Directory A

-User then attempts to copy file from Directory B to Directory A

-Windows clams the file already exists and asks if users should copy and replace or not copy at all

Why would windows think the file exists when it has been deleted. We've also notice that deleted files do not go to the Windows recycle bin.

Maybe this behavior is by design and if so is there a way to prevent it?

We are running AppVolumes 2.12.1.103

Reply
0 Kudos
1 Solution

Accepted Solutions
atoerper
Enthusiast
Enthusiast
Jump to solution

It appears the Writable does not behave this way when using AppVolumes 2.13 Manager/Agent as we have tested the same scenario in a test environment.

View solution in original post

Reply
0 Kudos
5 Replies
Ray_handels
Virtuoso
Virtuoso
Jump to solution

This is by design...

Here is how it works.

You machine is build up the following way. Golden Image --> Appstack --> Writable so the settings in your writable always take precedence over the appstacks and your golden image.

Let's say you have a folder called temp on your Golden image with 5 files, A, B, C, D and E. If a user deletes the temp folder it can't remove the folder from the golden image off course. What Appvolumes does is it creates a marker for this folder and marks it as #DELETED#. You can find these settings in your writable volume. Attach it to a machine without Appvolumes agent and load the snapvol.dat Hyve to your regedit. You can actually see what the writable volume holds.

So let's go back to the example here. If the user would delete the C:\Temp folder, the writable will mark it as #DELETED#. If you log off and back on again the temp folder wont be there because the writable takes precedence and thus "hides" the temp folder. But the user did not remove the files itself. If he was to recreate the folder again the #DELETED# marker for the folder c:\Temp wil be removed and you would not only see the folder C:\Temp but also all files will be there again as they are present on the Golden image.

I hope I'm making any sense here. And regarding editing of the writable and checking it, do this at your won risk. It could potentially break the writable altogether.

Reply
0 Kudos
atoerper
Enthusiast
Enthusiast
Jump to solution

This makes sense and thanks for the response.

Is there a way to prevent this behavior? Basically we need to allow users to copy a file to another location(within the OS/Writable), delete it from original location but then copy it back without getting the "file already exists" error message. We found that if the user logs off and back in again, they are able to copy the file back to original location but this isn't a legit solution.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso
Jump to solution

No, there is now way to disable or prevent this from happening because this is the way the writable volume works.

The files the users need to remove, are these in the golden image or the appstack or created within the writable?

What could work is that you trigger a refresh of the explorer (either by simply hitting F5 or killing and starting the explorer.exe process) or manually creating the folder before the actual copy, that might just work. Or you can exclude this folder from the writable altogether, edit the snapvol.cfg file on the writable to not include those folders. They won't be there after log off though..

Reply
0 Kudos
atoerper
Enthusiast
Enthusiast
Jump to solution

No AppStacks in our scenario, just a Writable.  The files initially come down from the golden image but as they are manipulated, they are stored on the writable.

The problem is when the files are deleted, they no longer show up in file explorer so an F5 refresh doesn't really do much for us.

We need the folder where these files live to be persistent so eliminating from Writable via snapvol.cfg isn't an option. I guess we could redirect via UEM but the folder lives outside the user profile and I don't think UEM can redirect such locations. Plus the folder is several GB so that could impact performance.

Reply
0 Kudos
atoerper
Enthusiast
Enthusiast
Jump to solution

It appears the Writable does not behave this way when using AppVolumes 2.13 Manager/Agent as we have tested the same scenario in a test environment.

Reply
0 Kudos