This has not been used for a while and is not even buildable after our
switch to meson. It was a niche to start with given that it needed the
PS3 OS to run on. I asked for any remaining users at EDD and on the list
but heard nothing. Time to remove.
Signed-off-by: Stefan Schmidt <s.schmidt@samsung.com>
Reviewed-by: Cedric BAIL <cedric.bail@free.fr>
Differential Revision: https://phab.enlightenment.org/D10778
Introduced in 9b294d6284 the new eina_file_statgen_* API has a typo in
its disable function. Fixing this before it gets out into a release.
Thanks goes to the https://abi-laboratory.pro service for offering their
great API/ABI reports to the open source communities to help finding such
things!
Differential Revision: https://phab.enlightenment.org/D9962
coverity doesnt like inconsistent behavior of code, so make it
consistent even if pointless as this is during init when we wont have
threads .... yet.
CID 1403903
this is a performance optimization. it brings in a "stat generation".
for now it's disabled by default so we retain previous behavior. this
stops eina file from opening and stating a file every time you open
... it only does it if stat generation is off, or, if the generation
changed since the last time it opened that file. this makes cache hits
not have a 3 syscall cost (open+fstat+close). this optimizes that
lower end of things path. but .. it comes at a cost. if the file
changes before generation ticks over (which this forces to tick over
every time the loop exits idle by default).
now here is something to ask.
1. should we have this on by default and accept the "inexactness"
since you can eina_file_statgen_next() before any call that would do
i/o to force it to look at the real file stat info...
2. should we tick over every idle enter OR every N idle enters or
every frame we render instead? ... i want to avoid getting a timestamp
or having a timer interrupt often... so what should we do?
at least this introduces the idea, some api's and an env var to turn
this on. it definitely cuts down syscalls during things like creation
of widdgets or objects in large batches etc.
Summary:
From (1) "the following commit" message, the changed condition in this patch
should check if the virtualized file is copied or not.
In eina_file_virtualize
head_padded = 16 * ((sizeof(Eina_File) + slen + 15) / 16);
file->global_map = ((char *)file) + head_padded;
In eina_file_dup
file->global_map != (void*)(file->filename + strlen(file->filename) + 1)
Because of this discord condition makes eina_file_dup copies always.
(1) This is "the following commit":
commit 4766316935
Author: Cedric Bail <cedric@osg.samsung.com>
Date: Wed Mar 8 10:13:36 2017 -0800
eina: force copy of not copied virtualized file while doing an eina_file_dup.
The other way around is pretty much impossible as you don't know who does
an eina_file_dup and for how long they keep there reference.
T5234
Reviewers: zmike, Hermet
Reviewed By: zmike
Subscribers: cedric, #reviewers, #committers
Tags: #efl
Differential Revision: https://phab.enlightenment.org/D6857
As the filename is now a stringshare, also make sure virtual
files use stringshares for the filename! Also when unmapping
we still need to test whether it is copied or not as unmap
will break on less tolerant architectures.
@fix T6449
since we have a sigbusd handler that flags an eina file with io errors
it has to walk the file cache and every file... taking locks. if those
locks were taking already in the current thread the sighandler was
called in... we'd deadlock. since this basicallly never happens (when
do we see i/o errors really? not much)... we never saw this as it'd
also reauire this race condition to happen too. but it is a problem
waiting to happen. this fixes that by moving to recrusive locks.
@fix
Summary:
This was causing problems on non-Linux architectures as eina_file_real_close unmapped not mapped data. Added a "copied" flag to Eina_File which is set on eina_file_virtualize (on copied data), and tested for when eina_file_real_close does the unmap. I'm surprised Linux allowed this. Certainly all of the BSDs crashed with the previous behaviour.
@fix T5479
Test Plan: Example inlcude Rage and Enlightenment Thumb on BSD systems which use eina_file_virtualize with emotion to obtain album artwork.
Reviewers: raster, cedric, jpeg
Reviewed By: jpeg
Maniphest Tasks: T5479
Differential Revision: https://phab.enlightenment.org/D5006
so we copy data to an UNALINED memory address (just after whatever
string we packed on the end of the eina file struct header). this is
bad. especially for non-intel architectures. this forces a 16 byte
alignment which should cover us.
@fix
I'm not sure about the rest of this code, so it's possible that
the index is increased even if it shouldn't. But I've observed
a crash at this line, apparently when reaching the end pointer.
Summary: CreateFileMapping return handle. The handle before use is always closed. This handle can be immediately closed after use.
Reviewers: cedric, raster, vtorri, rimmed, an.kroitor, FurryMyad, NikaWhite
Reviewed By: raster
Subscribers: artem.popov, cedric, jpeg
Tags: #windows
Differential Revision: https://phab.enlightenment.org/D4699
file != NULL does not mean it's valid. Since Eina_File is
a basic eina type a magic check is still better than nothing.
It can avoid doing eina_file_dup() on a closed file for instance.
This "fixes" a crash in eina_file_close with invalid files.
Now I can go hunt the root cause...
If the template is a path, mkstemp and mkdtemp would fail
miserably as they would try to create a file inside
/run/user/1000//path/to/file.XXXXXX even if the path did not
exist.
This patch fixes that by creating temp files inside the sys temp
dir iif the templatename is just a basic name without path
separator.
@fix
This reverts commit 22b45f220c.
eina_file_cleanup always does an eina_tmpstr_del. This is now capable of doing
double or even triple free in some case.
Summary:
Apparently eina_tmpstr_strlen counts the null character as well. This
doesn't follow how strlen works, as the latter excludes it from the count.
This resulted in mistreatment of the string in _eina_file_escape, with
tmp_str paths that had "../".
This fix will do for now, but it is advised that we avoid using
eina_tmpstr_strlen, to prevent such confusions in the future.
Test Plan:
The following lines will throw a valgrind 'invalid read of size 1' error
prior this fix:
char *path = "home/mydir/../myfile";
Eina_Tmpstr *tmp_str = eina_tmpstr_add(path);
char *ret_path = eina_file_path_sanitize(path);
@fix
Reviewers: cedric, stefan_schmidt
Subscribers: tasn, cedric
Differential Revision: https://phab.enlightenment.org/D1929
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
This reverts commit f52f562891.
This is reverted because it breaks eina_file_path_sanitize when using
"/../" in paths, for example:
eina_file_path_sanitize("/home/../mydir/myfile")
returns: "/mydir/myfili"
What invalid read size does this fix? Why was no test case specified?
Anyway, this change affects too much code to leave it in like this.
There seems to be an intent to check that UID==EUID
before calling getenv to get the temp directory.
But that was lost in commits 61478af3a6 and
then in e105abc99e.
XDG_RUNTIME_DIR gives us a nice securty benefit by only allowing the
same user to read wand write files.
In some configuration this is problematic though. If one looks at the
bug report this fixes for example you can see that there are build
scripts that use a special build user.
The way this has always worked on unix is that you can define your
own tempdir with TMPDIR. When I was making the original change towards
XDG_RUNTIME_DIR I expected some trouble with it but it worked quite
well so far.
To avoid breaking scripts out there and maybe configurations we
haven't tested yet give TMPDIR precedence over XDG_RUNTIME_DIR.
Fixes T1766
umask() sets the permissions of the file to read-only on Windows
(see umask documentation on MSDN).
This breaks the creation of .edj file (epp needs to modify the
created file).
Anyway, on Windows, permissions should be given to anybody.
@fix
Signed-off-by: Cedric BAIL <cedric@osg.samsung.com>
Instead using $TMPDIR and falling back to /tmp we now try $XDG_RUNTIME_DIR
first.
"$XDG_RUNTIME_DIR defines the base directory relative to which user-specific
non-essential runtime files and other file objects (such as sockets, named
pipes, ...) should be stored. The directory MUST be owned by the user, and
he MUST be the only one having read and write access to it. Its Unix access
mode MUST be 0700."
While improving our security by isolating these files from other users this
has the potential to break things. I have not seen any breakage in testing
but keep this commit in mind if something strange happens on your system.
Summary:
when dest directory is protected from writing success value was returned
@fix
Reviewers: seoz, cedric, Hermet
Reviewed By: Hermet
Subscribers: cedric, reutskiy.v.v
Differential Revision: https://phab.enlightenment.org/D1366
Stefan Schmidt
Carsten Haitzler
Vincent Torri
Shinwoo Kim
Al Poole
Cedric Bail
Jean-Philippe Andre
Ivan Furs
Vincent Torri
Andy Williams
Jaeun Choi
Tom Hacohen
Daniel Hirt
Romain Perier
Vincent Torri
Andrii Kroitor
Daniel Kolesa
Cedric BAIL
ChunEon Park