I am curious if you would be willing to add some default implementations to this crate to allow for compilation on unknown targets?

These implementations could panic on use but would allow this crate to compile.

The reason I bring this up is that there seem to be a few libraries that are exposing this crate even though they aren't using the functionality. For example mdbook depends on handlebars (with default features) which depends on walkdir which depends on this crate. That means if I wanted to use the structs exported by the mdbook library in a project that is compiling to say wasm32-unknown-unknown the compiler stops me. This specific example could be solved by getting mdbook's handlebars dependency updated to use the no_dir_source feature but since this isn't the first time I've run into this problem I thought it might be worth exploring solving it at this level.

In most situations there would still be an issue at a higher level but it would at least alleviate a small amount of pain.

Relevant API Guidelines:

• Panic Docs
• Destructors never fail

The win implementation of Handle calls unwrap in the following methods:

• Drop::drop
• AsRawFd::as_raw_fd
• IntoRawFd::into_raw_fd
• as_file
• as_file_mut

These calls should either have a comment inline documenting why they can't fail, or a Panics section should be added to the docs documenting when they will fail.

The libz blitz evaluation is finished 🎉 (a big thanks to everyone who contributed!). I guess the next steps are:

• Final pass over documentation
• Changelog (#13)
• Release 1.0

Does that sound right to you @BurntSushi?

Relevant API Guideline

Add an Errors section to the same_file function.

See the API Guidelines above for some inspiration.

Relevant API Guideline

Implement the Hash trait for Handle. See those docs for more details about how to implement Hash.

The MIT license at least requires publishing with the source code to really be in effect. Although I believe you don't need to include a copy of the Unlicense, it would be nice to include it as well.

Also, there's a COPYING file that contains the BSD-3-Clause, is that intended to be part of this repository, or just leftover from the initial setup (I notice that it was introduced in the first commit and the readme included it, but the first commit also had Unlicense/MIT in the Cargo.toml and the readme was changed very soon after).

How to reproduce:

1. Create named pipe: mkfifo my_pipe

2. Execute following program:

   use same_file::is_same_file;
   
   fn main() {
       let r = is_same_file("/path/to/my_pipe", "/path/to/my_pipe");
       println!("{r:?}");
   }

The program prints nothing and does not exit.

same-file: 1.0.6
rustc 1.58.1 (db9d1b20b 2022-01-20)
Linux 5.16.5-arch1-1 x86_64 GNU/Linux (Arch Linux)

Before the stable release, we should do a full pass over the crate documentation and make sure:

• There aren't any grammatical errors in the prose
• It all flows nicely
• The examples are easy to follow and all make sense
• The links to other items all work

error[E0433]: failed to resolve. Use of undeclared type or module `imp`
   --> C:\Users\harmony\.cargo\registry\src\github.com-1ecc6299db9ec823\same-file-1.0.3\src\lib.rs:105:19
    |
105 | pub struct Handle(imp::Handle);
    |                   ^^^ Use of undeclared type or module `imp`

version

nightly-x86_64-pc-windows-msvc (default)
rustc 1.30.0-nightly (39e6ba821 2018-08-25)

Relevant API Guidelines:

• Panic Docs
• Destructors never fail

The unix implementation of Handle calls unwrap in the following methods:

• Drop::drop
• AsRawFd::as_raw_fd
• IntoRawFd::into_raw_fd
• as_file
• as_file_mut

These calls should either have a comment inline documenting why they can't fail, or a Panics section should be added to the docs documenting when they will fail.

Relevant API Guideline

The API Guidelines recommend tracking changes between crate versions in release notes. I imagine you'll have some idea of how you want to do this already @BurntSushi.

I need to compare Handle values between program runs.

Constraints

• I can’t store file paths but do store metadata as contained in a Handle value (perhaps except the file field when it is Some).
• The program is cross-platform. Handle values need not be comparable across platforms. Handle values do need to be constructed using deserialization, across platforms.
• The theoretical issue that Windows file handles are only guaranteed unique as long as both are open is not prohibitive for me, assuming they do ‘tend’ to be unique and same-file has coded around this already using the file size metadata.

Proposal

Add a serde feature to enable this functionality.

Plan

After finishing discussion and getting a go-ahead, I’ll file a PR.

I have a samba share mounted with cifs-utils. I'm doing some file operations in the share and it is not case insensitive, which is fine. However, it seems like it uses virtual inode numbers because the Handles have different numbers. Here's a sample of the issue:

Handle { file: Some(File { fd: 3, path: "GoodFellas (1990)", read: true, write: false }), is_std: false, dev: 46, ino: 10248 }
Handle { file: Some(File { fd: 3, path: "Goodfellas (1990)", read: true, write: false }), is_std: false, dev: 46, ino: 11984 }

Only the "GoodFellas (1990)" directory exists, but both uppercase and lowercase paths work to access it. But they report different inode numbers, which makes this library report a false negative.

I'm not really sure if anything can be done about this...

The dev and ino methods on Handle are unix-only. This should be called out in the method docs.

Currently, Handle wraps a platform-specific implementation so I don't think we need an extension trait. Just mentioning that they're unix-only should be enough. But @BurntSushi might have other ideas.

Testing handle equality for file paths to streams works on Windows under cmd, however not from Powershell (tested with 5 and 6)

PS G:\dev\lib\same-file> cargo run --example is_stderr 2> examples/stderr
"examples/is_same_file.rs" is NOT stderr!
"examples/is_stderr.rs" is NOT stderr!
"examples/stderr" is NOT stderr!

I have two files both contains:

b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9

by invoking the assertion with is_same_file, error raises.

This is the tracking issue for the evaluation performed by the community over the last few weeks.

• Do a pass over documentation
• Clarify Approach to comparing files in docs
• Add examples to public methods on Handle
• Add Errors Section to methods on Handle
• Add Errors Section to same_file method
• Replace try! with ? in examples
• Note why Handle methods in unix won't panic
• Note why Handle methods in win won't panic
• Add hyperlinks to items in docs prose
• Implement Hash for Handle
• Ensure Handle is Send + Sync
• Add html_root attribute
• Note that dev and ino methods are unix only

Also part of the libz blitz but not really a contribution opportunity:

• Start tracking release notes for version bumps

Relevant API Guideline

Add assert_send / assert_sync methods and test Handle to make sure it stays Send + Sync.

See the API Guideline for an example of how to do this.

Relevant API Guideline

Add an example to the following methods on Handle:

• from_path
• from_file
• stdin
• stdout
• stderr
• as_file
• as_mut_file

I was checking out the source of this library purely out of interest, and while the comments and docs say at a few places that file size is compared on windows to avoid some false positives, this does not actually seem to be the case.

The key used for comparison on Windows is

struct Key {
    volume: u64,
    index: u64,
}

which does not include the file size, nor could I find any other place where file size is taken into account.

Hi! It seems that the Eq trait is erroneously defined on win::Handle (and thus on the top-level wrapper struct).

The comments mention the following:

        match file_info(&file) {
            Ok(info) => Ok(Handle::from_file_info(file, true, info)),
            // In a Windows console, if there is no pipe attached to a STD
            // handle, then GetFileInformationByHandle will return an error.
            // We don't really care. The only thing we care about is that
            // this handle is never equivalent to any other handle, which is
            // accomplished by setting key to None.
            Err(_) => Ok(Handle { file: Some(file), is_std: true, key: None }),
        }

If the Err branch is hit, we'll produce a struct that doesn't satisfy the Eq requirement that a == a.

I'd suggest either:

1. Removing the impl. This seems less desirable as it would be an externally breaking change.
2. Altering the PartialEq::eq implementation to look at the file and is_std fields iff the key is None for both self and other.

I'm happy to write the pull request but I'm unsure which direction you'd prefer.

Relevant API Guideline

Add an Errors section to the following methods on Handle:

• from_path
• from_file
• stdin
• stdout
• stderr

See the API Guidelines above for some inspiration.

Remove unnecessary any(target_os = "redox", unix), change to just unix.
This used to be necessary, but in 2019 Redox became unix-family.

Sorry to be opening an issue for a question. I was curious why this library exists compared to std::fs::canonicalize, which has the guarantee of Rust to return the real path. Is it a race condition commentary where

• open file
• move file
• move other file to that location

would cause distinct files to return as matches due to having the same path across time, an edge case this lib handles? What stronger guarantees exactly does this library aim to offer?

This may benefit from a follow-up to the README clarifying its utility.

This panics:

std::os::unix::io::IntoRawFd::into_raw_fd(same_file::Handle::stdin().unwrap())

The Option<File> field is treated carelessly, and so the reassuring “unwrapping won’t panic” comment in the Drop implementation is wrong.

Really, Option is the wrong tool to use here; it should be ManuallyDrop these days (✓ available within the current MSRV).

The config files for Travis and AppVeyor currently only test the crate on Windows and Linux.

It looks like Travis can do osx buids.

Relevant API Guideline

Make the following item references in the docs links:

• is_same_file from crate root docs
• examples/is_stderr.rs example source from crate root docs

The crates.io badge in the Readme (http://meritbadge.herokuapp.com/same-file) no longer loads.

Relevant API Guideline

Replace try! and unwrap with ? in the two crate root examples.

See the API Guideline for an example of how to do this.

Both the inode and device numbers are u64 on unix like systems.

On windows, you can get the BY_HANDLE_FILE_INFORMATION structure which returns:

• dwVolumeSerialNumber: The dword of the volume (device)
• nFileIndexHigh: The high-order part of a unique identifier that is associated with a file.
• nFileIndexLow: The low-order part of a unique identifier that is associated with a file.

It would be nice, if possible, if same-file could map:

• dwVolumeSerialNumber todev()
• nFileIndexHigh << 32 | nFileIndexLow to ino()

This would mean that you could have an analogue of inodes on windows with this library. Alternatively, maybe exposing these as their own functions to ensure they are explicitly windows only values.

Relevant API Guideline

Add a html_root attribute to lib.rs that points to "https://docs.rs/same-file/1.0.0".

Clarify the statement about false positives a little more in the crate docs for the same_file method. This should be enough to encourage users to check the implementation if they have specific requirements, but not complicate things for users who aren't concerned.