Right click on mouse freezes the archives folder

[vitorr2101]

What Happened?

When i right click in the area that has no folders or files the archives folder just freezes.

Steps to Reproduce

1. Click on the arquive folder (blue icon with magnifying glass).
2. Right click on the empty space.

Expected Behavior

After the click, show what functions that the right click provides or just don't freeze the window.

OS Version

8.x (Circe)

OS Architecture

amd64 (on most hardwares)

Session Type

Classic Session (X11, This is the default)

Software Version

Latest release (I have run all updates)

Log Output

Hardware Info

Acer Aspire 515-57, 8G Ram

[jeremypw]

I think that by "Archive folder" you mean the Files application icon in the dock (or Application Menu). That looks like a blue folder with a magnifying glass but it isn't an actual folder on the file system, it just launches the file manager application.

So which location is being shown when the Files application appears? You can see the path to the location in the pathbar in the header. Which type of view is being used? (Icon, List or Column)? Is the empty space being clicked on between the file items or at the bottom, beneath the file items? Or is it an empty folder?

I cannot reproduce this issue at the moment.

[dvilelaf]

This happens to me as well when I right click any empty space in any path using the icons view (at least). Files freezes and I have to kill it. This started happening 2 days ago.

[jeremypw]

@dvilelaf The last change to Files was released 3 weeks ago - have you just updated to that release? There is an issue with that release concerning file operations with files with # in the name but I cannot reproduce the issue that you describe. If you run System Monitor and then cause Files to freeze can you see if the Files process is using a lot of cpu suggesting it has gone into an infinite loop?

[dvilelaf]

@dvilelaf The last change to Files was released 3 weeks ago - have you just updated to that release? There is an issue with that release concerning file operations with files with # in the name but I cannot reproduce the issue that you describe. If you run System Monitor and then cause Files to freeze can you see if the Files process is using a lot of cpu suggesting it has gone into an infinite loop?

Yes, when i do that while checking htop, I can see the CPU going nuts until the app is suggested to be killed a minute after. But there's no files with # in their names.

[jeremypw]

It is possible that another punctuation or non-Latin character could also trigger the bug.

[kabeza]

Hi everyone

I begun having the same behaviour on io.elementary.files since 2-3 weeks ago I right click anywhere (no matter which are the filenames -having or not particular chars-, folders, etc.) no matter if I right-click a file, a folder, an empty space, etc. the window hangs completely

io.elementary.files 7.1.4 OS: elementary OS 7.1 Horus x86_64 Kernel: Linux 6.8.0-65-generic

Is there any way to see io.elementary.files log files, to see if anythying appears there?

Thanks

[jeremypw]

@kabeza You can try running Files from a terminal with the command G_MESSAGE_DEBUG=all io.elementary.files to see all Files debugging output.

If you are able you can try compiling and running this branch - https://github.com/elementary/files/pull/2616 - to see whether it fixes. Hopefully this branch will be merged and release soon.

[kabeza]

@kabeza You can try running Files from a terminal with the command G_MESSAGE_DEBUG=all io.elementary.files to see all Files debugging output.

If you are able you can try compiling and running this branch - #2616 - to see whether it fixes. Hopefully this branch will be merged and release soon.

I've tried that and this was the result:

