str(n)dupa are GNU extensions that duplicate a string, using an alloca'd
buffer. This patch removes their definitions from e.h (which should only
contain E's own API, without fallback definitions for libc functions)
which were wrong anyway (they failed in cases where str(n)dupa was an
actual function, not a macro).
Instead, we replace them depending on context with alloca+memcpy+strlen
or a static buffer (used in contexts where we are sure that the buffer
will contain the string entirely)
@fix
Summary:
Since E_FM_OP_OVERWRITE_RESPONSE_NO was sent before file renaming, src had been changed as next file.
->send E_FM_OP_OVERWRITE_RESPONSE_NO after file renaming.
File became empty if I copy a file into same directory
--> first of all, prevent move, rename, symlink into same directory. in case of copy, attach " (copy)" postfix after file name automatically. (need to decide postfix policy)
fixes T739
Reviewers: zmike, raster
CC: seoz, cedric
Maniphest Tasks: T739
Differential Revision: https://phab.enlightenment.org/D707
this simplifies/fixes the case where copying directories and canceling the operation would not correctly propagate the cancel to subtasks (contents of the directory)
T680
Patch from Maxime Villard <rustyBSD@gmx.fr>
"Hum, I've made a mistake in e_fm_op.c with lseek(), I inverted
the two last arguments. However it's not harmful, as SEEK_SET=0.:
SVN revision: 81697
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 srand(time())
foreachcharacter, so if the file is small enough
to be deleted inless than a second, it's not randomized.
And even if it's bigger, it's not goodly randomized.Sorry.
Patch by Maxime Villard rustyBSD
SVN revision: 78469
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 useless and
they were not in old revisions.
VI. _e_fm_op_copy_atom always returns 1, so we don't
need to always check and return 1.
Patch by Maxime Villard (rustyBSD)
SVN revision: 77221
When removing a file, we store a E_FM_OP_DESTROY task,
which overwrites file with 3 passes of (~)randomized
data, and when we store a E_FM_OP_REMOVE task, to remove
the randomized file.
If it's a dir, skip E_FM_OP_DESTROY.
Patch by Maxime Villard (rustyBSD)
SVN revision: 77020
I.
(strncmp(p, p2, PATH_MAX) == 0) &&
((p[p2_len] == '/') || (p[p2_len] == '\0')))
Here we want to know if p and p2 are the same.
It's easier to do a simple 'strcmp(p, p2)', and it's
useless to check the value of p[p2_len], because if
p = p2, p[p2_len] will always be \0.
II. Check the string as for E_FM_OP_MOVE.
III. Just a simplification.
it was something like:
if (type == E_FM_OP_COPY)
X;
if (type == E_FM_OP_COPY)
Y;
else ...
I just replaced by
if (type == E_FM_OP_COPY)
{
X;
Y;
}
else ...
SVN revision: 77015
There is a problem with the realpath() call. When moving
a symlink, realpath() gets the path of the pointed file,
and the name assigned to the copied link is the name of
this file.
So we shouldn't use realpath(), but I don't know an equivalent
which doesn't take care of symlinks.
Here is an example patch.
SVN revision: 76721
$ mkdir /home/test/EMPTY
$ mkdir /home/test/FULL
$ cd /home/test
$ ln -s EMPTY link
Now move (with EFM) the 'FULL' folder to the 'link' (without
opening it), and 'FULL' diseappear.
As the symlink points directly to 'EMPTY', we have not the
full path. So the 'FULL' directory is moved to ~/, instead
of the desired dest.
Here is a quickly-made a patch.
SVN revision: 76591
The rename() function deletes dest file if it exists,
so there is no overwrite handling. Instead of
testing a rename() and if it fails creating a task
to copy-delete the file, we directly create this
task, which handles overwrite.
Patch by Maxime Villard (rustyBSD)
SVN revision: 75489
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.
Patch by Maxile Villard
SVN revision: 75435
Yomi
Daniel Kolesa
Mike Blumenkrantz
Wonguk Jeong
Mike Blumenkrantz
Carsten Haitzler
Mike Blumenkrantz
Igor Murzov
Vincent Torri
rustyBSD