They're kind of terrible, and I think I have a better scheme now:

• app_dir -> ensure_app_dir
• get_app_dir -> compute_app_dir

Discussion is very welcome...

The function utils::sanitized mistakenly disallows periods in directory names.

std::path::Path is the standard library's way of storing immutably borrowed paths. sanitized, app_dir and get_app_dir, however, use normal borrowed strings and try to enforce path separators via documentation, which is severely unidiomatic.

Prevent compilation errors on non-supported platforms by always returning NotSupported.

Include every platform and data type. Big table!

I don't think I see this feature anywhere? I read the source and it says it's disabled on *nix because specs don't require it. I'm learning Rust and porting a DLang application and all my DLang applications us

.config/<Author>/<Application>

Thanks!

❯ rustc -V
rustc 1.25.0-nightly (79a521bb9 2018-01-15)

I receive the error

error[E0619]: the type of this value must be known in this context
  --> /Users/tylerthrailkill/.cargo/registry/src/github.com-1ecc6299db9ec823/app_dirs-1.1.1/src/imp/platform/macos.rs:10:40
   |
10 |         Ok(Component::RootDir.as_ref().into())
   |                                        ^^^^

error: aborting due to previous error

error: Could not compile `app_dirs`.
warning: build failed, waiting for other jobs to finish...
error: build failed

when attempting to compile my application using app_dirs with 1.25.0-nightly

Often command line tools on macOS use unix locations for dotfiles, I essentially never look in ~/Library/ to configure my tools. Because of this, I've avoided this crate for my personal projects because I want my dotfiles in ~/.config. Being able to configure this would make this much more useful to me.

Hi,

Would it be possible to add a temporary folder to this package?
This is not part of the XDG Base specification but would be very usefull to have in a cross-platform setting.

On Windows, AppData may be synced over the network on login/logout. Because of this, it is not recommended to store large user data in it and instead only store small config data. Since there is a separate entry for UserConfig, I believe the correct place for UserData is in LocalAppData (where you currently put UserCache).

This user on Reddit has an example of when using the first thing returned by XDG isn't a good idea. Perhaps we could check each path it returns and choose one based on some heuristic? Investigate...

On Windows, shared data should go in %ProgramData%. I don't remember the programmatic name off hand (on my phone at the moment), but it does have one.

Hey,

Is it possible to have xx/Appname not xx/Author/Appname ?

Thanks

Technically, this is the official way to get system paths, rather than reading from %[LOCAL]APPDATA%.

• There's a wrapper around SHGetKnownFolderPath in the shell32-sys crate.
• It seems that KNOWNFOLDERID values (i.e. FOLDERID_{Local,Roaming}AppData) aren't currently available in any Rust crate, but the constant values are available in the Windows documentation.
• Here is an example of how this could be implemented. Super ugly, but it is technically the "proper" solution...

Gotta love Windows. 😐

• get_app_file would be identical to get_app_dir.
• app_file would:
  • Call create_dir_all on the path's parent.
  • Call OpenOptions::new().create(true).append(true).open on the full path.
  • Return the full path.
• Could definitely consider combining get_app_dir and get_app_file into get_app_path and deprecating the old names. But I think that confuses the API. Even if the difference between get_app_dir and get_app_file is purely semantic, it's good (IMO) to mirror the difference between app_dir and app_file.

If we can resolve the mixed slashes issue on Windows, we should make [get_]app_dir generic over P: AsRef<Path>.

Some of us want to make a library that uses app_dirs to manage data but lets the user of the library specify the strings for the application using it. Forcing this to be a &'static str instead of a String is a pain and also seems to not really gain us anything.

The AppInfo struct stores the &'static str type, which fails miserably if any of the fields are borrowed from an owned String. It should be changed to use an explicit generic lifetime parameter and store the string slices with that lifetime.

Seriously, the current tests are test is useless 😛

Clicking at [src] in the documentation does not show any special handling of things like

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9

(source)

Note that it can also be complexier like aux.txt

Is it because of online documentation isn't for windows or it is not handled?

I am porting my apps to the new winapi for better compile times, but I am still compiling the old winapi one for this dependency. Can we get this updated?
https://retep998.github.io/blog/winapi-0.3/

I have no idea if this is even plausible, but it'd be cool 🎉

The documentation for get_app_dir claims that it "[r]eturns (but does not create)" the path. However, its implementation calls get_root which does in fact create the path anyway. The other getters have similar problematic code.

This will create unexpected stray directories and/or fail when $HOME is not actually set to the user's home directory, such as when the environment has been cleared with env -i.

I think trying to use this on Android would activate the unix branch and try to use the XDG spec... which I'm pretty sure that Android doesn't follow. 😱