Hello,
Sorry to hear you are having issues. This usually happen when you have OneDrive Desktop Sync turn on or any application that can sync your desktop icons on Cloud storage.

Thank you.
Basj,
Stardock Community Assistant.

I do have OneDrive installed but I do not use the desktop backup feature.

Does the issue reappear if you do the hybernate and wake up again?

Thank you,

Basj,
Stardock Community Assistant

Hello,
Sorry to hear you are having issues. Please update to Fences 5.82 revision 6. it the same as v5.83 but with extra debug information.

Here is the link you can use to download it: https://cdn.stardock.us/support/uploads/Fences5_5.8.2.6-j133-Setup.exe 

Install it reboot and test. If it still and issue, please follow the instructions at https://forums.stardock.com/529991/page/1 to submit us a report, which will contain extended debug information. Be sure to reproduce the problem a few times / over at least a couple of cycles to be sure we can see the problem and we'll work to take a look. We really appreciate your help in working to solve your issue.

(Note, that this version is likely to resolve your issues too, and if so, we'd love to know that too.)

Thank you.
Basj,
Stardock Community Assistant.

I'll try it out and send you the log.

Hi hpeach, got the log. This is very interesting. Not to give too much away but I'm seeing your desktop seems to be pointing at "D:\Desktop\", which is fine. What I'm seeing is the icons be put into the Fence groups, but them I'm also seeing the program notice that the files themselves don't exist (for some reason), and so clearing those entries. This is very confusing, as the app does several verifications to make sure that the file does not exist before taking this action.

I'll have to add more debug code and have us take another look into why it's thinking that. Your patience is greatly appreciated. I'll assume this D:\ drive is an internal drive and not an external drive correct?

Hrm. Well according to this, your entire desktop folder is redirected to D:\Desktop, and it is indeed saying files are missing. So "pretty much always" -- if they're unplugged at any time, unfortunately with the current code, their entries would get zapped for being removed.

But, interesting note on my end, that I should probably verify the drive can be accessed at all, before marking a file as missing! So that's something I'll take a look at.

Sounds like you have a seperate problem with folder portals not resuming properly after hibernate?

Right. I guess gotcha is it "prunes" this data at regular intervals. So (1) either files actually not present at that time, or (2) somehow they're failing to register.

Going to solve by: if the parent folder doesn't exist, don't remove the entry. This pruning mechanism is meant to make it so that if you delete a file, and then you create a file of the same name at a later date, the old data isn't "hanging around". But, if the parent folder isn't there... then, all bets are off.

Will see what we can do with a new beta release shortly. Thank you!