Determine application storage directory

I've asked this earlier: Self app directory

To sum it up, you can't directly know which is the proper storage directory of a specific application in a Cargo project. You're able to do this:

  • Get the path of the application executable
  • Get the user documents directory
  • Get the data directory

2 problems:

  • Rust std::fs or std::path aren't aware about which is the application Id. The application Id will be determined at the project settings. Not sure, but one of the replies to my earlier topic above show it's possible to get the crate name. But the crate name isn't the proper project Id (which usually contain dot-delimited parts for most platforms). For example, it might be or Qux/FooApp.
  • The proper base directory isn't necessarily the user documents directory (this will vary based on target OS).

I'm familiar with Adobe AIR SDK (ActionScript). There they support app: and app-storage: URLs for referring to application files. In Windows, at least until Windows 11, the app storage directory looks like C:/Users/foo-user/AppData/Roaming/ In Android, IIRC it's either /data/ for installation directory and /sdcard/Android/ for storage directory.

I want to develop a SDK for taking care of this, however, the solution I'm planning will create this file at the Cargo project:

  • src

The logic is, will invoke flx_setup::setup(). will be initialized with empty code and change everytime the application is compiled (to adapt the current project Id to the application directory variables), debugged and exported to desired platforms. However, I'd like to add to .gitignore, but if I do this, will have an error saying doesn't exist.

This is what looks like:


use flxsdk::filesystem::{
    // these variables are for internal use only

pub fn setup() {

extern crate lazy_static;

mod flx_setup;

pub mod localization;

pub fn main() {
    // do not modify this line

How can I somehow hide flx_setup?

cargo build scripts are the blessed way to generate rust source files during builds in cargo. You can take a look at this bindgen example to see how code is generated by the build script, and how the normal file can then include the generated code

Users of your crate would create a build script that depends on your codegen crate, and then include the generated code in their crate.

If procedural macros have access to all the information you need, that would be easier to set up for end users since they wouldn't need to configure a build script for their project.

1 Like

Oh! That makes sense!

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.