(re)Hi,
I added time of last access in file properties.
Here is a patch.
It works for me, but i'm not familiar with the API,
so if someone could review it...
Thanks,
Maxime
--- e_fm_prop.c.orig 2012-07-18 15:13:42.0 +0200
+++ e_fm_prop.c 2012-07-18 15:53:28.080852267 +0200
@@ -49,7
I'm French, and I also noticed a lot of spelling mistakes.
I can retranslate if you want.
Le 20/07/2012 11:46, Carsten Haitzler (The Rasterman) a écrit :
On Wed, 11 Jul 2012 21:30:50 +0200 Chidambar 'ilLogict' Zinnoury
illog...@online.fr said:
still waiting on a reply from batden here.
Hi,
the 'e_fm_op.c' file uses readlink() function, which doesn't
close path char at end.
In this code:
size_t len;
char path[PATH_MAX];
len = readlink(task-src.name, path[0], PATH_MAX);
path[len] = 0;
the '\0' is placed one byte past the end of path[], so if path[]
is equal or up to
(re)Hi,
when copying symlinks, it creates a symlink to the
destination but with the name of the pointed file/folder.
It causes problems, ex: we can't copy two symlinks
pointing to the same file, because they will have the
same name.
Here is a patch which corrects this. I also found other
Hi,
I was told that I have to explain race conditions I found.
I. Copy file bytes
It concerns 'e_fm_op.c.diff1'. When copying a file, the dest
file is written with bytes read from source file. It only stops
when we are at the end of the source file. The problem
is that you just have to launch a
with the actual svn revision, you can't
see this problem. (And it's not a bug, just a misconception.)
Le 23/07/2012 09:57, Carsten Haitzler (The Rasterman) a écrit :
On Fri, 20 Jul 2012 22:43:21 +0200 rustyBSD rusty...@gmx.fr said:
(re)Hi,
when copying symlinks, it creates a symlink to the
destination
here i disagree.
1. if we copy a file as its downloading - we want to get the rest of the file
that was appended to after the copy began, if we can.
2. try this with cp. cp behaves like efm. if you're telling me this is a
security issue.. then it's a security issue in cp too.. and been
Hi,
quick thing:
=== e/src/modules/wizard/page_080.c ===
line 18 - EAPI int wizard_page_show(E_Wizard_Page *pg __UNUSED__)
Two fopen(), but one fclose(). Should add
fclose(fin); before return 0; .
Maxime
--
Live
Hi,
here is a patch which fixes some things of FIXME in
file e_fm_prop.c.
I added:
- exec permission / group permission
- location (dir)
- last modified permission
- last accessed date
- occuped blocks on disk
- notification of broken symlink
I fixed size of icon (which was malformed).
I also
Hi,
In e/src/bin/e_fm_op.c, free() is used.
Should replace all free() by FREE(), as
free() doesn't do p = NULL.
FREE() avoids dangling pointers.
Maxime
--
Live Security Virtual Conference
Exclusive live event will cover
Hi,
== e/src/bin/e_fm.c ==
line 9261 - _e_fm_retry_abort_dialog(int pid, const char *str)
There is no check if malloc() fails. Should add if (!id) return NULL;
after id = malloc(sizeof(int));. It avoids null pointer dereference.
Same problem in
_e_fm_overwrite_dialog(int pid, const char *str)
Hi,
1. _e_fm_op_copy_link()
we chmod the created symlink. It's useless, because
we use stat() which gives st_mode of pointed file/folder,
and then we use chmod(), which follows symlink; so we
are chmoding a file to the same permissions it had
before.
2. _e_fm_op_symlink_atom()
Just added
Le 22/08/2012 05:27, Carsten Haitzler (The Rasterman) a écrit :
On Tue, 21 Aug 2012 18:01:05 +0200 rustyBSD rusty...@gmx.fr said:
Hi,
== e/src/modules/illume-keyboard/e_kbd_int.c ==
line 972: if (sscanf(buf, %4000s, str) != 1) continue;
str is declared like this: char str[PATH_MAX
Hi,
== src/modules/conf_theme/e_int_config_color_classes.c ==
l. 235: OpenBSD's ctype.h already defines _X.
( http://ftp.cc.uoc.gr/mirrors/OpenBSD/src/include/ctype.h )
So we should use another name.
--
Live Security
== src/bin/e_desklock.c ==
during auth, user's password may be written
to disk (core dump). To avoid that, the solution
is to limit core file size to 0 with|| setrlimit(). The
problem is that once set to 0, the file size can't
be raised; so we can't reset the size to the value
it was before.
Here
Le 22/08/2012 14:12, Tom Hacohen a écrit :
On 22/08/12 15:04, Carsten Haitzler (The Rasterman) wrote:
On Wed, 22 Aug 2012 14:54:30 +0300 Tom Hacohen tom.haco...@samsung.com
said:
On 22/08/12 14:51, Carsten Haitzler (The Rasterman) wrote:
On Wed, 22 Aug 2012 14:46:50 +0300 Tom Hacohen
== src/bin/e_fm_op.c ==
l. 234 277: we are trying to createa
symlink by using symlink(), and if it fails,
we create a task which does exactly the
same thing, but handles overwrite.
Wouldn't it be better to directly create
the task ?
Hi,
in src/bin/e_widget_check.c, the structure
E_Widget_Data has 'int *valptr'. If I'm not
mistaken, it's just used as boolean (true or
false). So why not use Eina_Bool or anything
else 'smaller' ? In e_fm_prop.c, for example,
all int could be Eina_Bool; and if i'm not mistaken
again, it takes
Le 02/09/2012 13:20, Daniel Juyung Seo a écrit :
It looks like valptr is not always boolean. You can set int value to
the check object.
So it's int rather than Eina_Bool.
But yes, most of cases it is used as if it was a boolean.
Anybody has a historical idea on this?
Daniel Juyung Seo
Hi,
in a lot of files, we use calloc(), malloc(),
realloc(), ...
Wouldn't it be good to have stuffs like g_malloc()
which aborts when it cannot allocate memory ?
Because there are a lot of un-null-checked calls,
which could be problematic...
Le 04/09/2012 01:54, Carsten Haitzler (The Rasterman) a écrit :
agreed. if u abort() or segv() it makes little difference. for small data
structs (linked list nodes for example) its VERY hard to recover sensibly from
such an out-of-memory situation. but for large allocs its perfectly possible.
Hi,
== e_fm_op.c l.984 ==
if dst = NULL, strlen() sefaults.
Here is a patch.
--- e_fm_op.c Sat Sep 22 13:31:24 2012
+++ e_fm_op.c Sat Sep 22 13:31:19 2012
@@ -980,6 +980,8 @@
int size, src_len, dst_len;
int ret = 0;
+ if (!dst) return;
+
src_len = strlen(src);
dst_len =
Le 25/09/2012 15:57, Sebastian Dransfeld a écrit :
Something like this (untested!!).
Hi,
I use malloc() because OpenBSD's secure rm
uses malloc too.
I'm not sure mmap() is good, but I'll read some
documentation.
In all cases, your patch doesn't work, as
eina_file_map_all() give a read access.
Le 25/09/2012 15:57, Sebastian Dransfeld a écrit :
Something like this (untested!!).
Hi,
I use malloc() because OpenBSD's secure rm
uses malloc too.
I'm not sure mmap() is good, but I'll read some
documentation.
In all cases, your patch doesn't work, as
eina_file_map_all() give a read access.
Le 27/09/2012 12:10, Carsten Haitzler (The Rasterman) a écrit :
and that's what i did. a fixed buffer of 64kb is malloced - and random filled
or 0xff filled as per before - but just written 64k at a time. and yes - it
handles the tail that may not be a full 64k too.
here's the question...
Le 27/09/2012 18:24, rustyBSD a écrit :
Le 27/09/2012 12:10, Carsten Haitzler (The Rasterman) a écrit :
and that's what i did. a fixed buffer of 64kb is malloced - and random filled
or 0xff filled as per before - but just written 64k at a time. and yes - it
handles the tail that may
Le 27/09/2012 18:55, rustyBSD a écrit :
Le 27/09/2012 18:24, rustyBSD a écrit :
Le 27/09/2012 12:10, Carsten Haitzler (The Rasterman) a écrit :
and that's what i did. a fixed buffer of 64kb is malloced - and random
filled
or 0xff filled as per before - but just written 64k at a time. and yes
Le 28/09/2012 01:41, Carsten Haitzler (The Rasterman) a écrit :
On Thu, 27 Sep 2012 18:55:39 +0200 rustyBSD rusty...@gmx.fr said:
Le 27/09/2012 18:24, rustyBSD a écrit :
Le 27/09/2012 12:10, Carsten Haitzler (The Rasterman) a écrit :
and that's what i did. a fixed buffer of 64kb
Le 28/09/2012 09:04, Carsten Haitzler (The Rasterman) a écrit :
Can you please revert your changes ?
why? its better than the code that was there (your patch). your patch did
this:
1. find out size of file
2. alloc memory for ENTIRE file
3. fill buffer with random data or 0xff
4. write
Le 28/09/2012 12:39, Carsten Haitzler (The Rasterman) a écrit :
you're waiting for vincent to commit patches? what patches? where? by who?
doing what? you planned to do something ... but never mention you did it.
planning and doing are very different things. you didn't say that the patches
you
Le 28/09/2012 19:21, Lucas De Marchi a écrit :
There's no need for a revert here. Code now is better than it was
before. If yours is indeed better yet (didn't look your patch), just
re-diff it and *send* as an improvement. You didn't submit it before
and raster committed a much more sane code.
Hi,
some trivial changes.
I. _e_fm_op_stdin_handler is unused, so - removed.
II. if we cannot malloc _e_fm_op_stdin_buffer, we
are in big shit, so nullcheck.
III. Formatting.
IV. if argc 4 we quit, so we don't need to check
if argc = 4.
V. removed 'ret' variables. They are
Mmmh... The translation of e/src/modules/notification
seems to be broken.
I don't know if it's the right thing to do, but I added
entries in POTFILES.in/.skip.
Then we can removee/src/modules/notification/po.
--- po/POTFILES.in 2012-09-29 13:14:20.739145592 +0200
+++ po/POTFILES.in 2012-09-29
Hi,
I added support for OpenBSD on the cpufreq
module.
Thanks
--- e_mod_main.cSun Sep 30 11:16:50 2012
+++ e_mod_main.cSun Sep 30 11:11:57 2012
@@ -6,6 +6,12 @@
#include sys/sysctl.h
#endif
+#ifdef __OpenBSD__
+#include sys/types.h
+#include sys/sysctl.h
+#include sys/param.h
On 09/30/12 13:57, Vincent Torri wrote:
are you sure about fresqet.c ? Just returning 1 ?
Not really.
I'm looking for a way to change the cpu freq
--
Everyone hates slow websites. So do we.
Make your web apps faster with
On 09/30/12 14:11, rustyBSD wrote:
are you sure about fresqet.c ? Just returning 1 ?
Not really.
I'm looking for a way to change the cpu freq
Mmhh...
The problem with openbsd's sysctl is that
we get cpu freq in Mhz, but we can only set
it in percents - and not up to 100%.
So I put percents
On 10/01/12 08:22, Vincent Torri wrote:
maybe this could help you :
http://stackoverflow.com/questions/4226353/show-memory-and-cpu-in-c
Vincent
?
There is no problem when getting the frequency.
The only difference with linux is that instead
of displaying available frequencies (in the menu),
On 10/01/12 15:20, Vincent Torri wrote:
?
I have seen that :
printf(CPU: %d MHz Free: %ld MB\n, cpuspeed,
sysconf(_SC_AVPHYS_PAGES)*sysconf(_SC_PAGESIZE))20
so it displays the freq in Mhz, no ?
My ? meant that it's not actually the problem.
The freq is correctly displayed in the counter
in
Hi,
== evas_gl_api_ext.h l.4 ==
The GLchar type is already defined on openbsd
(/usr/X11R6/include/GL/glext.h), so it has to
be renamed.
--
Got visibility?
Most devs has no idea what their production app looks like.
Find
On 10/01/12 19:41, Vincent Torri wrote:
is the freebsd support still broken avec your changes ?
Yes I think, but I'm not sure.
--
Got visibility?
Most devs has no idea what their production app looks like.
Find out how
Le 01/10/2012 19:08, rustyBSD a écrit :
Hi,
== evas_gl_api_ext.h l.4 ==
The GLchar type is already defined on openbsd
(/usr/X11R6/include/GL/glext.h), so it has to
be renamed.
You should really use another name.GLchar
already comes with gl/opengl.
OpenBSD and NetBSD don't like
Le 29/09/2012 13:27, rustyBSD a écrit :
Mmmh... The translation of e/src/modules/notification
seems to be broken.
I don't know if it's the right thing to do, but I added
entries in POTFILES.in/.skip.
Then we can removee/src/modules/notification/po.
Sometimes I wonder who I'm talking
Hi,
I looked at the ecore_file_recursive_rm() function
(in ecore/src/lib/ecore_file/), and I wonder why this
is so ugly/complicated.
We are doing a readlink() and two stat(). Why not simply
do a lstat() ?
It takes less memory and it's simplier. Here is a patch.
Am I wrong ?
(And readlink() is
Le 06/10/2012 14:03, Vincent Torri a écrit :
Hi,
I looked at the ecore_file_recursive_rm() function
(in ecore/src/lib/ecore_file/), and I wonder why this
is so ugly/complicated.
We are doing a readlink() and two stat(). Why not simply
do a lstat() ?
note that lstat does not exist on
Le 15/10/2012 10:03, Vincent Torri a écrit :
Maxime: you can separate code with the _WIN32 macro. Can you update
ecore and write a patch that use lstat on non win32 ?
Ok.
--- ecore_file.c 2012-10-15 18:53:22.594116119 +0200
+++ ecore_file.c 2012-10-15 18:52:46.668671104 +0200
@@ -399,22 +399,27
Hi all,
here is a patch for the randomization in
e/src/bin/e_fm_op.c.
I. Simplification, andif we cannot stat(), the best
thing to do is toswitch to a copy-delete operation.
II.Just stuff...
III. There is a problem with _e_fm_op_random_char().
When wewant to randomize a string we do
Hi all,
can someone add gettext support to e/src/bin/e_fm_op.c ?
Thanks !
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Le 15/10/2012 18:57, rustyBSD a écrit :
Le 15/10/2012 10:03, Vincent Torri a écrit :
Maxime: you can separate code with the _WIN32 macro. Can you update
ecore and write a patch that use lstat on non win32 ?
Ok.
So, what's new
Le 30/10/2012 11:44, Michael Blumenkrantz a écrit :
any particular reason?
For translation
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
Hi,
here is a patch for e/src/modules/cpufreq/e_mod_main.c
I. _cpufreq_status_check_available() always returns 1,
so moved to void.
II. Don't need to 'buf[sizeof(buf) - 1] = 0;', as it's
already done by snprintf.
III. Stuff for OpenBSD.
IV. Fixed files descriptors leaks, and removed
Hi,
with recent changes fromCedric Bail in e/src/bin/e_sys_main.c,
OpenBSD needs sys/wait.h. Also removed useless code.
thanks
--- e_sys_main.c Wed Oct 31 16:09:29 2012
+++ e_sys_main.c Wed Oct 31 16:07:00 2012
@@ -6,6 +6,7 @@
#include string.h
#include sys/types.h
#include sys/stat.h
Le 31/10/2012 16:41, Michael Blumenkrantz a écrit :
in. for future diffs please separate out all formatting changes into
separate patches.
ok
--
Everyone hates slow websites. So do we.
Make your web apps faster with
Hi,
I don't really know sensors on linux, but it seems
that there is a mistake in the temperature module.
Here are two patches: the first is for formatting
(it was a shame),the second for the fix.
thanks
--- tempget.c 2012-11-02 16:09:54.045398884 +0100
+++ tempget.c 2012-11-02
Le 30/10/2012 17:41, rustyBSD a écrit :
Hi,
here is a patch for e/src/modules/cpufreq/e_mod_main.c
I. _cpufreq_status_check_available() always returns 1,
so moved to void.
II. Don't need to 'buf[sizeof(buf) - 1] = 0;', as it's
already done by snprintf.
III. Stuff for OpenBSD.
IV
Le 08/11/2012 23:54, Michael Blumenkrantz a écrit :
Hi,
This mail is the official mail informing anyone and everyone working on E17
that we are now in a feature freeze for the upcoming release. This means that
NO
new features should be added unless:
1) They are absolutely crucial for the
Hi,
I just compiled e17 on OpenBSD, and when starting e I
get this:
Enlightenment was started without any configuration
files available for the given profile (normally
default or the last profile used or provided on the
command-line with -profile etc.)
Cannot contiue without configuration to work
Hi,
here are patches to fix compilation on OpenBSD and FreeBSD
(and NetBSD ?).
- The 'tainted' variable is unused, so removed.
- Switch to execv(), as FreeBSD and OpenBSD doesn't have
PTRACE_GETSIGINFO
- Just moved to size_t to avoid warning on FreeBSD
Thanks
--- src/bin/e_start_main.c
Le 09/11/2012 16:39, Vincent Torri a écrit :
I would suggest
#if !defined(__OpenBSD) etc
instead of
#ifdef __linux__
As it will work for Mac OS X, and probably on Solaris too
Btw, it's strange that it works on Mac OS X and not in FreeBSD.
Ah yes, forgot it.
Ialso tested on NetBSD,
Le 12/11/2012 09:10, Vincent Torri a écrit :
On Fri, Nov 9, 2012 at 7:08 PM, Vincent Torri vincent.to...@gmail.com wrote:
On Fri, Nov 9, 2012 at 6:56 PM, rustyBSD rusty...@gmx.fr wrote:
Le 09/11/2012 18:40, Vincent Torri a écrit :
On Fri, Nov 9, 2012 at 6:18 PM, rustyBSD rusty...@gmx.fr
Grr did someone notice that the Black White theme
is uncompilable ??
$ make
edje_cc theme.edc b_and_w.edj
edje_cc: Error. theme.edc:46 unhandled keyword spectrum
edje_cc: Error. PARSE STACK:
spectra.spectrum
edje_cc: Error. PARAMS:
Le 16/11/2012 23:55, Michael Blumenkrantz a écrit :
On Fri, 16 Nov 2012 23:44:07 +0100
rustyBSD rusty...@gmx.fr wrote:
Grr did someone notice that the Black White theme
is uncompilable ??
$ make
edje_cc theme.edc b_and_w.edj
edje_cc: Error. theme.edc:46 unhandled keyword spectrum
Hi,
I have just created a ticket but I'm considered as a spammer
and I can't send backtrace.
So I post it here.
Thanks
#1804: SIGSEGV on BSD's
-+
Reporter: rustyBSD@… | Owner: raster
Type: Bug | Status
Hi,
I would like some guys to test this:
plug an USBkey, then move a lot of files to thiskey by
drag'n'dropping. Move A LOT OF files, not afolder containing
these files. Tell me then if itworks or if it tells something
like not available.
PS: save your data before, and don't check 'Really
Hi,
just a patch to avoid
temperature/tempget.c: In function 'init':
temperature/tempget.c:271: warning: passing argument 3 of 'sysctlnametomib'
from incompatible pointer type
temperature/tempget.c: In function 'check':
temperature/tempget.c:379: warning: passing argument 4 of 'sysctl' from
Le 01/12/2012 09:41, Michael Blumenkrantz a écrit :
On Sat, 01 Dec 2012 08:01:28 +0100
rustyBSD rusty...@gmx.fr wrote:
Hi,
just a patch to avoid
temperature/tempget.c: In function 'init':
temperature/tempget.c:271: warning: passing argument 3 of 'sysctlnametomib'
from incompatible
+--
Reporter: rustyBSD@… | Owner: raster
Type: Bug| Status: new
Priority: Critical | Milestone:
Component: enlightenment | Keywords: segfaulf
Blocked By: | Blocking:
+--
Hi,
when changing
Le 01/12/2012 10:02, rustyBSD a écrit :
We can also fix leaks.
I. Removed useless 'buf[sizeof(buf) - 1] = 0;', fgets()
already does that
II. Ensure file descriptors are closed before 'goto error'
III.We don't need to nullcheck before freeing a buf, as it's
already done
67 matches
Mail list logo
