In some cases, if some of the files are not renamed, for reasons like
deletion or files having the same name, the undo would fail.
The problem was that the files and names lists provided for undo also
contained info about the files for which the rename failed.
The fix was to add undo info only for files that are actually renamed
and prepare the undo only if at least a file has successfully been
renamed.
https://bugzilla.gnome.org/show_bug.cgi?id=770965
If there were too many files in batch renaming, the tracker query would
give the following error: "parser stack overflow", because the limit for
the expression tree depth was hit for the file name filter.
The fix was to use a filter that doesn't expand that much in sql.
https://bugzilla.gnome.org/show_bug.cgi?id=770586
If one or more files are deleted during a batch rename and click rename,
Nautilus would seg fault.
The problem is that in the function nautilus_file_rename_handle_file_gone
there was called a callback that was NULL. For batch renaming, there is no
need for a callback here.
https://bugzilla.gnome.org/show_bug.cgi?id=770968
If a file had the extensions .tar.bz or .tar.xz, the function
eel_filename_get_extension_offset would identify only .bz or .xz as
an extension.
To fix this, .xz and .bz were added among the other special cases.
https://bugzilla.gnome.org/show_bug.cgi?id=771018
In the replace mode, for some unicode characters, the displayed label
would be incorrect.
The problem is that the second argument of g_markup_escape_text is
the number of bytes and it was used with the number of characters.
Since the strings are null terminated we can just omit this parameter
altogether and fix this as a side effect.
https://bugzilla.gnome.org/show_bug.cgi?id=770972
destroy_conflicts_task_data() erroneously checks pointers to the mutex
and condition variables. They always evaluate to true and thus no
checking should be done in that case.
https://bugzilla.gnome.org/show_bug.cgi?id=771071
We were checking separately when a directory had different parents
than just one.
However having just one parent is a special case of having multiple
parents.
With the latest refactoring, we can merge the code now.
https://bugzilla.gnome.org/show_bug.cgi?id=770586
The Gtask has to finish only when all the internal async call are ready,
doing the other way around is conceptually wrong and will cause problems
if we rely on the task for checking the status of the general operation.
For that implement a correct GTask handling, waitig with a mutex and
condition for all async calls to be ready, and only then mark the task
as finished.
https://bugzilla.gnome.org/show_bug.cgi?id=770586
Seems the case statements adjustment are buggy in uncrustify.
Added a new line at the start of the file, reran uncrustify and it
worked. Removing the new line doesn't affect the output anymore.
https://bugzilla.gnome.org/show_bug.cgi?id=770564
In the replace mode, when "." or ".." were typed in the replace entry,
there would always pop up an error, saying that a file would have an
invalid name.
In this case, instead of checking the entry, the check must actually be
done to all the new names to see if any of those are equal to "." or
"..".
Since the new names are now used in this function, these have to be
obtained before.
https://bugzilla.gnome.org/show_bug.cgi?id=770870
Using this shortcut on one or more folders causes segmentation fault.
In order to solve this, if there is a directory that needs to be
activated, the NEW_WINDOW flag is set, so that the initial window will
be closed and a new one will be created. After a new window is created,
the CLOSE_BEHIND flag is disabled,so that the window will not be closed.
The flags NEW_TAB is also set there(unless we want all directories
opened in new windows), in order for new tabs to open in the newly
created window.
https://bugzilla.gnome.org/show_bug.cgi?id=755711
Currently, enum types are generated by passing command line
arguments to glib-mkenums. A better alternative to that is passing a
template file, which also declutters build files.
https://bugzilla.gnome.org/show_bug.cgi?id=770507
