Rust-Path abs: path_abs — Absolute serializable path types and associated methods.

path_abs: ergonomic paths and files in rust.

Build Status Build status Docs

This library aims to provide ergonomic path and file operations to rust with reasonable performance.

See the library docs for more information


The source code in this repository is Licensed under either of

at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.


  • Internationalization (i18n) support
    Internationalization (i18n) support

    Aug 13, 2018

    There's two aspects of internationalization relevant to path_abs:

    1. It should be possible for path_abs to present its own error messages (and other human-readable text) in the user's language, instead of hard-coding specific English messages.
    2. path_abs should not depend on the exact text of error messages from the underlying operating system, since they can vary.

    For path_abs' own error messages, the biggest offender is probably the Error::action() method which returns a string. Possibly this could be replaced with an enum, patterned after std::io::ErrorKind. There may be other issues; the code should probably be audited.

    For errors from the underlying operating system, currently the only dependency I'm aware of is the test "sanity_errors", which could be amended by checking error fields individually rather than formatting the error and checking the resulting string. Again, there may be other issues and the code should probably be audited.

  • Inherent methods for PathOps and PathInfo
    Inherent methods for PathOps and PathInfo

    Jul 16, 2019

    It feels extremely silly to have to import traits to get methods that could sensibly be provided on the types themselves, especially traits that have so many methods (PathInfo), and especially when I have no intention to use the traits generically. (I already have my own trait with a method named join, and importing yours would cause a conflict)

    Most notably:

    • {PathAbs,PathDir}::{join,concat}
    • {PathAbs,PathFile}::{file_name,with_file_name,with_extension} (and maybe stuff for PathDir; though the term base_name might be cause less confusion than file_name)
    • PathAbs::{exists,is_file,is_dir,parent...}... in fact, nearly all of the Path methods are useful for PathAbs, making it really hard for me to see why you removed impl Deref for PathAbs. Maybe Target=PathArc was too much, but isn't at least Target=Path reasonable?
  • WIP: Monotonic path handlng
    WIP: Monotonic path handlng

    Jun 18, 2018

    Adds a "monotonic_path_preview" module containing my monotonic path handling code, for ease of review, as requested in #17. The module is made public, so the documentation can be viewed with cargo doc.

  • Add PathArc::absolute() tests
    Add PathArc::absolute() tests

    Aug 8, 2018

    This PR adds a bunch of tests for PathArc::absolute(), in various situations: on POSIX, on Windows when the current directory is a regular path (C:\), and on Windows when the current directory is an extended-length syntax path (\\?\C:\).

    I made this as a separate PR for a few reasons:

    • to get feedback on the somewhat unusual way I've laid out the tests
    • so that a future PR for issue #21 can highlight behaviour changes by changing these tests
    • to find out whether these tests will pass on AppVeyor the same way they passed in my VM. :)

    This PR also adds some "TODO" comments to tests that I've observed to fail in various environments, just for completeness.

  • Moving/copying/removing a symbolic link
    Moving/copying/removing a symbolic link

    Feb 18, 2018

    (I wish GitHub provided a better way to have discussion other than opening a bug report)

    Let's talk symlinks.

    I have an application which has historically taken the easy way out of path management by changing the current directory. In moving away from this setup towards a more principled design, I considered using path_abs as a means of leveraging the type system to ensure that I don't accidentally leave behind any lingering relative paths.

    Reviewing the documentation, however, it is evident to me that my mental model of symlinks differs from that of the library. Of course, this is to be expected; I understand that PathAbs is opinionated, and that our ideas will inevitably clash somewhere.

    But with regard to symlinks specifically, I find the model presented by this crate to be dangerous, and quite scary! I'd like to hear your point of view on this, and I wonder if there is something I am missing.

    I'll describe these clashing models by making analogy to Rust's borrow semantics.

    To me:

    • A directory in the filesystem is like some Box<_> type. It has a unique owner (its "true" parent) and that's the only way you can move or delete it.
    • A file in the filesystem is like some Arc<_> type. It may have multiple owners via hard links, and dies when the last link vanishes.
    • A symlink is like some *mut _ type. It can change data belonging to its target, but only if you explicitly dereference it (by joining another path component). The pointer itself does not own its target, and its target might not even exist.

    In PathAbs:

    • by immediately resolving symlinks, PathAbs makes symlinks feel more like C++'s mutable references. A symlink is the directory or file it points to. To me, this is terrifying, because if I'm not careful, then code which was intended to delete a symlink could end up accidentally recursively deleting its target!

    What do you think of this? Do you disagree with this risk about deleting a symlink? Is there room in PathAbs for symlinks to live as first class citizens? Am I asking too many questions? :stuck_out_tongue:

  • Help in handling weird join behavior
    Help in handling weird join behavior

    Mar 24, 2018

    @soc left a comment here and I wrote a quick script to demonstrate the problem:

    Joining: a with b
    Result : a/b
    Joining: a/ with b
    Result : a/b
    Joining: /a with b
    Result : /a/b
    Joining: a with /b
    Result : /b
    Joining: /a with /b
    Result : /b

    This is indeed bizare and an issue I think path_abs might be able to help with.

    The issue with "joining not compiling" is that the API for most path operations takes in AsRef<Path>. I think you would agree that both RelativePath and AbsolutePath should be AsRef<Path>, right? This makes the issue harder as I'm not sure of a way to disallow a certain type in rust (please let me know if there is a way).

  • test assumptions about windows
    test assumptions about windows

    Mar 24, 2018

  • WIP #6: add absolute() method on PathArc, still need tests
    WIP #6: add absolute() method on PathArc, still need tests

    Mar 22, 2018

    This is a first attempt at implementing #6.