Summary:
This fixes a typo in the fix 55676b33, which introduced an invalid early
return from the save_list function, preventing it from outputing the
list data to the file.
@fix CID1375005, CID1375004
Reviewers: jpeg
Reviewed By: jpeg
Subscribers: stefan_schmidt, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4873
This fixes the commit 169a08c03a (efreetd:
BSD optimizations). Coverity rightly pointed out six different leaks of
various buffers on error paths.
CID: 1374949 1374950 1374951 1374952 1374953 1374954
Summary:
winsock2.h included in Ecore.h
But Ecore.h ' is included in
/bin/efreet/efreet_desktop_cache_create.c
src/bin/efreet/efreet_mime_cache_create.c
src/tests/ecore_con/ecore_con_test_efl_net_ip_address.c
Reviewers: NikaWhite, cedric, raster, an.kroitor
Reviewed By: raster
Subscribers: artem.popov, cedric, jpeg
Differential Revision: https://phab.enlightenment.org/D4687
if a setuid app needs efreet - it will not be able to contact the
users' efreetd and thus may spawn it's own... and thus we cant have
this now spawned efreetd using env vars inherited from the
unpriveleged etc. user, so ignore them.
Summary:
- old_file_ids is freed but not set as NULL.
If it goes to error code, old_file_ids will be freed again.
Reviewers: jpeg, cedric, Hermet
Reviewed By: Hermet
Subscribers: conr2d
Differential Revision: https://phab.enlightenment.org/D4467
so efreet mime was loading a bunch of mime type info files, parsing
them on startup and allocating memory to store all this mime info -
globs, mimetype strings and more. all a big waste of memory as its
allocated on the heap per process where its the SAME data files loaded
every time.
so make an efreet mime cache file and a tool to create it from mime
files. mmap this file with all the hashes/strings in it so all that
data is mmaped once in memory and shared between all processes and it
is only paged in on demand - as actually read/needed so if your
process doesnt need to know about mime stuff.. it wont touch it anyway.
this saves about 240-300k or so of memory in my tests. this has not
covered the mime MAGIC files which still consume memory and are on the
heap. this is more complex so it will take more time to come up with a
nice file format for the data that is nicely mmaped etc.
@optimize
set EFREETD_LOG to something to get efreetd to log. otherwise efretd
log files can end up rather larth and since they go in xdg_runtimedir
- thats mostly a ramdisk... they eat actual ram. so save a lot of
memory and only log if asked to.
@fix
partially reverts e4d815dc48
this caused efreetd to crash almost immediately due to non-stringshared
strings being used in a stringshare-only hash data descriptor
lots of long paths for monitoring file paths for icons etc. are in
memory for efreetd. this reduces that memory by sharing them much more.
@optimization
so efreets tmp file/cache/log file handling was broken, using
filenames in tmp and renaming them to a caceh dir that can be on
different filesystems. also log file should have been in a tmp dir ...
and subsidrs cache didnt get renamed properly at all and thus not
updated.
@fix
libgen is needed on OSX because it contains the prototype
of basename() which is required in the compiling unit.
The result of basename() was therefore implicitely converted into
an integer, which could leed to subtile issues.
@fix
since the conversion from dbus -> ecore-ipc, efreetd has failed to
notify when a cache build has completed, instead only sending the current
state of the desktop cache: not built
fix T2733
@fix
@fix
this is wrong - start monitoring every/any dir in which a desktop file
exists that we load a desktop file from. imagine you browse directories
in efm with lots of desktop files in them - we end up monitoring lots
of directories that we then rememebr and don't un-monitor. this
disables monitoring of dirs from which we load a .desktop file from to
fix this.
Commit 0cd59bb1 introduced the use of basename()
which needs libgen.h (hence winsock2.h before) on Windows.
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
if a client added $home in the efreet extra desktops dirs, then
efreetd would detect and nuke cache, exit, causing a restart cycle
forever. this makes efreet simply ignore the errant dir so it can keep
working.
@fix
this fixes warnings about no efreet dbus session bus in non session
environments as brought up on the mailing lists with:
Subject: Re: [E-devel] [EGIT] [core/efl] master 01/01: edje: unset
efreet cache update flag to prevent dbus connections
this moves all of efreetd client and server to ecore ipc, with client
auto-launching efreetd if not found as a service and trying for up to
500ms to connect. efreetd times out on last connection or no
connections after 10sec so it wont hang around forever if not in use.
it seems to work in my testing, so let me know if there is an issue.
@fix
Summary: Fix coverity CID1294212 (potential Null pointer dereference) as
the alloc for subdir_cache Could fail, however if it does we Were
still trying to use it. In the case that it fails, ERR msg and return.
@fix
Signed-off-by: Chris Michael <cp.michael@samsung.com>
efreetd was losing the last char on every line of extra_icon.dirs and
icon.exts thus resulting in gradual degredation of these files as more
and more changes happen to have things like:
.jpeg
.jpe
.jp
.j
.
etc. for extension or dirs like
/home/raster/.e/e/icons
/home/raster/.e/e/icon
/home/raster/.e/e/ico
...
/home/ras
/home/ra
/home/r
...
/ho
/h
/
.. you get the idea. before long the list of extra icon dirs (and
extensions) was massigve and caued all sorts of filesystem rummaging.
this fixes that to no longer degrade these files. this also changes
their names to force new files to be used instead of the broken old
ones.
if you unlink then rename, there is a gap between the unlink and
rename - no file is there. the point of the rename is to be atomic.
either old file OR new file. nothing in between. this fixes that race.
this fixes major slowness in things like enlightenment login. when
enlightenment starts, efreetd is started. efreetd takes a long time to
start because it is scanning lots of directories recursively. it is
early in code freeze, so i think this can go in as a fix, even though
it is more of an optimization, but as such it has a fairly major speed
impact, so i consider this fixing a core performance problem for
things like logging in. The solution is a cache file containing all
the sub directories in a directory tree. we still have to stat every
directory, but this avoids a lot of stating of all files as well and
avoids any readirs etc. so it is much faster. on an ssd this comes out
to 4 times faster for efreetd to start up. on an hdd it's about 2x
faster to start uncached.
this should bea good fix for startup times - on my systems thats a 1
second speedup on ssd (out of about 8 seconds boot time) and 3 seconds
on hdd (out of about 39 seconds boot). so w save 1 and 3 seconds
respecively in boot + login.
now can we get this to 0 or close? that's a matter of designing
something like a deferred scan + monitor add so we wait until "startup
is done" then set up in the bg for a bit. that might shave another 3
seconds off boot time for hdd's but for ssd's wil barely blip (maybe
save 0.1 sec). so leave that till normal dev mode.
@fix
i found my efreetd was not just monitoring a small set of dirs but
literally $HOME - recursively. this explains a lot of performance
issues i have seen on spinning hdd's vs ssd's. i never knew if was in
efreetd though... until now. for whatever reason my efret cache caused
efreet to try monitro a list like:
/
/h
/ho
/hom
/home
/home/
/home/r
... etc.
when trying to monitor something like:
/home/raster/.local/share/icons
that means it ended up trying $HOME as wellas a vast range of dirs it
just shouldn't sensibly ever try. i have no idea how my cache ended up
this way, but deleting it and re-populating it fixed it. so this ads
code to detect such insanity (as wellas give actual complaints on deep
recursion so we can see things better later). not a bug fix as such,
but a major improvement to detecting bugs which is what we want for
stability.
I also noticed that one legacy pixmaps dir is not recursively
monitored, but another is - so be consistent and recurs both.
Also apply checks to desktop file monitoring too.