On Fri, 28 Sep 2012 13:15:22 +0200 Sebastian Dransfeld
said:
> On 09/28/2012 12:28 PM, rustyBSD wrote:
> > 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
> >>
On Fri, 28 Sep 2012 17:41:37 +0200 rustyBSD said:
> 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 a
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 co
On Fri, Sep 28, 2012 at 12:41 PM, rustyBSD wrote:
> 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 v
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
>
On 09/28/2012 12:28 PM, rustyBSD wrote:
> 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
Hello,
On 09/28/2012 11:28 AM, rustyBSD wrote:
> Le 28/09/2012 09:04, Carsten Haitzler (The Rasterman) a écrit :
> You fucking don't understand what i told.
>
> I told that
>
> I HAVE ALREADY MADE A PATCH WHICH DOES A BETTER JOB
> THAN YOURS, AND THAT I'M JUST WAITING FOR VTORRI
>
> Isn't that
On Fri, 28 Sep 2012 12:28:40 +0200 rustyBSD said:
> 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 memor
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.
On Fri, 28 Sep 2012 07:05:50 +0200 rustyBSD said:
> Le 28/09/2012 01:41, Carsten Haitzler (The Rasterman) a écrit :
> > On Thu, 27 Sep 2012 18:55:39 +0200 rustyBSD said:
> >
> >> > Le 27/09/2012 18:24, rustyBSD a écrit :
> >>> > > Le 27/09/2012 12:10, Carsten Haitzler (The Rasterman) a écrit :
>
On Fri, 28 Sep 2012 14:37:44 +0900 Cedric BAIL
wrote:
> On Fri, Sep 28, 2012 at 2:00 PM, Joerg Sonnenberger
> wrote:
> > On Thu, Sep 27, 2012 at 07:10:29PM +0900, Carsten Haitzler wrote:
> >> here's the question... this is pretty lame security-wise.
> >> shouldn't we be military/cia/nsa spec and
On Fri, Sep 28, 2012 at 2:00 PM, Joerg Sonnenberger
wrote:
> On Thu, Sep 27, 2012 at 07:10:29PM +0900, Carsten Haitzler wrote:
>> here's the question... this is pretty lame security-wise. shouldn't we be
>> military/cia/nsa spec and overwrite it at least 7 times? :) oh and this will
>> probably/po
Le 28/09/2012 01:41, Carsten Haitzler (The Rasterman) a écrit :
> On Thu, 27 Sep 2012 18:55:39 +0200 rustyBSD 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 is mall
On Thu, Sep 27, 2012 at 07:10:29PM +0900, Carsten Haitzler wrote:
> here's the question... this is pretty lame security-wise. shouldn't we be
> military/cia/nsa spec and overwrite it at least 7 times? :) oh and this will
> probably/possible get screwed by logging fs's or flash media that may shuffl
On Thu, 27 Sep 2012 18:55:39 +0200 rustyBSD 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 is malloced - and random
> >> filled or 0xff filled as per before - but just written 6
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 ti
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 not
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...
On Thu, 27 Sep 2012 19:10:29 +0900 Carsten Haitzler (The Rasterman)
wrote:
> On Wed, 26 Sep 2012 08:41:00 +0200 Sebastian Dransfeld
> said:
>
> > On 09/25/2012 06:01 PM, rustyBSD wrote:
> > > Le 25/09/2012 15:57, Sebastian Dransfeld a écrit :
> > >> Something like this (untested!!).
> > > Hi,
>
On Wed, 26 Sep 2012 08:41:00 +0200 Sebastian Dransfeld
said:
> On 09/25/2012 06:01 PM, rustyBSD wrote:
> > 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 mma
On Mon, 24 Sep 2012 12:55:31 +0200 Sebastian Dransfeld
said:
> On 09/22/2012 08:29 PM, Enlightenment SVN wrote:
> > Log:
> > E17: Added secure delete option (experimental !). Wait for discomfitor to
> > add it to EFM conf panel
> >
> >When removing a file, we store a E_FM_OP_DESTROY task,
> >
On 09/25/2012 06:01 PM, rustyBSD wrote:
> 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 d
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. S
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. S
On 09/24/2012 12:55 PM, Sebastian Dransfeld wrote:
On 09/22/2012 08:29 PM, Enlightenment SVN wrote:
Log:
E17: Added secure delete option (experimental !). Wait for discomfitor to add
it to EFM conf panel
When removing a file, we store a E_FM_OP_DESTROY task,
which overwrites file with
On 09/22/2012 08:29 PM, Enlightenment SVN wrote:
> Log:
> E17: Added secure delete option (experimental !). Wait for discomfitor to add
> it to EFM conf panel
>
>When removing a file, we store a E_FM_OP_DESTROY task,
>which overwrites file with 3 passes of (~)randomized
>data, and when
okay, I know alloc checks are good and everything, but I'd really like to
avoid turning the e17 codebase into a giant spaghetti monster with checking
every alloc; if you're going to check one, check them all; we're not going
to check them all. if it's not in e_sys_main or e_fm_op or e_alert, don't
i've forgotten to say that it was a patch from Maxime Villard (rustyBSD)
sorry
Vincent
On Sat, Aug 25, 2012 at 12:18 AM, Enlightenment SVN
wrote:
> Log:
> E: minor changes
>
>* useless define
>* formatting and useless comment
>* fread() returns a number >= 0
>* symlink returns -
On Sun, 18 Apr 2010, hannes.janet...@gmail.com wrote:
On Sun, Apr 18, 2010 at 7:29 AM, Enlightenment SVN
wrote:
Log:
Replace the description "Everything" by "All" as there
is a conflict with the Everything module wrt translations.
'Everything' shouldnt be translated, just like 'enlighten
On Sun, Apr 18, 2010 at 7:29 AM, Enlightenment SVN
wrote:
> Log:
> Replace the description "Everything" by "All" as there
> is a conflict with the Everything module wrt translations.
>
'Everything' shouldnt be translated, just like 'enlightenment' so
there is no conflict, or was there any?
> Au
30 matches
Mail list logo