In this case (where I've begun noticing this bug) is related to copying files in one tab and trying to paste in another

Thanks again!

[jeremypw]

@kabeza Thanks, that's very helpful. It means that the statement var pixbuf = new Gdk.Pixbuf.from_file (filename) is failing, so the value of filename is invalid in some way. I see you have redacted the filename in your screenshot but can you advise whether it has any features that may make it an invalid filename on Linux or whether it does not correspond to an actual file on your system? Perhaps you could post here after replacing all alphanumeric characters with X?

[jeremypw]

@kabeza By the way, that part of the code should only be reached when using the clipboard (is using Copy, Cut or Paste commands or shortcuts). Is that what you were doing?

[jeremypw]

@kabeza Sorry - just noticed that the file extension is .pdf but the code was related to handling a target type of PNG_IMAGE so not sure what was happening there. That should only be be used when pasting into an image handling app (not Files). Anyway I do not see that this warning could be related to Files freezing.

[kabeza]

@jeremypw

1. I open io.elementary.files then go to a tab, select a pdf file (the filename does not contain anything weird nor strange characters). I can right-clic a file and select Copy, but I usually select the file, press in keyb. Ctrl+C and then in the other tab to right-clic and press paste. Now I had to override this and press on keyb. Ctrl + V (but I always try to right-clic first)

2. Yes, io.elementary.files now crashes everytime I work with copy/paste tasks

3. I don't know, maybe the io.elementary.files tries to get the preview image of the PDF file I try to copy? I'm not aware of having installed anything nor a plugin to do so. However, I've tried copying/pasting other files (.conf, .docx, .jpg, .png) and I get other errors

screenshot1 (trying to copy a pdf file doing right-clic etc.):

screenshot2 (same with png file):

screenshot3 (same but with conf file):

PS: I blur the paths or something from filenames because they contain personal info etc. But the files and paths are ok, without any strange characters, they exists

[jeremypw]

Very strange; when pasting into a Files view it should never request a target type of "PNG_IMAGE" from the clipboard.

I am not able to reproduce this behaviour at all using local files and copy/pasting between local folders. Can you perform the same operation using drag and drop successfully?

(You can ignore the warning from plugin.vala - it just means you do not have a color-tag database from an older version of Files. That warning can probably be discontinued now - we migrated away from the color-tag database a while back).

You could pipe the output through grep to concentrate on clipboard messages using G_MESSAGES_DEBUG=all io.elementary.files 2>&1 | grep -i clipboard.

I assume you are moving files between local folders? Could you check the properties of the file being moved using the "Properties" context menu option. In particular is the mime-type correct?

Does File "crash" even copy/pasting one file (with a "normal" name)?

You could try running Files under gdb. In a terminal run gdb io.elementary.files and at the prompt type run. If Files truly crashes then focus will return to the terminal otherwise if Files just becomes unresponsive you can type Ctrl + C into the terminal. You can then type bt to obtain a backtrace of what was happening.

[kabeza]

1. pipe the output through grep

2. yes, some files may be on a NTFS mount, but this was working before perfectly. I begun having this right-clic freezing behaviours some weeks ago. The Mime-type is right in the properties

3. Yes, the io.elementary.files crashes even copying/pasting files with "normal" names

4. When running through gdb, I don't get anything different than before

[jeremypw]

@kabeza Thanks for your efforts in trying to diagnose this issue. Was the program terminated by you pressing Ctrl+C into the terminal while Files was frozen, or in some other way? You should then be able to type bt in the terminal while still running gdb to get a useful backtrace. However, it looks like you just typed quit? You should not end the Files process through the Files UI otherwise the backtrace will not be obtainable.

[kabeza]

@jeremypw yes, ctrl+c and/or quit. Now I wrote bt but no luck, nothing shows, I only get the Force Quit dialog

[jeremypw]

Not sure but it looks like Files is still running under gdb. Make sure the terminal is focused before pressing <Ctrl>C - you should then get a visible response in the terminal, returning to the gdb prompt. (May need to press more than once?) You should then be able to type bt and get a response from gdb.

Incidentally the dialog looks unusual for elementaryos - have you made some mods?

[kabeza]

Incidentally the dialog looks unusual for elementaryos - have you made some mods?

just install some 3rdparty gtk theme

[dvilelaf]

Just installed latest image in another laptop, and I just got the same behaviour.

[jeremypw]

Thanks, I'll check the context menu code and see if there are entries that need to have a timeout or be excluded for certain locations/fi;esystems. I haven't been able to reproduce this but I mainly use local files.

[ernstki]

Possibly #2613 again same as #2643?

@vitorr2101 if this isn't already resolved for you, can you see if you have a ~/Templates folder and if not, create it? You will also need to manually update ~/.config/user-dirs.dirs and either killall io.elementary.files-daemon, or log out and back in.

I'm not sure how @jonolumb figured out that it was the missing Templates folder, but re-creating ~/Templates and updating user-dirs.dirs resolves the situation for me, where Files used to lock up hard any time I right-clicked on an empty part of the window.

I had deleted ~/Templates and ~/Public because I never use those, causing ~/.config/user-dirs.dirs to default to $HOME/ for both, and triggering the bad behavior as it tried to populate the "Template" sub-submenu with the contents of my home directory.

Update: applying the patch from #2644 also corrects this problem. That appears to be targeted for the next release of Files, and is awaiting a review. So, hopefully, soon.

[dvilelaf]

Possibly #2613 again? @vitorr2101 if this isn't already resolved for you, can you see if you have a ~/Templates folder and if not, create it?

I'm not sure how @jonolumb figured out that it was the missing Templates folder, but re-creating ~/Templates resolves the situation for me, where Files used to lock up hard any time I right-clicked on an empty part of the window.

I had deleted ~/Templates and ~/Public because I never use those, causing ~/.config/user-dirs.dirs to default to $HOME/ for both, and triggering the bad behavior as it tried to populate the "Template" sub-submenu with the contents of my home directory.

Update: applying the patch from #2644 also corrects this problem. That appears to be targeted for the next release of Files, and is awaiting a review. So, hopefully, soon.

Recreating ~/Public and ~/Templates does not fix it for me. Hoping for that patch to be released and to fix it.

[ernstki]

Recreating ~/Public and ~/Templates does not fix it for me. Hoping for that patch to be released and to fix it.

@dvilelaf Just re-creating the missing directories isn't enough.

• ~/.config/user-dirs.dirs also needs to be updated accordingly — and —
• elementary's Files app starts a daemon that runs in the background, which you'd need to kill from terminal, or else log out and log back in

[ernstki]

@jeremypw Could be a duplicate of #2643. Hard to tell for sure until @vitorr2101 checks back in.

[dvilelaf]

Recreating ~/Public and ~/Templates does not fix it for me. Hoping for that patch to be released and to fix it.

@dvilelaf Just re-creating the missing directories isn't enough.

* `~/.config/user-dirs.dirs` also needs to be updated accordingly — _and_ —

* elementary's Files app starts a daemon that runs in the background, which you'd need to `kill` from terminal, or else log out and log back in

Oh damn, I missed that part. I confirm that also fixes it for me! Thanks, it's been a few weeks constantly crashing Files.

[ernstki]

Oh damn, I missed that part. I confirm that also fixes it for me! Thanks, it's been a few weeks constantly crashing Files.

@dvilelaf OK, glad it worked out for you. That was my bad also, because I didn't document that crucial step in the comment above until later. Got so excited I'd found a workaround for the crashes that I forgot to go back and check my work!