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.
Being annoyed by different types of eina critical macros - CRI, CRIT,
CRITICAL -, I concluded to unify them to one. Discussed on IRC and
finally, CRI was chosen to meet the consistency with other macros -
ERR, WRN, INF, DBG - in terms of the number of characters.
If there is any missing bits, please let me know.
an errant path made its way into my efreet cache. this had a
side-effect of causing efreetd to scan my entire $HOME recursively
to monitor everything. while the original cause was $HOME getting in,
we shouldn't have efreetd sit and consume scan all of $HOME when this
is far from a normal situation. the recursive scanning is there ot
handle some minimal levels of subdirs in app directories, but not an
entire filesystem, so this mitigates the effects of errant cache data
by limiting the amount of recursion allows for icon dirs and desktop
dirs to 8 and 3 levels respectively.
this fixes T580 ... or SHOULD fix it. there is recursion detection
code now and it properly follows symlinks and dirs. it also properly
updates the file monitor tree for both icons and desktops and it only
monitors dirs, not files (as a dir picks up changes to child data).
tested and it seems not to recurse into self-referencing symlinks
(once it detects the loop) and detects changes nicely in all my tests.
- Store result from mkstemp so we don't leak file descriptor
- No need to chmod, as we set correct umask before createing file
- Use fdopen to open file from file descriptor, not from path
This reverts commit bd5a5e7fce.
sorry about this... all fine eina mkstemp use and all... but this
*BREAKS EFREET*! ibar icons stop working (vanish). efreet no longer
issues a desktop file update event to e etc. etc. etc. ... so let's
keep code that works for now even if it uses mkstemp and not eina...
:) working is better. :)
These binaries are called by efreetd and should be under MODULE_ARCH
dir.
And actually fix the path to efreet_desktop_cache_create that was wrong.
SVN revision: 82489