some distros 9notably in this case nixos) want to do reproducible
builds. to them this means going around setting mtime for all files to
0. this means efreetd not only thinks mtime is invalid/stupid (0 is
generally just that as midnight on jan 1 1970 is not exactly a
sensible dare for a modified timestamp of a file as no filesystem with
any sanity will have not been modified since that time), but it keeps
mtime at 0 even when things update. this totally breaks efreetd that
expects to find mtime increases over time as things change. it's
necessary because it has to perform a "are mu caches up to date" scan
of all file data it caches and it needs to know if it should rebuild
something based on this.
so this does a few things:
1. it makes mtime have to be an exact match to the cache, not cache
mtime >= file mtime. so any change forward or back is an inavlidation.
2. it now also uses ctime, mode, size, uid, gid, block count and if a
symlink, the sha1 of the symlink path in addition and any change to
these == invalid.
this adds a lot of code and changes how dirs get scanned a bit but it
means it can pick up changes on these 0 mtime distros.
interestingly the policy of mtime being 0 is to have a reprodcible fs
... but ctime still changes and is > 0, as does inode info, so it's
not actually possible to have it totally work... but they try still,
so this is a fix for that problem.
whilst i was doing thisi also noticed efreetd re-red dirs many times
due to icon theme inhritance. i also fixed that to do a LOT less
syscalls by only scanning a dir once as i was rejigging the scanning
code at the time anyway. this should optimize thr scan costs at
efreetd startup too.
@fix
@opt
some distros do odd things with source desktop files and set their
mtime timestamps to 0... thus we can't tell that there is a change.
thier ctimes do change, so consider the newer of either of these as
the modification time to not miss updates
@fix
this must be explicitly added for windows builds
Reviewed-by: Marcel Hollerbach <mail@marcel-hollerbach.de>
Differential Revision: https://phab.enlightenment.org/D8725
Summary:
there is a global variable that is defined tentatively.
this patch modify it not to be tentitive explictly.
Reviewers: raster, cedric, zmike
Reviewed By: raster, zmike
Subscribers: #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D8551
a new shiny buildtool that currently completes in the total of ~ 4 min..
1 min. conf time
2:30 min. build time
Where autotools takes:
1:50 min. conf time
3:40 min. build time.
meson was taken because it went quite good for enlightenment, and is a traction gaining system that is also used by other mayor projects. Additionally, the DSL that is defined my meson makes the configuration of the builds a lot easier to read.
Further informations can be gathered from the README.meson
Right now, bindings & windows support are missing.
It is highly recommented to use meson 0.48 due to optimizations in meson
that reduced the time the meson call would need.
Co-authored-by: Mike Blumenkrantz <zmike@samsung.com>
Differential Revision: https://phab.enlightenment.org/D7012
Depends on D7011
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.
Carsten Haitzler
Vincent Torri
Mike Blumenkrantz
Wonki Kim
Marcel Hollerbach
Bryce Harrington
Stefan Schmidt
Al Poole
Ivan Furs
Sungtaek Hong
Mike Blumenkrantz
Jean Guyomarc'h
Vincent Torri