Both are quite naive Errors I must say. The good thing about Rust is that it doesn't hide the complexities of the file system from you — it requires you to explicitly handle the edge cases. OR you know, you could just write a cp that panics when there is a PermissionDenied because you decided that never happens and happily unwrapped the Result.

The last one is a different kind. Rusts std lib indeed cannot stat . Which means they would have to translate . into the coreutils meaning manually. Their tests should have cought that one tho.

> Rusts std lib indeed cannot stat .

But the kernel can! I mean, stat() isn't a standard library function, it's a system call with (reasonably) well-defined semantics. And "." is a valid path, which returns a valid struct stat block representing a guaranteed-valid (cwd is always live; you're always "somewhere" even if the filesystem has removed the directory) directory.

Coming at this from the perspective of "translate . into the coreutils meaning" is almost certainly the wrong way to think about it. It's rust that has the broken picture of the filesystem environment, coreutils is just doing unix.

On Linux.

This isn't a Linux project, it is a cross-platform project.

No, stat() of "." predates linux by almost two decades. And coreutils is a set of unix tools. You can build them on other systems, but only via emulation layers that are reponsible for handling the friction (and those layers would likewise be subject to this same logic).

Or I guess what you're saying is that uutils is a cross platform project? Which is true enough, but it's still responsible for faithfully representing the behavior of the underlying system. And when running uutils on linux, stating "." (in this case to detect that src and dst are the same file) is legal and valid.

It's true there are other ways to solve the same problem than emulating a linux syscall layer, but you have to pick one. You don't get to use "the standard library can't stat ." or "we have to run on windows" as an excuse.

Nobody is saying this is not a bug. I am saying that "It's rust that has the broken picture of the filesystem environment" is not true in any way. Rust implements a cross-platform filesystem API. The fact that it does not work the same way as the Linux kernel does not make it "broken".

That's a little out of context. The situation being described[1] is that "rust cannot stat the path '.'". A core requirement of coreutils is to work with a unix filesystem where "." is a valid path. Ergo, from the point of view of the requirements at hand, the rust filesystem layer is "broken". It doesn't do what uutils needs it to do.

[1] And I'll admit that I don't have any understanding of the actual low level issue here or why native pathnames are being interpreted by the runtime and not passed through to the OS layer.

Because if you just pass them through, you will not have consistent behaviour across platforms. That was the original point: Rust implements a consistent, cross-platform filesystem API. It does not necessarily match whatever your platform happens to do.

But uutils needs to necessarily match whatever your platform happens to do, or else it breaks[1] in silly ways like this when it turns out that "." stops being a path.

[1] Maybe this is all just a semantic argument about this use of the word "broken"? This is a long-standing usage. It doesn't mean that Rust's standard library isn't useful for anything, it means that it isn't useful here because of design choices that don't match the problem at hand. If it were something that can be fixed, it would just be "buggy". But it can't (for the reasons you mention!). Therefore it's "broken", not "buggy".

What do you mean with "Rusts std lib indeed cannot stat ."? I wasn't able to find something related to this on the web.

I'm not sure what they mean either, this seems to succeed: https://play.rust-lang.org/?version=stable&mode=debug&editio...

Note that in the readme `cp` is listed as semi-done.

Wtf is "semi-done"?

There is "done" and there is "not done"...

I imagine "semi-done" means "works enough that it can be dogfooded by the devs and tried out by the curious among us, but does not exactly mirror behaviour of GNU cp in terms of corner cases and error output".

I think we need to be more flexible than classifying things as done/not-done. Even GNU coreutils has open issues[0] - is it "done" or "not done"?

[0] = https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=coreutils

If that's how you categorize software, then no software has ever been "done". There are always new cases, bugs, features, and performance improvements. You will never run out of any one of those things.

In this case, semi-done probably means what it usually means: some common cases are handled, while others aren't yet.

if you believe that, there is not a single piece of done software in the world, besides perhaps tex.

"semi-done" means:

1. Not done. :-(

2. A lot has been done already, i.e. not just-started.

3. Not almost-done, i.e. there's significant work still to be done

In that case at least one of "done" and "not done" needs to be a spectrum; semi-done is a point on one of those spectra

You think that's confusing? Wait until you hear about half "A" presses.

Portions of code could be completed and others are not? See semifinished.

WIP? Dude, chill… you’re not paying for it

Could not get mv to fail as you did on the Mac or Linux. Would you re-run with the latest bits and let me know what your platform is? I am going to fix these two bugs, if they still exist.

Are you running an irregular version of libc? Something else unusual?

Same with cp. Could not reproduce on the Mac or Linux.

So it doesn't work for cases where it shouldn't work. And it errors out but doesn't do anything stupid

I don't see the problem for something that was just released as a very preliminary version

(Though I don't know where cp is getting "PermissionDenied" from)

> I don't see the problem for something that was just released as a very preliminary version

Fwiw the project os half a decade old.

> (Though I don't know where cp is getting "PermissionDenied" from)

Have not looked at the problematic code but e.g. copy_file_range(2) says

> EPERM fd_out refers to an immutable file.

While that is a good point, it is quite unsightly to panic from unwrapping. Instead it should propagate that error back to the top level where a nicer error message can be generated.

More importantly cp should continue copying other inputs even if one of the source files fails to be readable. Handling errors by panic doesn't suggest that will be the case.

I don’t know if that is _more_ important, but I agree that it is also important :)

The reason I say this is that while users will expect this behavior, doing it well (so that it can be parallelized, for example) requires careful thinking about how errors should flow, how lines are printed to stdout, etc.