alt Hacker NewsI really don't understand why Canonical rushes this. If 'rm' can't remove all possible directory entries, that is a big issue:
$ podman run --rm -it ubuntu:26.10
$ apt update -y; apt upgrade -y
$ rm --version
rm (uutils coreutils) 0.10.0
$ gnumkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
$ rm -rf a
Segmentation fault (core dumped) rm -rf a
$ ls a
a
$ gnurm -rf a
$ ls a
ls: cannot access 'a': No such file or directoryReplies
but it segfaulted in a memory safe way.
Rush? This is an interim release (95% or so only tracks LTS's) that is not even out yet... Go file a bug reports if you have some time.
And that’s why i keep ubuntu far from my computers…
Hi, this is not a one bug.when the change app flags not working or not happening. I was measured with bsd and busybox.
to enable GPL free embedded Ubuntu, field tested on all platforms (because it happens to be the default).
yeah, this is a bug. And yes, it should be fixed. But I don't think it will affect many users, I mean who has a 32000 -evels deep directory on their system?
I mean, that should work... but you can see why that would be considered low priority right?
Wow! Memory safety and such... Reminds me when a friend of mine wrote in IRC long time ago: "Hmm, tail just segfaulted." When I asked "Are you on Hurd?" he just replied "Yes."
I tried switching a buildroot based CI server to the 26.04
One Makefile statement triggered a bug in rust ln:
In parallel build, we would get random failure: Rewrote that Makefile to work-around it, and ended up with the same kind of bugs with parallel $(INSTALL) -D ...Tried latest ubuntu 26.10 which supposedly fixes a lot of TOCTOU races in rust coreutils, but no better.
Gave up and switched back to original coreutils.