summaryrefslogtreecommitdiff
path: root/src/nautilus-directory.c
Commit message (Collapse)AuthorAgeFilesLines
* directory: Prevent usage of uninitialized hash tableOndrej Holy2023-03-051-0/+5
| | | | | | | | | I see regularly the following debug print on Nautilus startup: `GLib-CRITICAL **: 10:52:52.992: g_hash_table_foreach: assertion 'hash_table != NULL' failed`. This is because the `emit_change_signals_for_all_files_in_all_directories` function is called before the `directories` hash table is initialzed. Let's return early to prevent usage of the uninitialized hash table.
* general: glib deprecations in name onlyCorey Berla2023-01-091-1/+1
|
* general: Use gobject ADD_PRIVATE macrosCorey Berla2023-01-091-3/+2
| | | | Fixes: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1022
* eel: remove eel-glib-extensions.hPeter Eisenmann2022-12-231-1/+0
| | | | | Replace the eel_boolean_bit typedef with a plain guint and remove all includes.
* nautilus-directory: handle change eventsNelson Benítez León2022-02-121-0/+15
| | | | | | | | | | | | | | | | | | | | | for files that were still not known to nautilus because they were in the midst of being added to Nautilus. This happens when eg. inotify fires two consecutive NEW + CHANGE events for a new file, and it's important to handle the CHANGE event as the file may have changed its properties with respect the ones reported at the time the NEW event fired. A case this happens is for mountpoint directories of removable devices, as seen in the referenced bug below. We now queue CHANGE events received for files unknown to Nautilus only when the parent folder is currently adding new files. When the folder finish adding the new files, we then process the list of queued files. If there are still files unknown to Nautilus in this list, they will be ignored as before. https://bugzilla.gnome.org/show_bug.cgi?id=703179 Issue #1576
* general: Stop using gtk_main_iteration()António Fernandes2021-11-221-2/+2
| | | | It's going away with GTK4. Use the recomended replacement.
* directory: Use finite amount of tries for self checkPeter2021-11-131-2/+4
| | | | | | | | Turn potentially infinite while loops into for loops with finite amount of repetitions. In general 1000 tries should be sufficient, so the chosen amount of 100.000 serves as an upper limit. See https://gitlab.gnome.org/GNOME/nautilus/-/issues/1290
* nautilus-directory.c: Fix a memory leak.Michael Webster2021-06-071-1/+1
| | | | | | | | | | | | | | | | | | | | | When creating a new file using a template, it's possible for is_added to be FALSE, so make sure the file is unref'd regardless. This actually resolves an issue in caja and nemo which is caused by files created in this manner not being finalized when no longer in use. I can reproduce the issue with nautilus, but this *does not* fix it, so I think that there may be an additional leak somewhere else (maybe not related to template-created files). To reproduce: - Create an svg file and save in ~/Templates. - Right-click, Create document-> svg file, name it whatever. - Navigate out of the folder. - Modify the file in a visible manner. - Re-enter the folder, note that it never finishes loading. Original report: https://github.com/linuxmint/nemo/issues/2736
* file,directory: Drop obsolete is_local() methodswip/antoniof/local_vs_native_fixupAntónio Fernandes2021-01-251-13/+0
| | | | | | | | | | | | | | | | 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 b3a4eabf01a57b860ea95155f608f33fd08cce27 * files-view.c, introduced in f98d2edb0a71c58127e23a05d58bd12842b57132 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()
* directory: Restructure and document is_local_or_fuse()António Fernandes2021-01-251-9/+31
| | | | | | Avoid calling g_file_get_path() if we have enough information. Clarify the purpose of this function.
* directory: Replace obsolete early return with preconditionAntónio Fernandes2021-01-251-5/+1
| | | | | | | | | | | | The early "return TRUE;" was added because gnome-vfs didn't have a way to represent all URIs: 5baaa578051f2f1249a518c256d84d04f221011a When nautilus was ported to GIO, this early return was kept despite GnomeVFSURI being superceeded by GFile, which can represent any URI: 469047a2a58430026d68a3b99b223b922b18b8d1 This early return should never happen, because a non-NULL location is always set.
* directory: Ignore trash://* in is_local_or_fuse()António Fernandes2021-01-251-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 bc22321e5b5b02711b65d8c1b0301a53de42f18b. 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.
* directory: Revert bfd0b4bf02187b4da6ce0eb7c9a36df5d96ca649António Fernandes2021-01-251-2/+1
| | | | | | | | | | | | | 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] 2f1765d80392c06166d077c27a9a6661edd7c128 [2] 4df06e7f14ffefedc65bae84fca1cd7f5e945f78
* directory: Revert b60f861638f11117174d435860f2409963489995António Fernandes2021-01-251-2/+1
| | | | | | | | | | | | | | | | | | | 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
* nautilus-directory: Implement monitor list with hash tableXiang Fan2019-02-221-2/+14
| | | | | The original linked list can be O(n^2) (n = the number of files) in the worst case.
* directory: Free list as well as unref itemsErnestas Kulik2018-10-091-5/+5
| | | | | filtering_changed_callback() populates a list of directories, but never frees the list.
* file-utilities: Deduplicate max filename querying codeAntónio Fernandes2018-08-021-30/+0
| | | | | | | | | | | A method to query maximum filename length has been introduced by commit a5520fd8930910ffa686232f3fc92325fe47c64e However, Ernestas has noticed that another implementation was already present in nautilus-file-operations.c This commit will replace both with a file-utilities function, which takes ideas from both implementations.
* general: Clean up headers and their inclusionsErnestas Kulik2018-05-181-11/+12
| | | | | | | This commit removes redundant header inclusions and tries to optimize headers by using forward declarations of types in headers. Such optimization should generally make builds speedier in that changes in certain headers will not cause unrelated sources to be rebuilt.
* file: Remove link info attributeAntónio Fernandes2018-05-141-1/+0
| | | | Leftovers from NautilusLink removal.
* directory: Add method to query maximum filename lengthErnestas Kulik2018-05-111-0/+30
| | | | | This is to be used by a potential fix for https://gitlab.gnome.org/GNOME/nautilus/issues/148.
* directory: Warn if extension point not registeredErnestas Kulik2018-03-241-0/+4
|
* general: don’t shadow variablesErnestas Kulik2018-03-011-3/+2
| | | | | | | Shadowing variables is error-prone, since one might mean to refer to a variable that was declared earlier, but has the same name. Additionally, being more strict about variable scoping can help make the code more readable.
* general: Rename from 'favorite' to 'starred'Carlos Soriano2018-02-131-2/+2
| | | | | | | | It was a mix of both terms, given that tracker uses 'favorite' but we use 'starred' in the UI. Since the part that interact with tracker is minimal, is better to be consistent with the UI. This renames 'favorite' to 'starred' except the tracker queries.
* general: remove desktop supportErnestas Kulik2018-01-021-64/+0
|
* directory: use API to get file namesErnestas Kulik2017-12-011-8/+8
| | | | | | | This additionally removes some redundant assertions to avoid needless string copies. https://bugzilla.gnome.org/show_bug.cgi?id=786760
* directory: use API to get file directory objectsErnestas Kulik2017-12-011-26/+45
| | | | | | Another attempt at reducing the amount of internal state accessing. https://bugzilla.gnome.org/show_bug.cgi?id=786760
* Add favorite filesAlexandru Pandelea2017-11-051-0/+14
| | | | | | | Add option to make files Favorite, by either toggling a star in the list view, or from the context menu. https://bugzilla.gnome.org/show_bug.cgi?id=786039
* directory: reorganize static functionsErnestas Kulik2017-08-241-157/+145
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=786760
* vfs-directory: stop poking internal directory stateErnestas Kulik2017-08-241-0/+26
| | | | | | | | This commit moves some NautilusVFSDirectory vfunc overrides to NautilusDirectory, as they directly access NautilusDirectoryDetails fields. https://bugzilla.gnome.org/show_bug.cgi?id=786760
* directory: Remove unused nautilus_directory_is_remote()Bastien Nocera2017-07-181-15/+0
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=784941
* mime-actions: support admin backendCarlos Soriano2016-11-211-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | Until now Nautilus was not able to handle files where the user had no permissions. An error was reported. The only way for a user to handle those files were to start Nautilus with sudo, which is something that shoudl be avoided for security reasons. On Wayland, is not even possible to launch an application with sudo, so this is no longer available and therefor no way to handle files with no permissions. On 3.22 gvfs added an admin backend with integration with Polkit, so a file withouth permissions can be accessed using this backend if the user has the root password. Add support for the admin backend in Nautilus, where a file will be opened using it if cannot be read. There still work to do, basically implement the operations with this backend too and refactor the code to be able to open from nautilus application command line also a file withouth permissions. https://bugzilla.gnome.org/show_bug.cgi?id=773937
* general: initialize smart pointers to NULLRazvan Chitu2016-08-301-1/+1
| | | | https://bugzilla.gnome.org/show_bug.cgi?id=770609
* general: run uncrustifyCarlos Soriano2016-08-291-1248/+1394
| | | | | | | | And make the style of Nautilus the same for all files. Hopefully we can fix all the style issues we can find in the next days, so expect a little of movement on this. https://bugzilla.gnome.org/show_bug.cgi?id=770564
* directory: fix nautilus_directory_is_local()Ernestas Kulik2016-07-181-6/+1
| | | | | | | | | g_file_is_native() should be enough to decide whether the file is local. Checking if g_file_get_path() returns a native path lets us know if the directory is possibly made available by use of FUSE and there is nautilus_directory_is_local_or_fuse() for that. https://bugzilla.gnome.org/show_bug.cgi?id=768733
* directory, file: add function to query FUSE handlingCarlos Soriano2016-04-261-1/+28
| | | | | | | | | | | We use checks to know whether a file is local, using g_file_is_native. However, we also need to know for some cases when a file, even if no native, can be handled like native, using FUSE. This will be needed for the selection of default applications on remote locations, and will be used in a upcoming patch. https://bugzilla.gnome.org/show_bug.cgi?id=764506
* general: merge libnautilus-private to srcwip/csoriano/private-to-srcCarlos Soriano2016-04-251-0/+1902
And fix make distcheck. Although libnautilus-private seem self contained, it was actually depending on the files on src/ for dnd. Not only that, but files in libnautilus-private also were depending on dnd files, which you can guess it's wrong. Before the desktop split, this was working because the files were distributed, but now was a problem since we reestructured the code, and now nautilus being a library make distcheck stop working. First solution was try to fix this inter dependency of files, but at some point I realized that there was no real point on splitting some of those files, because for example, is perfectly fine for dnd to need to access the window functions, and it's perfectly fine for the widgets in the private library to need to access to all dnd functions. So seems to me the private library of nautilus is somehow an artificial split, which provides more problems than solutions. We needed libnautilus-private to have a private library that we could isolate from extensions, but I don't think it worth given the problems it provides, and also, this not so good logical split. Right now, since with the desktop split we created a libnautilus to be used by the desktop part of nautilus, extensions have access to all the API of nautilus. We will think in future how this can be handled if we want. So for now, merge the libnautilus-private into src, and let's rethink a better logic to split the code and the private parts of nautilus than what we had. Thanks a lot to Rafael Fonseca for helping in get this done. https://bugzilla.gnome.org/show_bug.cgi?id=765543
View Lorry Controller Status