Crash when replacing a file in the desktop

Thank you for reporting ! Though I cannot reproduce the issue.

More information is required:

When i try to replace a file in the desktop

Are you talking about xfdesktop (the background), or the ~/Desktop folder in thunar ? Or does it happen for both ?
Does it happen for all types of files, or only for launchers ? If it only happens for a specific file, it would be good to have it attached to the issue.
How do you perform the replace operation ? Does it matter ? I tested with CTRL+C + CTRL+V on a file which has the same name.

When I am still not able to reproduce, for crashes, it's best to get a backtrace to see which method failed to execute.

To get a meaningfull backtrace, you will need to install thunar debug symbols. Check the distro specific backtrace info in the xfce wiki to see how to do so !

It's basically ulimit -c unlimited to produce coredumps on crashes and than using gdb on it to get the backtrace out of the coredump. Here some example: https://serverfault.com/questions/61659/can-you-get-any-program-in-linux-to-print-a-stack-trace-if-it-segfaults

added 1. Crash / Freeze 3. Need Info 5. File Operations labels

From an open thunars window on my desktop (the background) select copy file or files (all types of files). Try to paste (right click menu) on my desktop with the window still open. From the dialog select replace or replace all (the file\es existing on my desktop) do the job and the thunars window crash.

I can reproduce the crash:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x000055a0f89dc18c in thunar_job_operation_overwrite (job_operation=job_operation@entry=0x0, overwritten_file=overwritten_file@entry=0x55a0f96df5a0) at thunar-job-operation.c:177
177	  job_operation->overwritten_files = thunar_g_list_append_deep (job_operation->overwritten_files, overwritten_file);
[Current thread is 1 (Thread 0x7f90d37fd6c0 (LWP 67979))]
(gdb) bt
#0  0x000055a0f89dc18c in thunar_job_operation_overwrite (job_operation=job_operation@entry=0x0, overwritten_file=overwritten_file@entry=0x55a0f96df5a0) at thunar-job-operation.c:177
#1  0x000055a0f8a0bdad in ttj_copy_file (error=0x7f90d37fca78, copy_flags=(G_FILE_COPY_OVERWRITE | G_FILE_COPY_NOFOLLOW_SYMLINKS), target_file=0x55a0f96df5a0, source_file=0x55a0f9714500, operation=0x0, job=0x55a0f9d4f090) at thunar-transfer-job.c:663
#2  thunar_transfer_job_copy_file (error=0x7f90d37fca70, rename_confirmed=<optimized out>, replace_confirmed=<optimized out>, target_file=0x55a0f96df5a0, source_file=0x55a0f9714500, operation=0x0, job=0x55a0f9d4f090) at thunar-transfer-job.c:739
#3  thunar_transfer_job_copy_node (job=job@entry=0x55a0f9d4f090, operation=operation@entry=0x0, node=0x55a0f97154e0, target_file=0x55a0f96df5a0, target_parent_file=0x55a0f9737ea0, target_parent_file@entry=0x0, target_file_list_return=target_file_list_return@entry=0x7f90d37fcb40, error=0x7f90d37fcb38) at thunar-transfer-job.c:954
#4  0x000055a0f8a0c2a0 in thunar_transfer_job_execute (job=0x55a0f9d4f090, error=0x7f90d37fcb90) at thunar-transfer-job.c:1716
#5  0x00007f90d9783727 in exo_job_scheduler_job_func (scheduler_job=<optimized out>, cancellable=<optimized out>, user_data=0x55a0f9d4f090) at exo-job.c:310
#6  0x00007f90d8a91bee in  () at /usr/lib/libgio-2.0.so.0
#7  0x00007f90d8ac4c4c in  () at /usr/lib/libgio-2.0.so.0
#8  0x00007f90d8903673 in  () at /usr/lib/libglib-2.0.so.0
#9  0x00007f90d88fde05 in  () at /usr/lib/libglib-2.0.so.0
#10 0x00007f90d871a8fd in  () at /usr/lib/libc.so.6
#11 0x00007f90d879ca60 in  () at /usr/lib/libc.so.6

Thank you for the details and @Tamaranch for the bt ! Now I as well can reproduce (not sure why I could not before) ... will look into it.

removed 3. Need Info label

mentioned in commit 7074fbc6

mentioned in commit c4ee462b

Fixed ... copy/move to desktop is triggered via DBus, and thunar does not create or store undo/redo operations for that case. For thunar_job_operation_overwrite a guard was missing to check if there actually is an undo/redo operation ongoing.

(For master I will switch to operation != NULL, which is more intuitive than checking the log_mode)

closed

changed milestone to %4.18.2

Crash when replacing a file in the desktop

Designs

Child items ...

Activity