Weird nautilus behavior for file removal on F38

I just noticed that, if I select files on nautilus and press del or shift+del to remove them, sometimes they remain on the window, and if I select any one of them, the lower-right status bar shows "" selected, as if the file name was empty. Actually, they are kind of “ghost entries”, since trying to interact with them results in an error. If I go to another directory and then come back, or refresh the window with F5, the ghost files are gone.

I made a short video demonstrating it:

  1. I created 3 empty files aaa, bbb and ccc with touch
  2. I removed aaa with shift+del, it still appears on the screen, with the empty name "", while bbb seems to be gone

The behavior is not deterministic, though: sometimes the files are removed as expected.

I wonder if someone else is also experiencing this :thinking:

EDIT: I uploaded the video to my Google Drive

Yes, I can confirm that nautilus doesn’t refresh the view when deleting files for me. I experienced the issue earlier today, later updated nautilus to version 44.1, which was made available a couple of hours later, but still happening. Tried both Wayland and X11.

1 Like

The problem seems to be fixed on nightly flatpak. Filed issue 2943.

Had just noticed the same issue, where can i find the nightly flatpak?

Ahh, found it:
flatpak remote-add --if-not-exists gnome-nightly
Gnome Nightlies

The flatpak works because it uses gtk 4.11. 44.0 and 44.1 broke because a fix in gtk 4.10 wasn’t cherrypicked. There should be a fixed gtk released soon

3 Likes

even weirder effect if you choose “undo” after deletion. aaa will be shown twice.
and one more, moving file to the folder (not copying) has similar weird effect.

Yes, it is completely broken as it is :disappointed: (under the hood the files are removed, but the view becomes inconsistent) Until a fix comes up, we must remember to refresh the view after a move/delete…

1 Like

Is there something we can do to provide some kind of bug report for Fedora besides posting to the forums? I guess, the Gnome team is already aware and fixed it. So far, so good.

Just switched to Fedora, is working with nightly build flatpaks an option? I guess, no. Used the chance and reinstalled the system to set up snapper and BTRFS, so hopefully next time, I can revert to a working snapshot when something like this is happening again. Not a huge problem this time, but since I had to learn the hard way that BTRFS and Clonezilla are not best friends, better rely on snapshots in the future :slight_smile:

You can always file a bug report on Fedora’s Bugzilla. I might be wrong, but on this specific case, since upstream is already aware and provided a fix, I am not sure it would be much effective…

I didn’t quite get this with nightly neither…
So I’m on F38, could I use flatpak remote-add --if-not-exists gnome-nightly as @djgalvan01 suggested and later on come back to non nightly?

From what I understand, the hint to the nightly flatpak was more or less just a quick test to verify that the bug is already fixed upstream, right? Please correct me, if I’m wrong.

Edit: Today’s wave of updates seems to have fixed the issue on my system.

@ewoks sorry for not making it clearer the first time. @mendres82 is right, I just installed nightly following the instructions on GNOME’s Github to quickly test if it had alreaby been fixed, it was not meant to be a full replacement for the stable version.

Also, I can confirm that the problem seems to be gone with today’s updates :raised_hands: