As we all know, file copying on Linux has long relied on the classic cp command, which remains reliable but offers little feedback and limited control over long or complex operations.

To address this, a promising new Rust-based command-line tool called cpx emerge, designed as an alternative rather than a replacement, that approaches the same task with a focus on performance, visibility, and configurability.

It targets scenarios where large directory trees, interrupted transfers, or the need for detailed progress reporting make standard tools less convenient to use. The project is currently Linux-only and leverages modern kernel features to improve copy throughput and reliability.

you are viewing a single comment's thread
view the rest of the comments
[–] 21 points 9 months ago (17 children)
  • [–] 15 points 9 months ago (9 children)

    It's a damn pain to remember all the flags. How many flags can a program friggin have? I'm always afraid that some flag I enter will reverse the sync and delete everything in the source folder because the target is empty.

    I use rsync only when all params have been reseasrched and tested. cpx presumably just requires cpx - r source target instead of 5 rsync flags.

  • source
  • parent
  • hideshow 9 child comments
  • [–] 7 points 9 months ago (2 children)

    What 5 flags did rsync need? I always just do -av and go about my day. And the -v is kinda optional.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 11 points 9 months ago* (last edited 9 months ago) (4 children)

    The only one you need is -a. -avz if you want verbose and compression.

  • source
  • parent
  • hideshow 4 child comments
  • [–] 3 points 9 months ago* (2 children)

    I just looked it up and - x means one filesystem. But does - v give you a progress bar or just a lost of stuff copied?

    IIRC rsync also treats the trailing slash in a special manner that I always have to look up.

  • source
  • parent
  • hideshow 2 child comments
  • [–] 4 points 9 months ago

    The trailing slash is just following cp's own special treatment

    
    # before
    dir/
        file1
    target/
        orig.txt
    
    
    
    # no trailing slash - copy *dir* to target
    cp -r /path/to/some/dir /my/target
    
    # after
    target/
        orig.txt
        dir/            # dir copied to target
            file1
    
    
    
    # with trailing slash - copy *contents* of dir to target
    cp -r /path/to/some/dir/ /my/target
    
    # after
    target/
        orig.txt
        file1            # contents of dir
    
    
  • source
  • parent
  • [–] 3 points 9 months ago (3 children)

    I've had cp aliased to rsync with my flags for years. It seems like a lot of newcomers try to "fix" stuff before they really understand what's available. Or they just like to play around with different programming languages. Which is fine, but usually it's not really interesting to me.

  • source
  • parent
  • hideshow 3 child comments
  • [–] 0 points 9 months ago (2 children)

    you seem to have added a condescending comment before you understood the goals. 2-5x speedup over rsync (their benchmarks, but still) seems significant on its own, and an interface that doesn't require aliasing to be useful is also nice

  • source
  • parent
  • hideshow 2 child comments
  • [–] 0 points 9 months ago (1 child)

    Nope, thanks for projecting though. I just didn't mention the multi-threaded because, again, it doesn't speed up anything. Transfer speed has always been the bottleneck, unless you're talking about heavy data-center type use. Like I said, if it's interesting to you, go for it. I don't see a need to reinvent the wheel on core utilities.

  • source
  • parent
  • hideshow 1 child comment