How do I remove my file paths inside the release version of the executable?

On Windows if I run cargo build --release, it doesn't remove my file path if I were to open the executable in notepad and to search up my file path. I wish to strip off such information, is there a way to do so?

You need to use --remap-path-prefix,

To do so you'll need to create a config file. E.g. from the command prompt:

mkdir .cargo
notepad .cargo/config.toml

When notepad opens up enter this:

rustflags = ['--remap-path-prefix', 'C:\path\to\folder=.\']

Replace C:\path\to\folder with the folder you want to remove. You can also change .\ to a fake folder.


I think these folder path it stores inside the executable it has got to do with debug related information in the event my program decides to panic.

I want to completely remove all of this when releasing my executable. How would I do so?

Did you try the recommendation above? What have you got? Did it not work?

I want to completely remove all this debug stuff, this includes the folder/file path. I am not looking to change the file path, I want to completely remove all this debug related stuff.

Then it's that question you're really interested in, not this?

1 Like

"Debug related stuff" appears in panic error messages. You cannot remove these error messages, short of not panicking.

However, the remap-path-prefix allows editing these messages such that the real path does not appear.

Is it possible to complety remove/disable panic!?

Are you looking for this place in Rust book?

I added this:

panic = 'abort'

I did this, but why would my file path still be included in my executable? Shouldn't that be stripped off?

Setting panic = "abort" disables unwinding, but it doesn't change the default panic hook, which still prints the same output to the console whether unwinding is enabled or not. You can use std::panic::set_hook to override this behavior.

1 Like

Sorry mate but what does "unwinding" even mean?

Where would I place this code? Is it in the or cargo.toml?

See the link posted by @Cerber-Ursi above.

It’s a function, so you’ll need to write code that calls it, probably at the very start of your main function. Note that this will change the behavior of panics, but I doubt it’ll eliminate all filenames from your binary.

What is your goal? If it”s binary obfuscation, you should probably use a tool specifically designed for that. The Rust toolchain doesn’t have any sort of built-in obfuscation support.

Why would Rust still put these information into the binary? Wouldn't it waste more storage space and slow the program down?

I just want to remove anything useless and I am not too sure why Rust wants to include these file path information?

rustflags = ['--remap-path-prefix', 'C:\soemthing\=.C:\something']

So I added this, I compiled via cargo build --release and still my file path is inside the binary.

Hey bud,

Try this is you are in a Unix system.

Build the release and then run strip on the binary. I think that removes all symbols used for backtraces.

it works well on Linux I have tired this for myself.

But if you have an idea how to do this on Windows, that will be great. Also strip always complains with "unrecognized format" on Windows, not on Linux, so again if you have an idea how to strip debug related information on WIndows that will be great, thanks =D

Do you have any debug related information directly in .exe file? How did you find it?

Ok so after compiling it, you go to the executable, and then open it with any text editor.

here is a sample of it.

 called `Result::unwrap()` on an `Err` value                    cmd.exe/cecho%userprofile%Failed to execute command!E:

After the E: there is my full path to the executable.

On Linux if I do

fn main() {

And then compile it using cargo build --target x86_64-pc-windows-gnu --release, I do not get the full path of the source or executable in the resulting executable file. I only get src/ even when not using --remap-path-prefix.

Are you sure that your own code doesn't cause this? Only source paths should be added to the executable, not the path to the executable itself.