Whe the ASK option gone, the only alternative to the default is RUN.
This option is not safe: it's too easy to accidentally run programs.
Now we have a "Run as a Program" action in the context menu, which is
available by default (no configuration required) and safe (clearly
labeled, intentionally chosen).
So, remove the RUN option is no longer necessary, and with it we can
remove the preference from both the UI and GSettings schemas.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1700
Discussed in https://gitlab.gnome.org/GNOME/nautilus/-/issues/443
There is an option in Preferences which enables a dialog asking users
what they intend to do when they double-click an executable text file:
open as a text file or run as a program?
The dialog asking that question has known design problems, but they
remain unaddressed, which is not surprising because it's non-default.
Now, with the new menu item added in the last commit, the two options
("Open" and "Run as a Program") are both available by default in the
context menu, so there is no need to ask the question in a dialog.
Remove the option, the dialog, and the related code.
Closes https://bugzilla.gnome.org/show_bug.cgi?id=598671
Part of https://gitlab.gnome.org/GNOME/nautilus/-/issues/1700
By default, when as executable text file is activated (by double-click,
pressing <Return>, etc.), it opens as a regular text file (usually with
a text editor).
This is a safe and consistent behavior, but it makes runing scripts
harder than it needs to be, requiring configuration by the user.
Address this by introducing a new context menu action to run files as
programs. (The code for this action was adapted from mime-actions.c.)
Required for https://gitlab.gnome.org/GNOME/nautilus/-/issues/1700
Discussed in https://gitlab.gnome.org/GNOME/nautilus/-/issues/443
A gsettings-based option "confirm-trash" existed to determine if a
confirmation dialog should be shown when emptying the trash. This
setting, enabled by default, was misappropriated for the unrelated
"delete directly" operation of files outside Trash. This latter use of
this setting was misleading and unexpected (more discussion on the
linked issue page.)
Remove option "confirm-trash" entirely because neither of the above
mentioned operations are reversible, so they should always require
confirmation.
Add ellipsis to labels for the "empty trash" and "delete permanently"
actions since they now always invoke a confirmation dialog.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1699
They are plain wrappers for g_file_is_native(), and, after the previous
commits, there are only two usages, which are found in:
* window-slot.c, introduced in b3a4eabf01
* files-view.c, introduced in f98d2edb0a
In both cases, we can just call g_file_is_native() directly. This way,
we can drop the chronically-misinterpretted is_local() methods, whose
various interpretations are now covered by specific checking methods:
* g_file_is_native()
* nautilus_file_has_local_path()
* !nautilus_file_is_remote()
The early "return TRUE;" was added because gnome-vfs didn't have a way
to represent all URIs: 5baaa57805
When nautilus was ported to GIO, this early return was kept despite
GnomeVFSURI being superceeded by GFile, which can represent any URI:
469047a2a5
This early return should never happen, because a non-NULL location
is always set.
We use the is_local_or_fuse() method in 2 cases where we want to know
whether a local path can be obtained for a file in a give location:
1) when determining which apps can open the file, as some apps
don't understand URIs;
2) when providing local paths to scripts from the Scripts menu.
It has been returning TRUE for files in the Trash as a special case,
because they are stored in a real location which can be obtained from
the value of the G_FILE_ATTRIBUTE_STANDARD_TARGET_URI attribute.
However, we have been ignoring this attribute for trashed files since
commit bc22321e5b.
This has resulted in two bugs:
1) we pick the default handler to open an application ignoring the
fact that it may not be able to open URIs;
2) we pass relative paths as command-line parameters for scripts,
which they wrongly interpret as being relative to $HOME because
we can't chdir() into trash:///.
As discussed in https://bugzilla.gnome.org/show_bug.cgi?id=768168, we
probably don't want to provide direct access to the real location of
trashed files.
So, let's drop this special case, making is_local_or_fuse() return
FALSE for trash://*, which fixes these two bugs.
That commit mixed the concepts of "file with local path", "local file",
and "native file". They are 3 different things, as documented in GIO.
Now, after the previous commits, the is_local() methods are no longer
employed to check that files have local paths. Instead, we now use
nautilus_file_is_local_or_fuse(), which was introduced[1] in order to
fix[2] for a regression caused by the commit we are now reverting.
[1] 2f1765d803
[2] 4df06e7f14
The nautilus_[directory,file]_is_local() methods have been confounding
the concepts of "native" and "non-remote" files, ever since the port
from gnome-vfs to GIO in 59511dfee330102ee42e09bef37cbc9cd12973c6
This conceptual mismatch is notorious in the Trash location, which is
neither native nor remote. This soon raised a bug [1], which has been
worked around by introducing a check for nautilus_file_is_in_trash().
Now, after the previous commits, the is_local() methods are no longer
employed to check that files are "non-remote". Instead, we now use
nautilus_file_is_remote(), which correctly reports that the trash is
not remote.
So, this workaround can be droped now.
[1] https://bugzilla.gnome.org/show_bug.cgi?id=546353
We have been calling is_local_or_fuse() on the current directory to
know if we can pass local paths for scripts in as an environment
variable.
This is wrong because the current directory may not be the actual
location of the files. That's why a workaround has been introduced for
search directories in commit 8fdd3792ed
But the same problem still happens in the starred:/ directory.
In the case of paths passed as command line parameters, we call
is_local_or_fuse() directly on the files, so there is no need for any
workaround for search and starred. This enhancement had been proposed
in https://bugzilla.gnome.org/show_bug.cgi?id=341657, and introduced
in commit 34d5940998.
However, this enhancement was not applied to the envar case. Let's do
something equivalent now.
The scripts in the Scripts menu are passed the (possibly relative)
local paths to selected files as command line parameters.
The relative paths can only work if the current directory itself has a
local path that we can chdir into, and, for backwards compatibility,
don't pass URIs.
For that reason we pass no parameters if nautilus_file_is_local()
returns FALSE for any of them. [1]
However, it returns FALSE for files in FUSE mounts, which have
perfectly usable local paths.
So, use nautilus_file_is_local_or_fuse() instead.
The scripts in the Scripts menu are passed the local paths of selected
files as a NAUTILUS_SCRIPT_SELECTED_FILE_PATHS environment variable.
But in some cases files may not have a backing local path. We account
for this by checking for the "file:" URI schema. But the accompaining
comment is outdated, because nautilus_directory_is_local() changed
behaviour as a result of the gnome-vfs -> GIO port.
Furthermore, thanks to FUSE, we can have valid local paths for
non-native locations, but we haven't been passing these to scripts.
To fix this, we can use nautilus_directory_is_local_or_fuse() now. Also
drop the eel_uri_is_trash() check, which is now redundact.
When creating a file from template, we fail if the template's not local
This was introduced by commit e5e83363ca
The assumption of being local comes from the original version of that
patch[1], which used filenames instead of URIs, as later explained[2]:
> I was sure that templates will be only stored on the local disk,
> ignoring that we have to pass URIs to GnomeVFS anyway.
As a result of the review process, the usage of filenames was dropped
in favor of URIs, but the precondition check remained, even though it
was no longer necessary.
Remove it now.
[1] https://mail.gnome.org/archives/nautilus-list/2005-June/msg00008.html
[2] https://mail.gnome.org/archives/nautilus-list/2005-June/msg00176.html
The nautilus_file_should_show_thumbnail() method was first introduced
in commit 469047a2a5
It duplicated the tradeoff setting logic that was already present in
get_speed_tradeoff_preference_for_file(), a shared function for both
top left text preview and child directories item count.
(Top left text preview has since been phased out.)
The code duplication grew when support for the filesystem::use-preview
attribute was added in commit 00e59a6b3c
Instead, let's make should_show_thumbnail() use the shared function.
When the thumbnailing and/or item counting preference is 'local-only',
we need to know if a file is local or remote, and for this we use the
nautilus_file_is_local() method.
However, ever since the port from gnome-vfs to GIO, this method relies
on g_file_is_native() instead of gnome_vfs_uri_is_local(), which are
not the same thing. Quoting the GIO docs:
> A native file is one expressed in the platform-native filename
> format, e.g. "C:\Windows" or "/usr/bin/". This does not mean the
> file is local, as it might be on a locally mounted remote filesystem.
So, nautilus_file_is_local() is no longer telling us the truth. This
means we may show thumbnails or item counts for natively-mounted remote
locations when we are not supposed to.
Instead, let's use the nautilus_file_is_remote() method, which relies
on the G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE attribute (which was not
implemented at the time of the GIO port).
Fixes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1478
It compares the filesystem type identifier with a hardcoded list of
remote types introduced in 2015.[0]
The filesystem::remote attribute has been introduced[1] to handle this,
and we have been using it[2], but kept the hardcoded list in order to
workaround issues with GLocalFile not setting this attribute correctly.
Now that these issues have been fixed[3], we can finally drop it.
[0] d3e1a71c63
[1] e57355b055
[2] 99f55748ef
[3] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1534
The tests currently create various files and directories with generic names
and manipulate with them directly in the `/tmp` directory. The tests also
remove all files in `/tmp` with the generic prefixes like `move`, `copy`,
etc. This can simply cause test suite failures if files with such names
already exist in the `/tmp` directory. Also, the test suite can easily remove
files created by other applications. Let's always create an unique directory
in `/tmp` for tests to fix the mentioned problems...
Currently, "Moved 0 files to ..." status is shown if all files were moved
during the initial phase. This is because the initial phase consists of
`g_file_move` calls with `G_FILE_COPY_NO_FALLBACK_FOR_MOVE` flag, however,
the status is printed for files which needs copy&delete fallback. Let's
print the total number of natively moved files in this case instead.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1635
Some GVfs backends doesn't report progress except the total file size. With
the previous patch applied, the remaining time is calculated after each
successfully transfered file for such backends. This is fine for small files,
but looks weird for big files as the estimated time is not updated regularly,
so it looks like hang. One possible solution would be to update the remaining
time periodically even if progress is not reported from GIO. However, this
could again lead to situations, which would look like that the transfer is
hanged. Let's do not report remaining time at all when progress is not reported
to reduce confusion.
Currently, the remaining time for some operations is reported even if
it hasn't been yet computed. Consequently, "596,523 hours left" is
shown to the user as it corresponds to the initial value, which is INT_MAX.
In most cases this is because some GVfs backend doesn't report progress
except the total file size. Let's do not report remaining time if transfer
rate is 0, ie. remaing time is not computed.
Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/232
The SOURCE_INFO_INIT sets the hash table pointer to NULL, and we may go
out of scope before/without calling scan_sources(). So, it's wrong to
assume that .scanned_dirs_info is not NULL.
Interestingly, this didn't break the tests in either the MR or the
main branch. But it did break the move-files test in another branch
after being rebased, because that branch added an early return which
precedes scan_sources(). Thank you tests, and thank you CI!
The size of a copied or moved directory (when represented as a file itself - in
addition to its contents) was not being included in the transferred byte count.
Add code to include size of directory in transferred byte count.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1501
During a copy/move operation the total file count as well are size was
not decremented correctly when a directory was skipped. The file count
and size were only decremented for the directory (being represented as
a single file) but not for the descendants of the directory even though
the count and size of the descendants were included in the original
count for the operation. This caused the reported progress of the copy
operation to be off from the total file count and size when one or more
directories were skipped.
Fix logic to reduce total file count and size of a skipped directory to
account for the descendants of the directory (children files and
subdirectories and their children, recursively).
Since the existing logic for scanning contents does not scan a
directory in a recursive manner but instead adds all identified
directories at the end of a queue to be processed later, additional
data structures were added to hold children file count and size of each
directory scanned during a file operation. Information from this data
structure is accessed to properly decrement the total file count and
size of a directory if it is skipped during a copy/move operation.
This reverts commit 24dae9e0a4.
In situations that allow a directory and its children to be
simultaneously selected for file operations (such as from search
results, the logic implemented in the original commit prevented an
item to be counted more than once. However in the actual copy, move
or delete operation the selected items were copied (or moved or
deleted) as if they were separate top level items thus performing
the operation on the children or subdirectories multiple times (in
addition to processing them as part of the parent directory that was
also included in the selection).
Due to this inconsistency between the sources scan logic and the actual copy
logic the total scanned source file count and size would be less than the
actually transferred file count and size.
Refer https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests/610#note_991810
for more details.
During a "merge" directory copy operation, when recursively merging
a directory to a destination directory that already contains some files
or subdirectories that are being copied, the "skip" flag is set
individually for those files or subdirectories. This correctly reduces
the count total files being copied for each file or subdirectory that
was skipped.
However, the "skipped" flag was then also being set for the parent
directory even though that directory was successfully copied (when
represented as a single file which is also included in the file count).
This ended up incorrectly reducing the total file count even though
the copied file count was incremented for that directory.
Change code to ensure that the "skipped" flag is not set for a
directory when one or more children are skipped.
During a move operation the "skipped" flag was not being set when there
was an error deleting the source directory after copying the source
directory to the new location if "skip-all-error" was selected during a
previous user interaction in the same operation.
We were spawning a background thread for performing the name conflict
check. Since the logic and data used for checking name conflicts
is not thread-safe we were executing the actual conflict check function
in the main thread (via g_main_context_invoke()). That routine in turn
ended up scheduling the actual work to execute in the callback
on_directory_conflicts_ready() per distinct parent directory. Thus
almost all the computationally intensive work was done via multiple
layers of indirection in the main thread.
Modify file_names_list_has_duplicates_async() to simply schedule the
actual name check function to be called per distict parent directory.
As before, most of the computationally intensive work is still done in
the callback registered via nautilus_directory_call_when_ready().
This greatly simplifies the design of the name conflict check by
eliminating the need for thread-safe synchronization of access and
modification of data that is used in the check.
When collecting distinct parent directories of selected files we were
accessing and possibly modifying the selected files GList from multiple
threads without any synchronization causing unpredictable corruption.
We were also performing operations in a background thread on
NautilusFile and NautilusDirectory which are not thread safe.
Identify distict parent dirs only once during dialog initialization and
store it in the instance struct because the selection does not change
during operation of the dialog. This eliminates thread-unsafe operations
when collecting and accessing the list of distinct parent directories.
Closes https://gitlab.gnome.org/GNOME/nautilus/-/issues/1552
