← Back to context

Comment by collinfunk

19 hours ago

I 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 directory

84 comments

collinfunk

Reply
maxhou  40 minutes ago

I tried switching a buildroot based CI server to the 26.04

One Makefile statement triggered a bug in rust ln:

  src/%:
      @ln -sfn $(DIR)/foo src

In parallel build, we would get random failure:

  ln: Already exists

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.

HackerThemAll  1 few seconds ago

While I supported that, this your experiment showed me how bad it is. My results are totally different, but not what I expected (edited out long strings of "a/a/a" for brevity). I wouldn't call it stable...

  root@71a8c5a6c5e3:/# mkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
  mkdir: File name too long
  root@71a8c5a6c5e3:/# gnumkdir -p $(yes a/ | head -n $((32 * 1024)) | tr -d '\n')
  gnumkdir: cannot create directory 'a/a/a/.../a/a': File name too long
  root@71a8c5a6c5e3:/# gnumkdir -p $(yes a/ | head -n $((3 * 1024)) | tr -d '\n')
  root@71a8c5a6c5e3:/# rm -rf a
  rm: cannot remove 'a/a/a/.../a/a/a': Directory not empty
  root@71a8c5a6c5e3:/# gnurm -rf a
  root@71a8c5a6c5e3:/# rm -rf a
  root@71a8c5a6c5e3:/#

teekert  19 hours ago

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.

PunchyHamster  26 minutes ago

It's entirely aisine and makes me avoid Ubuntu every time it is possible. And it is repeated offence, Ubuntu always tried to push the envelope in worst place and way possible

amelius  19 hours ago

Let them first fix Snap.

  • tjoff  5 hours ago

    There is no reason for anyone on any distro to use snap.

    It will die so just leave it alone.

  • 0x696C6961  10 hours ago

    They need to kill snap ...

    • LtWorf  4 hours ago

      I think ubuntu wants to kill desktop linux. No other explaination of why they push firefox inside snap, which then proceeds to constantly crash, when firefox used normally works completely fine.

      I haven't tried chromium but I presume it's the same issue.

      At work I'm forced to use ubuntu and I placed snapd on hold and added mozilla's own apt repository to my configuration to get firefox.

      At least in the past few months the dbus crashes (been using systemd on debian for several years just fine, this never happened) that render the system unusable and un-rebootable have stopped… I guess when my company will decide to upgrade to 26.04 there will be more instability and problems.

      5 replies →

froh  3 hours ago

to enable GPL free embedded Ubuntu, field tested on all platforms (because it happens to be the default).

dark-star  19 hours ago

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?

  • geokon  3 hours ago

    It's less about the specific issue and more indicative of bad/insufficient test coverage

  • tosti  17 hours ago

    What programmer or programming language can't iterate a loop more than 32000 times?!

    • IshKebab  17 hours ago

      It's a stack overflow which means it's using recursion and for historical reasons that don't make sense any more, stacks are teeny tiny on 64-bit Linux - apparently only 8 MB on Linux! I'm not sure why they don't raise it to something reasonable like 4 GB. I guess because they want consistency with 32-bit? Maybe we can finally change it if/when they phase out support for 32-bit Linux. Apparently it might not be that far away:

      https://lwn.net/Articles/1035727/

      17 replies →

  • secondcoming  19 hours ago

    That way of thinking just means it'll never be fixed

    • gpm  19 hours ago

      Nah, people should (and do) fix small issues as well as big issues. Lying about the scale of issues and calling them "big" when they aren't just leads to no ability to prioritize or evaluate.

      Incidentally someone submitted a PR for this issue about 3 hours before the first comment about it in this thread - https://github.com/uutils/coreutils/pull/14554 (and 2 hours before this link was submitted to HN)

IshKebab  17 hours ago

I mean, that should work... but you can see why that would be considered low priority right?

lynx97  5 hours ago

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."

barbarkaragul  2 hours ago

Hi, this is not a one bug.when the change app flags not working or not happening. I was measured with bsd and busybox.