Enigma Protector

Hello, I have a question about how file virtualization works in the context of my folder structure: Here's the situation: original.exe requires both resource1.dat and resource2.dat to function properly. I have created a boxed.exe from original.exe, which packs a different version of resource2.dat (same name, different content).

My intention is that when running boxed.exe, it should use the updated resource2.dat from its own directory, while still accessing the unchanged resource1.dat from the original directory. However, what I observed is that the entire ./resources directory seems to be replaced by %DEFAULT FOLDER%/resources, meaning boxed.exe can only see the updated resource2.dat and cannot find resource1.dat.

I am trying to understand whether this observation is accurate, or if I might have made an error. If this is how the environment is designed to work, are there any workarounds that would allow boxed.exe to access both the updated resource2.dat and the untouched resource1.dat? Thank you for your help.

In my opinion you should take the folder <<sources>> as %DEFAULT FOLDER%/ to include both resource1.dat and resource2.dat. I hope it will work.

arxaios wrote: Mon Apr 15, 2024 9:59 am In my opinion you should take the folder <<sources>> as %DEFAULT FOLDER%/ to include both resource1.dat and resource2.dat. I hope it will work.

Thanks for your reply. Are you suggesting that I should place both resource1.dat and the updated resource2.dat within the "boxed.exe/%DEFAULT FOLDER%/resources/" directory? I've tried this, and it definitely works. However, the file structure I provided is just a simplified example. In reality, resource1.dat could be several gigabytes in size, and there may be many other such resources. Since I'm only looking to make a small update, packing everything into boxed.exe is not a practical solution.

nbook wrote: Sun Apr 14, 2024 6:32 am Hello, I have a question about how file virtualization works in the context of my folder structure:

Code: Select all

.
├── resources/
│   ├── resource1.dat
│   └── resource2.dat
├── original.exe
└── boxed.exe/
    └── %DEFAULT FOLDER%/
        └── resources/
            └── resource2.dat

Here's the situation: original.exe requires both resource1.dat and resource2.dat to function properly. I have created a boxed.exe from original.exe, which packs a different version of resource2.dat (same name, different content).

My intention is that when running boxed.exe, it should use the updated resource2.dat from its own directory, while still accessing the unchanged resource1.dat from the original directory. However, what I observed is that the entire ./resources directory seems to be replaced by %DEFAULT FOLDER%/resources, meaning boxed.exe can only see the updated resource2.dat and cannot find resource1.dat.

I am trying to understand whether this observation is accurate, or if I might have made an error. If this is how the environment is designed to work, are there any workarounds that would allow boxed.exe to access both the updated resource2.dat and the untouched resource1.dat? Thank you for your help.

Hi, structure of the files you specified is correct, and your expectations are also correct.

If there are files in the virtual and real folder, like you have in folder "resources" then the results will be added up. So when packed, your file will see both resource1.dat and resource2.dat in resources folder.

If there are files with the same name in virtual and real folder, then the one that virtualization peeks depends on a virtual file properties:
- if virtualization method is specified to "Never write to disk", then virtual resource2.dat will be taken
- if virtualization method is "Never write to disk (Use file from disk if exists)", then resource2.dat from real folder will be taken.
I'm not talking about virtualization methods like "Write to disk", I believe this is not what you are looking for.

If the behavior of your packed program is different, then this is unexpected and probably, shows a bug or a wrong configuration. If you are sure this is a bug, then we need your files to check it out to find the problem.