7 ms·

Gave it a whirl with `cp`: > ./target/debug/cp /dev/null /dev/zero thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1

Gave it a whirl with `cp`: > ./target/debug/cp /dev/null /dev/zero thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', src/uu/cp/src/cp.rs:1295:54 Good advice is "don't panic." Trying `mv`: > ./target/debug/mv . . ./target/debug/mv: cannot stat '.': No such file or directory oof Anyways the point is that there's lots of legitimate institutional knowledge baked into coreutils and a naive RiiR effort will re-introduce previously fixed bugs.

atoav 5y ago
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.
- ajross 5y ago
  > 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.
  - user-the-name 5y ago
    On Linux. This isn't a Linux project, it is a cross-platform project.
    - ajross 5y ago
      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.
      - user-the-name 5y ago
        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".
        ajross 5y ago
        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.
        user-the-name 5y ago
        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.
- throwaway525142 5y ago
  What do you mean with "Rusts std lib indeed cannot stat ."? I wasn't able to find something related to this on the web.
  - steveklabnik 5y ago
    I'm not sure what they mean either, this seems to succeed: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=95d61719812e5a55a544c930659d39a3 https://play.rust-lang.org/?version=stable&mode=debug&editio...
raverbashing 5y ago
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)
- masklinn 5y ago
  > 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.
- db48x 5y ago
  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.
  - megous 5y ago
    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.
    - db48x 5y ago
      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.
rocqua 5y ago
Note that in the readme `cp` is listed as semi-done.
- bradwood 5y ago
  Wtf is "semi-done"? There is "done" and there is "not done"...
  - bastardoperator 5y ago
    Portions of code could be completed and others are not? See semifinished.
  - baq 5y ago
    if you believe that, there is not a single piece of done software in the world, besides perhaps tex.
  - smt88 5y ago
    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.
  - afiori 5y ago
    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
  - smcl 5y ago
    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 https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=coreutils
mustache_kimono 5y ago
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.
- mustache_kimono 5y ago
  Same with cp. Could not reproduce on the Mac or Linux.
- mustache_kimono 5y ago
  Are you running an irregular version of libc? Something else unusual?

atoav 5y ago

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.

ajross 5y ago
> 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.
- user-the-name 5y ago
  On Linux. This isn't a Linux project, it is a cross-platform project.
  - ajross 5y ago
    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.
    - user-the-name 5y ago
      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".
      - ajross 5y ago
        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.
        user-the-name 5y ago
        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.
throwaway525142 5y ago
What do you mean with "Rusts std lib indeed cannot stat ."? I wasn't able to find something related to this on the web.
- steveklabnik 5y ago
  I'm not sure what they mean either, this seems to succeed: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=95d61719812e5a55a544c930659d39a3 https://play.rust-lang.org/?version=stable&mode=debug&editio...

raverbashing 5y ago

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)

masklinn 5y ago
> 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.
db48x 5y ago
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.
- megous 5y ago
  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.
  - db48x 5y ago
    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.

rocqua 5y ago

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

bradwood 5y ago
Wtf is "semi-done"? There is "done" and there is "not done"...
- bastardoperator 5y ago
  Portions of code could be completed and others are not? See semifinished.
- baq 5y ago
  if you believe that, there is not a single piece of done software in the world, besides perhaps tex.
- smt88 5y ago
  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.
- afiori 5y ago
  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
- smcl 5y ago
  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 https://debbugs.gnu.org/cgi/pkgreport.cgi?pkg=coreutils

mustache_kimono 5y ago

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.

mustache_kimono 5y ago
Same with cp. Could not reproduce on the Mac or Linux.
mustache_kimono 5y ago
Are you running an irregular version of libc? Something else unusual?