danreeves / path-clean Goto Github PK

39.0 4.0 9.0 28 KB

A Rust implementation of `cleanname` or `path.Clean`

License: Apache License 2.0

Rust 100.00%

path-clean's Introduction

path-clean

Installation

cargo add path-clean

Usage

use std::path::PathBuf;
use path_clean::{clean, PathClean};
assert_eq!(clean("hello/world/.."), PathBuf::from("hello"));
assert_eq!(
  PathBuf::from("/test/../path/").clean(),
  PathBuf::from("/path")
);

About

path-clean is a Rust port of the the cleanname procedure from the Plan 9 C library, and is similar to path.Clean from the Go standard library. It works as follows:

Reduce multiple slashes to a single slash.
Eliminate . path name elements (the current directory).
Eliminate .. path name elements (the parent directory) and the non-. non-.., element that precedes them.
Eliminate .. elements that begin a rooted path, that is, replace /.. by / at the beginning of a path.
Leave intact .. elements that begin a non-rooted path.

If the result of this process is an empty string, return the string ".", representing the current directory.

It performs this transform lexically, without touching the filesystem. Therefore it doesn't do any symlink resolution or absolute path resolution. For more information you can see "Getting Dot-Dot Right".

For convenience, the [PathClean] trait is exposed and comes implemented for [std::path::PathBuf].

License

MIT OR Apache-2.0

path-clean's People

Contributors

Stargazers

Watchers

Forkers

heyimalex rcook basile-henry safai-labs jerrywu1234 foo-jin nethunterslabs adamreichold principis

path-clean's Issues

LICENSE-APACHE file does not contain the Apache-2.0 license

Hi, I'm trying to package path-clean for Fedora. During the review process it was pointed out that the LICENSE-APACHE file only contains the header, but not the Apache-2.0 license itself, as is required.

You can get the full license from here. Replacing the file would suffice. Thanks in advance!

Is this safe?

Hello,

There is ongoing discussion for sanitizing paths in typst, I was wondering if you consider this implementation to be acceptable as a safety feature? For example to check whether a script is trying to access a file outside of the predetermined root directory?

Thanks in advance,

Dherse

Path containing back slashes and forward slashes is not cleaned

This pathbuf is not cleaned on windows:

PathBuf::from("/dir\\../otherDir/test.json").clean()

Remains as:

/dir\../otherDir/test.json

Workaround:

PathBuf::from(file_path.to_string_lossy().replace("\\", "/")).clean()

Don't assume valid UTF-8

Currently, your clean function requires &str and your trait just throws out any paths containing invalid UTF-8.

Given how easily one can have invalid UTF-8 on POSIX platforms from mojibake in filenames (eg. Load data onto a mobile device that uses latin1 on-disk using its USB Mass Storage Device mode, then pull the SD card out and plug it into a UTF-8 Linux device directly), this makes it of very limited use. (And Windows also allows unpaired UTF-16 surrogates in filenames for historical reasons.)

The proper solution would be to use the Path::components iterator so you don't need to convert to &str to match on component types or, for that matter, even think about what path separator the platform is using.

You'd just get a sequence of Prefix(PrefixComponent) (Stuff like C: or \\server\share), RootDir, CurDir, ParentDir, and Normal(&OsStr) values, and it'd collapse away //, /./, and trailing / and /. for you.

(That'd also allow you to eliminate an unnecessary intermediate copy in going from PathBuf to &str, since you can just impl your trait on Path.)

clean("c:/temp/..") results in "c:", not "c:/"

You would expect "c:/temp/.." to be normalized to "c:/", but it results in "c:". "c:" does not mean the root of windows file system, but rather current directory in drive c:.

    let buf = clean("c:/temp/..");
    assert_eq!(buf, "c:");

Consider adding #![forbid(unsafe_code)]

cargo-geiger marks crates in one of three ways:

Red for crates using unsafe and, thus, in need of more careful and skilled auditing.
Uncoloured for crates wth no unsafe
Green for crates which use #![forbid(unsafe_code)]

Given that the point of path-clean is to "[perform] this transform lexically, without touching the filesystem" (unlike normpath which depends on GetFullPathNameW on Windows), adding #![forbid(unsafe_code)] as an additional indicator of the intent to do it without FFI calls seems like a good idea.