UE Download folder deleted on UE activation

[stevelon]

Hi Alex.

My download folder for UE happens to be on a disk that is mounted to another drive.
The configured UE download folder is, say, g:\DL\UE, where g:\DL\UE itself was an empty folder upon which another disk was mounted, and it is here that downloads are meant to go.

Most of the time (but not always) activation of UE.exe causes the unmounting of the mounted disk and deletion of the "UE" empty mount point folder.
I've been getting around this by starting UE, recreating the UE folder under g:\DL if it has disappeared again and remounting with diskmgmt.msc
It's been an issue with many new releases of UE so I'm guessing nobody else has ever raised this, but if you can fix this that would be great.

Thanks for looking at this.

[alex]

Hi Steve,

Is it something related to Edit menu->Properties->Unpack "Delete empty save folders" or it is something else?

I see it is checked by default.

[stevelon]

Hi Alex,

I've cleared that setting and the problem hasn't happened since (although it was always hit and miss)

I wonder if whatever system call(s) you use to check for empty folders don't always check if the folder is currently in use as a mount point...

Anyway. It seems to be OK now. Thanks for the quick response.

[alex]

The program only calls ::RemoveDirectory, it doesn't know anything about mounted folders, the rest is how the system handles that

https://learn.microsoft.com/en-us/windo ... directorya

The description mentions something about links.

What can be done when the option is checked but the save path starts with \\ such empty save folders won't be deleted.

[alex]

>although it was always hit and miss

When you saved to that folder previously and the files are still listed in the unpack pane and the files are not in that folder any more on program restart only then it will call RemoveDirectory on that folder which will fail if it is not empty (but apparently the call will unlink it even if it is not empty).

In the next release it won't touch paths starting with \\ so it will be the way to go if you would prefer the option checked.

[stevelon]

Hi Alex. Unticking the option is fine for me. Problem solved

Thanks

[alex]

If you are talking about paths starting with \\ and you want to try it with the checkbox checked I can compile a version and send you a link.

I just added

&&strncmp(*folder,"\\\\",2) before &&::RemoveDirectory(*folder) so it won't proceed there

But if it is a different method of mounting better just keep that checkbox unchecked.

[stevelon]

Hi Alex. No I'm not using SMB for access to this disk, and the only reason the option was checked was that was the default. Thanks for the offer though.

[alex]

So it looks like a normal path only mapped to a different path?

Can you refer me to what it is exactly?

Even if something later in kernel32.dll and not present in earlier systems it is still easy to maintain backward compatibility.

I just wonder if it is possible to detect from the program.

[stevelon]

Sorry if I wasn't clear. I'm sure you'll already know this, but instead of allocating a drive letter to a diskdrive/partition you can choose an existing empty folder on another drive and mount the drive/partition there. So it looks like a continuation of an already existing folder heirarchy.

I already had a drive g:. This had a subfolder named DL. I created an empty subfolder under DL called UE (giving g:\DL\UE) and with diskmgmt.msc chose the "Mount in the following empty NTFS folder" option for this partition instead of the "Assign the following drive letter" option. So instead of g:\DL\UE being an empty folder it now gives everything in the mounted partition.

It's a way of a) avoiding using up drive letters and b) extending a nearly full existing partition.

It's analogous to the mount command (or even symlinks) in Unix. I'm sure I'm teaching grandma to suck eggs with this explanation....

Am I being clearer now? Thanks for the continued interest.