GNU bug report logs - #58721
28.2; dired with delete-by-moving-to-trash can't trash directory twice

Previous Next

Full log

Message #44 received at 58721 <at> debbugs.gnu.org (full text, mbox):

From: Gustavo Barros <gusbrs.2016 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 58721 <at> debbugs.gnu.org
Subject: Re: bug#58721: 28.2; dired with delete-by-moving-to-trash can't trash
 directory twice
Date: Fri, 28 Oct 2022 07:43:08 -0300

On Fri, 28 Oct 2022 at 04:47, Eli Zaretskii <eliz <at> gnu.org> wrote:

> This sounds very strange.

It baffles me too. Yet it still fails like clockwork here.

>  Why would the failure depend on the size of
> the file/directory and on whether it does or doesn't cross
> filesystems?  I see nothing in the code involved in this that could
> cause that.

Well, "crossing filesystems" and "large enough" are admittedly a
working hypothesis. I don't really know that's what makes it fail. I
just know that I could create other cases which do not fail, out of
these conditions.

I take this means you still cannot reproduce... I'm sorry, I don't
know what else I can try, I'm out of my depth here. Do you have
anything you'd like me to try? Can anyone else reproduce this, or is
it really just me?

>  Perhaps on your system something happens in the
> background, due to one of the filesystems being encrypted or
> something?

The encrypted partition is open and mounted, as far as the system can
see, it is just another ext4 partition. More clearly, it cannot be
encryption per se, since the "/tmp/" folder is not encrypted at all,
it is just a tmpfs mount. It's fstab entry is:

    tmpfs /tmp tmpfs nodev,nosuid,size=6G 0 0

Of course, it might still be "or something". But I don't do anything
out of the ordinary here that I'm aware of.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.