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
during the copy, the file can be accessed by users.
See http://cwe.mitre.org/data/definitions/689.html
So we apply the access rights after the creation of
the dest file.
Patch by Maxime Villard
SVN revision: 74284
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.
Also when copying, if it's a link, we fill the destination
in the struct task, then, after we check overwrite with
_e_fm_op_handle_overwrite()
Here is a patch which corrects this.
Patch by Maxime Villard (rustyBSD), modified a bit by me (add 2 free() + formatting)
SVN revision: 74264
Mike Blumenkrantz
Igor Murzov
Carsten Haitzler
Vincent Torri
rustyBSD