supercilex / fuc Goto Github PK
View Code? Open in Web Editor NEWModern, performance focused unix commands
License: Apache License 2.0
Modern, performance focused unix commands
License: Apache License 2.0
If io_uring ever adds support for copy_file_range (splice doesn't do copy acceleration AFAIK), we should be able to use that to parallelize our writes.
I want to benchmark for some of windows default commands like rd
, robocopy
.
but I can't make it work because of error.
Benchmark 1: rmdir /S /Q D:/tmp/
Error: The preparation command terminated with a non-zero exit code. Append ' || true' to the command if you are sure that this can be ignored.
It works well with release files of this project, without rmdir lines in batch script.
Please help.
Not working code here.(windows batch script)
@echo off
for %%G in (0,1G) do (
for %%F in (10,10_000,100_000,1M) do (
hyperfine --warmup 3 -N ^
--export-markdown "benches/remove_%%F_files_%%G_bytes.md" ^
--export-json "benches/remove_%%F_files_%%G_bytes.json" ^
--prepare "ftzz g -n %%F -b %%G "D:/tmp/ftzz"" ^
"rmdir /S /Q "D:/tmp/"" ^
"./target/release/rm_stdlib "D:/tmp/ftzz"" ^
"./target/release/rm_rayon "D:/tmp/ftzz"" ^
"./target/release/rm_remove_dir_all "D:/tmp/ftzz"" ^
"./target/release/rmz "D:/tmp/ftzz""
)
hyperfine --warmup 3 -N ^
--export-markdown "benches/remove_100_000_files_%%G_bytes_0_depth.md" ^
--export-json "benches/remove_100_000_files_%%G_bytes_0_depth.json" ^
--prepare "ftzz g -n 100_000 -b %%G -d 0 "D:/tmp/ftzz"" ^
"rmdir /S /Q "D:/tmp/"" ^
"./target/release/rm_stdlib "D:/tmp/ftzz"" ^
"./target/release/rm_rayon "D:/tmp/ftzz"" ^
"./target/release/rm_remove_dir_all "D:/tmp/ftzz"" ^
"./target/release/rmz "D:/tmp/ftzz""
hyperfine --warmup 3 -N ^
--export-markdown "benches/remove_100_000_files_%%G_bytes_5_files_per_dir.md" ^
--export-json "benches/remove_100_000_files_%%G_bytes_5_files_per_dir.json" ^
--prepare "ftzz g -n 100_000 -b %%G -r 5 "D:/tmp/ftzz"" ^
"rmdir /S /Q "D:/tmp/"" ^
"./target/release/rm_stdlib "D:/tmp/ftzz"" ^
"./target/release/rm_rayon "D:/tmp/ftzz"" ^
"./target/release/rm_remove_dir_all "D:/tmp/ftzz"" ^
"./target/release/rmz "D:/tmp/ftzz""
)
```
I just accidentally deleted the contents of a directory instead of its symlink which seems pretty stupid. Check the behavior of every scenario that involves symlinks and figure out what the behavior should be. I'm leaning towards never follow symlinks.
cpz and rmz are very fast, but adding some eye candy like progress bar would be possible?
Thank you for your work on the rmz
utility.
Since on Ubuntu LTS 20.04 (focal) - and probably on its derivations, too - rust 1.61.0 is the only supported version, it would be nice to get the fuc compiled there as well. Right now it fails with something like "blabla requires rustc 1.63.0" or even 1.64.0 ...
Most implementations of cp
provide a -v
which prints out directories as they are created. i.e.:
$ tree
.
└── foo
├── bar
└── baz.txt
2 directories, 1 file
$ cpz -v foo backup/
foo -> backup/foo
foo/baz.txt -> backup/foo/baz.txt
foo/bar -> backup/foo/bar
This would be very useful for keeping track of what operations cpz actually performed. e.g. in case your shell glob pattern captured unintentional files)
Note: While most other cp implementations just output the paths directly to stdout, GNU cp also escapes each string so that non-printable characters and newlines are backslash-escaped (+the string is single-quoted). This gives the benefit that it's easy to copy some path from the terminal and call another command with it, even if it contains whitespace or special characters
Current thinking: no. It adds code bloat and all modern file systems support d_type. Open to changing my mind.
Symptoms will be attempting to delete a file that's actually a directory or copying a file that's actually a directory.
Follow-up from #15. This is on 1.1.7 with rust 1.68. As requested cargo install rmz cpz
:
[ 115s] Executing(%install): /usr/bin/bash -e /var/tmp/rpm-tmp.VtpYef
[ 115s] + umask 022
[ 115s] + cd /home/abuild/rpmbuild/BUILD
[ 115s] + /usr/bin/rm -rf /home/abuild/rpmbuild/BUILDROOT/fuc-1.1.7-3.1.x86_64
[ 115s] + /usr/bin/mkdir -p /home/abuild/rpmbuild/BUILDROOT
[ 115s] + /usr/bin/mkdir /home/abuild/rpmbuild/BUILDROOT/fuc-1.1.7-3.1.x86_64
[ 115s] + cd fuc-1.1.7
[ 115s] + unset LIBSSH2_SYS_USE_PKG_CONFIG
[ 115s] + [[ -z '' ]]
[ 115s] + CARGO_AUDITABLE=auditable
[ 115s] + CARGO_FEATURE_VENDORED=1
[ 115s] + RUSTFLAGS='-Clink-arg=-Wl,-z,relro,-z,now -C debuginfo=2 -C incremental=false'
[ 115s] + /usr/bin/cargo auditable install -j3 --offline --no-track --root=/home/abuild/rpmbuild/BUILDROOT/fuc-1.1.7-3.1.x86_64/usr --path . cpz rmz
[ 115s] error: could not find `cpz` in /home/abuild/rpmbuild/BUILD/fuc-1.1.7 with version `*`
[ 115s] error: could not find `rmz` in /home/abuild/rpmbuild/BUILD/fuc-1.1.7 with version `*`
[ 115s] Summary Failed to install cpz, rmz (see error(s) above).
[ 115s] error: some crates failed to install
[ 115s] error: Bad exit status from /var/tmp/rpm-tmp.VtpYef (%install)
Can be worked around with rpm.
If I try cargo install cpz rmz --locked
I see this
Downloaded rmz v1.1.1
Downloaded 1 crate (14.2 KB) in 0.21s
Installing cpz v1.1.1
Downloaded supports-color v1.3.1
Downloaded typed-builder v0.11.0
Downloaded is_ci v1.1.1
Downloaded thiserror-impl v1.0.38
Downloaded semver v1.0.16
Downloaded thiserror v1.0.38
Downloaded owo-colors v3.5.0
Downloaded clap2 v4.0.32
Downloaded fuc_engine v1.1.1
Downloaded error-stack v0.2.4
Downloaded os_str_bytes v6.4.1
Downloaded is-terminal v0.4.2
Downloaded once_cell v1.17.0
Downloaded anyhow v1.0.68
Downloaded rustix v0.36.6
Downloaded libc v0.2.139
Downloaded crossbeam-utils v0.8.14
Downloaded io-lifetimes v1.0.3
Downloaded linux-raw-sys v0.1.4
Downloaded terminal_size v0.2.3
Downloaded 20 crates (2.6 MB) in 0.55s
Compiling proc-macro2 v1.0.49
Compiling libc v0.2.139
Compiling unicode-ident v1.0.6
Compiling quote v1.0.23
Compiling syn v1.0.107
Compiling version_check v0.9.4
Compiling io-lifetimes v1.0.3
Compiling semver v1.0.16
Compiling rustix v0.36.6
Compiling linux-raw-sys v0.1.4
Compiling bitflags v1.3.2
Compiling crossbeam-utils v0.8.14
Compiling cfg-if v1.0.0
Compiling is_ci v1.1.1
Compiling thiserror v1.0.38
Compiling heck v0.4.0
Compiling os_str_bytes v6.4.1
Compiling once_cell v1.17.0
Compiling strsim v0.10.0
Compiling termcolor v1.1.3
Compiling proc-macro-error-attr v1.0.4
Compiling proc-macro-error v1.0.4
Compiling clap_lex v0.3.0
Compiling crossbeam-channel v0.5.6
Compiling rustc_version v0.4.0
Compiling error-stack v0.2.4
Compiling atty v0.2.14
Compiling supports-color v1.3.1
Compiling owo-colors v3.5.0
Compiling is-terminal v0.4.2
Compiling terminal_size v0.2.3
Compiling thiserror-impl v1.0.38
Compiling clap_derive v4.0.21
Compiling typed-builder v0.11.0
Compiling fuc_engine v1.1.1
error[E0554]: `#![feature]` may not be used on the stable release channel
--> /home/roland/.cargo/registry/src/github.com-1ecc6299db9ec823/fuc_engine-1.1.1/src/lib.rs:1:12
|
1 | #![feature(const_cstr_methods)]
| ^^^^^^^^^^^^^^^^^^
error[E0554]: `#![feature]` may not be used on the stable release channel
--> /home/roland/.cargo/registry/src/github.com-1ecc6299db9ec823/fuc_engine-1.1.1/src/lib.rs:2:12
|
2 | #![feature(const_result_drop)]
| ^^^^^^^^^^^^^^^^^
error[E0554]: `#![feature]` may not be used on the stable release channel
--> /home/roland/.cargo/registry/src/github.com-1ecc6299db9ec823/fuc_engine-1.1.1/src/lib.rs:3:12
|
3 | #![feature(const_option)]
| ^^^^^^^^^^^^
error[E0554]: `#![feature]` may not be used on the stable release channel
--> /home/roland/.cargo/registry/src/github.com-1ecc6299db9ec823/fuc_engine-1.1.1/src/lib.rs:4:12
|
4 | #![feature(once_cell)]
| ^^^^^^^^^
For more information about this error, try `rustc --explain E0554`.
error: could not compile `fuc_engine` due to 4 previous errors
warning: build failed, waiting for other jobs to finish...
Installing rmz v1.1.1
Compiling proc-macro2 v1.0.49
Compiling libc v0.2.139
Compiling unicode-ident v1.0.6
Compiling quote v1.0.23
Compiling syn v1.0.107
Compiling version_check v0.9.4
Compiling io-lifetimes v1.0.3
Compiling semver v1.0.16
Compiling rustix v0.36.6
Compiling linux-raw-sys v0.1.4
Compiling bitflags v1.3.2
Compiling crossbeam-utils v0.8.14
Compiling cfg-if v1.0.0
Compiling is_ci v1.1.1
Compiling thiserror v1.0.38
Compiling heck v0.4.0
Compiling os_str_bytes v6.4.1
Compiling strsim v0.10.0
Compiling once_cell v1.17.0
Compiling termcolor v1.1.3
Compiling clap_lex v0.3.0
Compiling proc-macro-error-attr v1.0.4
Compiling proc-macro-error v1.0.4
Compiling rustc_version v0.4.0
Compiling crossbeam-channel v0.5.6
Compiling error-stack v0.2.4
Compiling atty v0.2.14
Compiling supports-color v1.3.1
Compiling owo-colors v3.5.0
Compiling is-terminal v0.4.2
Compiling terminal_size v0.2.3
Compiling thiserror-impl v1.0.38
Compiling typed-builder v0.11.0
Compiling clap_derive v4.0.21
Compiling fuc_engine v1.1.1
error[E0554]: `#![feature]` may not be used on the stable release channel
--> /home/roland/.cargo/registry/src/github.com-1ecc6299db9ec823/fuc_engine-1.1.1/src/lib.rs:1:12
|
1 | #![feature(const_cstr_methods)]
| ^^^^^^^^^^^^^^^^^^
error[E0554]: `#![feature]` may not be used on the stable release channel
--> /home/roland/.cargo/registry/src/github.com-1ecc6299db9ec823/fuc_engine-1.1.1/src/lib.rs:2:12
|
2 | #![feature(const_result_drop)]
| ^^^^^^^^^^^^^^^^^
error[E0554]: `#![feature]` may not be used on the stable release channel
--> /home/roland/.cargo/registry/src/github.com-1ecc6299db9ec823/fuc_engine-1.1.1/src/lib.rs:3:12
|
3 | #![feature(const_option)]
| ^^^^^^^^^^^^
error[E0554]: `#![feature]` may not be used on the stable release channel
--> /home/roland/.cargo/registry/src/github.com-1ecc6299db9ec823/fuc_engine-1.1.1/src/lib.rs:4:12
|
4 | #![feature(once_cell)]
| ^^^^^^^^^
For more information about this error, try `rustc --explain E0554`.
error: could not compile `fuc_engine` due to 4 previous errors
warning: build failed, waiting for other jobs to finish...
error: failed to compile `cpz v1.1.1`, intermediate artifacts can be found at `/tmp/cargo-installiGVJr2`
error: failed to compile `rmz v1.1.1`, intermediate artifacts can be found at `/tmp/cargo-installBjmtJB`
My rust version (stable branch)
rustc -V
rustc 1.66.1 (90743e729 2023-01-10)
I get a "File name too long (os error 36)" error on Linux machine when I try to remove 1000 nested directories
$ rmz dir0
Error: An I/O error occurred
│
╰─▶ File name too long (os error 36)
╰╴Failed to open directory: "dir0/dir1/dir2/dir3/dir4/dir5/dir6/dir7/dir8/dir9/dir10/dir11/dir12/dir13/dir14/dir15/dir16/dir17/dir18/dir19/dir20/dir21/dir22/dir23/dir24/dir25/dir26/dir27/dir28/dir29/dir30/dir31/dir32/dir33/dir34/dir35/dir36/dir37/dir38/dir39/dir40/dir41/dir42/dir43/dir44/dir45/dir46/dir47/dir48/dir49/dir50/dir51/dir52/dir53/dir54/dir55/dir56/dir57/dir58/dir59/dir60/dir61/dir62/dir63/dir64/dir65/dir66/dir67/dir68/dir69/dir70/dir71/dir72/dir73/dir74/dir75/dir76/dir77/dir78/dir79/dir80/dir81/dir82/dir83/dir84/dir85/dir86/dir87/dir88/dir89/dir90/dir91/dir92/dir93/dir94/dir95/dir96/dir97/dir98/dir99/dir100/dir101/dir102/dir103/dir104/dir105/dir106/dir107/dir108/dir109/dir110/dir111/dir112/dir113/dir114/dir115/dir116/dir117/dir118/dir119/dir120/dir121/dir122/dir123/dir124/dir125/dir126/dir127/dir128/dir129/dir130/dir131/dir132/dir133/dir134/dir135/dir136/dir137/dir138/dir139/dir140/dir141/dir142/dir143/dir144/dir145/dir146/dir147/dir148/dir149/dir150/dir151/dir152/dir153/dir154/dir155/dir156/dir157/dir158/dir159/dir160/dir161/dir162/dir163/dir164/dir165/dir166/dir167/dir168/dir169/dir170/dir171/dir172/dir173/dir174/dir175/dir176/dir177/dir178/dir179/dir180/dir181/dir182/dir183/dir184/dir185/dir186/dir187/dir188/dir189/dir190/dir191/dir192/dir193/dir194/dir195/dir196/dir197/dir198/dir199/dir200/dir201/dir202/dir203/dir204/dir205/dir206/dir207/dir208/dir209/dir210/dir211/dir212/dir213/dir214/dir215/dir216/dir217/dir218/dir219/dir220/dir221/dir222/dir223/dir224/dir225/dir226/dir227/dir228/dir229/dir230/dir231/dir232/dir233/dir234/dir235/dir236/dir237/dir238/dir239/dir240/dir241/dir242/dir243/dir244/dir245/dir246/dir247/dir248/dir249/dir250/dir251/dir252/dir253/dir254/dir255/dir256/dir257/dir258/dir259/dir260/dir261/dir262/dir263/dir264/dir265/dir266/dir267/dir268/dir269/dir270/dir271/dir272/dir273/dir274/dir275/dir276/dir277/dir278/dir279/dir280/dir281/dir282/dir283/dir284/dir285/dir286/dir287/dir288/dir289/dir290/dir291/dir292/dir293/dir294/dir295/dir296/dir297/dir298/dir299/dir300/dir301/dir302/dir303/dir304/dir305/dir306/dir307/dir308/dir309/dir310/dir311/dir312/dir313/dir314/dir315/dir316/dir317/dir318/dir319/dir320/dir321/dir322/dir323/dir324/dir325/dir326/dir327/dir328/dir329/dir330/dir331/dir332/dir333/dir334/dir335/dir336/dir337/dir338/dir339/dir340/dir341/dir342/dir343/dir344/dir345/dir346/dir347/dir348/dir349/dir350/dir351/dir352/dir353/dir354/dir355/dir356/dir357/dir358/dir359/dir360/dir361/dir362/dir363/dir364/dir365/dir366/dir367/dir368/dir369/dir370/dir371/dir372/dir373/dir374/dir375/dir376/dir377/dir378/dir379/dir380/dir381/dir382/dir383/dir384/dir385/dir386/dir387/dir388/dir389/dir390/dir391/dir392/dir393/dir394/dir395/dir396/dir397/dir398/dir399/dir400/dir401/dir402/dir403/dir404/dir405/dir406/dir407/dir408/dir409/dir410/dir411/dir412/dir413/dir414/dir415/dir416/dir417/dir418/dir419/dir420/dir421/dir422/dir423/dir424/dir425/dir426/dir427/dir428/dir429/dir430/dir431/dir432/dir433/dir434/dir435/dir436/dir437/dir438/dir439/dir440/dir441/dir442/dir443/dir444/dir445/dir446/dir447/dir448/dir449/dir450/dir451/dir452/dir453/dir454/dir455/dir456/dir457/dir458/dir459/dir460/dir461/dir462/dir463/dir464/dir465/dir466/dir467/dir468/dir469/dir470/dir471/dir472/dir473/dir474/dir475/dir476/dir477/dir478/dir479/dir480/dir481/dir482/dir483/dir484/dir485/dir486/dir487/dir488/dir489/dir490/dir491/dir492/dir493/dir494/dir495/dir496/dir497/dir498/dir499/dir500/dir501/dir502/dir503/dir504/dir505/dir506/dir507/dir508/dir509/dir510/dir511/dir512/dir513/dir514/dir515/dir516/dir517/dir518/dir519/dir520/dir521/dir522/dir523/dir524/dir525/dir526/dir527/dir528/dir529/dir530/dir531/dir532/dir533/dir534/dir535/dir536/dir537/dir538/dir539/dir540/dir541/dir542/dir543/dir544/dir545/dir546/dir547/dir548/dir549/dir550/dir551/dir552/dir553/dir554/dir555/dir556/dir557/dir558/dir559/dir560/dir561/dir562/dir563/dir564/dir565/dir566/dir567/dir568/dir569/dir570/dir571/dir572/dir573/dir574/dir575/dir576/dir577/dir578/dir579/dir580/dir581/dir582/dir583/dir584/dir585/dir586/dir587/dir588/dir589/dir590/dir591/dir592/dir593/dir594/dir595/dir596/dir597/dir598/dir599/dir600"
Currently if you --force a directory, copying will still fail with a file exists error. In theory it should be easy to support ignoring those errors when force is used, but I don't know how to handle the edge cases. For example, what happens if a file name conflicts with a directory name? Do we delete the directory before creating the file? That's scary to me.
Need to check what cp does.
hi, please make it accessible from homebrew.
I want to learn about things need to know to implement like this project on windows.
Please give me some hint.
Thanks.
This is a GNU-ism rather than standard POSIX, but it'd be nice if cpz supported GNU cp
's -t
(--target-directory
) and -T
(--no-target-directory
) options, so that the user can ensure consistent behavior re: treating the target as a directory or a name.
I tried cpz locally, to find it was faster.
When I tried to copy to a sshfs mount, it just never finished.
My command issued was cpz mainrig-MS-7D51_amd64_2023-10-10_2141.iso /sshfsmounts/20tb-1-raid1c3/iso/
And I used the cargo build of cpz 1.1.9
Rsync does for instance finish in like 10 minutes.
I went to the shower, had a workout and came back to see it hadn't sent any signal that it was finished.
And the utilization was at 0.0% too.
What can I do to provide more info?
I encountered the following error when copying a directory that contains only a text file.
I'm using CentOS 7.5. rmz
works just fine.
user@hostname:~$ cpz --version
cpz 1.1.10
user@hostname:~$ rustc --version
rustc 1.75.0 (82e1608df 2023-12-21)
user@hostname:~$ cpz test test2
Error: An I/O error occurred
│
╰─▶ Invalid argument (os error 22)
╰╴Failed to copy file: "test/abc.txt"
user@hostname:~$ cat test/abc.txt
ABC
user@hostname:~$ ls test
abc.txt
user@hostname:~$
I'm getting a pretty destructive behavior, while trying to remove symbolic link.
rmz
fails to remove symbolic link and responds with Not a directory (os error 20)
, in reality, it nukes contents of the directory, that symbolic link points to.
I know that rmz
is not advertised to be able to remove symbolic links (no idea if they fall under file
category), but removing content that lies under it - is a very different story. Not sure if it's a bug or a feature request, but it would be better if this behavior would be ether documented or fixed.
Version: 1.1.1
The -i
/ --interactive
flags can be useful for preventing user errors. I use an abbreviation in fish so that rm
and cp
expand to rm -i
and cp -i
. So that I must first delete the flag in order to run a potentially dangerous operation.
A large amount of code complexity comes from trying manage the different platform implementations and keeping their semantics the same.
mv
on the same filesystem is rename(2)
. mv
across file systems is cp
followed by rm
, a non-atomic operation. Implement mvz
with accelerating of the copy and remove phases using mostly the existing code base.
Let's assume that a somewhat frequent usage of rmz
is to recursively delete a tree and putting another tree in it's place. During the recursive operation, however fast, the original directory entry name remains blocked for use. The perceived speed of rmz
could be improved by adding an option (--rename-before-deletion
) to rename the target directory to a non-conflicting, temporary name (.rmz-deletion-$PID-$XXXX
). For a single interactive shell this only makes sense when rmz is run in the background.
While copying symbolic link cpz
copies the whole directory.
cp (GNU coreutils) 8.32
by default if symlink points to a:
Directory - will not follow symbolic link, scream that it needs an -r
flag and copy it as is
File - will follow symbolic link and copy file itself
-L, --dereference
- always follow symbolic links in SOURCE (Copy contents, but resolve ALL links under the directory)-P, --no-dereference
- never follow symbolic links in SOURCE (Copy symlink itself)-H
- follow command-line symbolic links in SOURCE (Copy contents as is)-s, --symbolic-link
make symbolic links instead of copying (Works recursively, unlike ln
. Consider as a feature?)Default behavior probably requires the same treatment as #11.
Not a critical issue, but default behavior is different and probably not expected.
Version: 1.1.2
Basically, the -p
flag from (POSIX) cp
:
-p Duplicate the following characteristics of each source file in the corresponding destination file:
- The time of last data modification and time of last access. If this duplication fails for any reason, cp shall write a diagnostic message to standard error.
- The user ID and group ID. If this duplication fails for any reason, it is unspecified whether cp writes a diagnostic message to standard error.
- The file permission bits and the S_ISUID and S_ISGID bits. Other, implementation-defined, bits may be duplicated as well. If this duplication fails for any reason, cp shall write a diagnostic message to standard error.
note that most implementations of cp
also specify -a
(-a
/--archive
in GNU), which implies:
-p
-R
: recursive (cpz already does this by default)-P
: symlinks in the sources are copied as symlinks, rather than followed (cpz also does this by default)Also, for reference, GNU's cp -a
additionally:
cp -p=all
)cp -d
)
cp -a
two files that are hard-linked, you'll create a separate pair of hard-linked files)Providing -a
(ideally, but perhaps not necessarily, GNU's version) would be very useful for using cpz
as a backup tool.
potentially interest data point:
with a test script like this:
$ git clone https://github.com/pkgxdev/pantry
Cloning into 'pantry'...
$ cpz pantry pantry2
Error: An I/O error occurred
│
╰─▶ Operation not permitted (os error 1)
╰╴Failed to unshare FD table.
i get errors (ref) on both linux/amd64 and linux/arm64, but not on macos; a simpler test passes both:
$ mkdir -p a/b/c/d/e
$ echo aaa > a/b/c/d/e/f
$ echo aaa > a/b/c/d/e/g
$ cpz a a2
further, i get an unshare error on linux/amd64 for rmz
, regardless of complexity:
$ git clone https://github.com/pkgxdev/pantry
Cloning into 'pantry'...
$ test -d pantry
$ rmz pantry
Error: An I/O error occurred
│
╰─▶ Operation not permitted (os error 1)
╰╴Failed to unshare I/O.
$ mkdir -p a/b/c/d/e
$ touch a/b/c/d/e/f
$ test -d a
$ rmz a
Error: An I/O error occurred
│
╰─▶ Operation not permitted (os error 1)
╰╴Failed to unshare I/O.
(ref2)
i suspect that the rmz
error might be specific to GitHub Actions runners, since the rest are self-hosted, and the cpz
error is likely related to the complexity of a full git clone
. but i thought it was interesting that the problems manifested solely on linux, so i thought i'd bring it to your attention. i'll update if i find anything else (might try using sudo
to see if that makes a difference. or -f
, but that seems unlikely.).
A zippy alternative to cp, a tool to remove files or directories.
Hello,
Unless I'm mistaken, cpz does not handle sparse file and will copy null bytes over the wire. The xcp project (https://github.com/tarka/xcp) tries to iterate between sparse chunk and use copy_file_range for actual data.
I think this would be a nice addition and I hope you will consider this feature.
Sorry this is really an RFE without an associated pull request, but my rust skills are non-existent at the moment.
Thank you for this project. This is a fantastic contribution to the space of data movement.
Jean-Baptiste
Rust TUI tool to remove unused files
Finds files older than X, presents a flat scrollable view with exclusion/inclusion and shortcuts to advance, digging down directories until no more files are unknown. Allows deleting all included files.
3 pane view: left is delete, middle is todo, right is keep
Enter opens dir, left right up down navigate between panes and dirs, a means delete, d means keep, ws enter leave dirs, esc leaves dirs
Sort by least recently modified. Kept dirs get mtime bump.
Keep parent delete child totally fine. Deleting parent but keeping child is bad: delete around kept children. Check for superset deletion and prune children that will get deleted anyway.
Store keep/delete as trees with dirs as nodes and children in a set. Make doubly linked so nodes can be removed/inserted easily. Add undo/redo stack with list of nodes and their inverse ops (e.g. delete/insert this node). If deleting kept child, start at child and expand up to parent, adding all not-child path dirs to the deletion set and the child path nodes to the keep set.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.