On Mon, Aug 24, 2015 at 10:54 AM, David Houlder wrote: > On 10/08/15 20:00, [email protected] wrote: >> >> +{ >> + GError *gerror = NULL; >> + GFile *gfile = NULL; >> + int must_unlink = !dt_conf_get_bool("send_to_trash"); >> + >> + if (!must_unlink) >> + { >> + gfile = g_file_new_for_path(filename); >> + if (!g_file_trash(gfile, NULL, &gerror)) >> + { >> + if (g_error_matches(gerror, G_IO_ERROR, G_IO_ERROR_NOT_SUPPORTED)) >> + must_unlink = TRUE; >> + } >> + >> + if (gerror != NULL) > > Um... don't you want to g_object_unref(gfile) regardless of gerror? >> >> + g_object_unref(gfile); >> + } >> + if (must_unlink) >> + (void)g_unlink(filename); >> +} > > Also, there may be cases where g_file_trash() takes an appreciable amount of > time - sometimes it may boil down to a copy instead of a rename. I'm not > very familiar with the darktable source, but if the code above is called > from the main thread it might tie up the GUI for a little while. Maybe > that's OK - any thoughts? At the risk of complicating things, I note that > there is also g_file_trash_async (). > > On the whole though, I think I prefer this to the current file deletion > mechanism. > Thanks. >
The current deletion mechanism already sends the deletion job to an other thread so it's already taken care of. Guillaume ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to [email protected]
