On 06/02/11 18:40, Goswin von Brederlow wrote:
I absolutely hate that. A header file should be compilable on its
own. The times when #include would slow down the compiler are
long gone and all include files are protected with #ifndef NAME so
duplicate includes are harmless.
On the other hand f
Shachar Shemesh writes:
> On 26/01/11 13:03, Goswin von Brederlow wrote:
>>
>> Some things I noticed:
>>
>> safewrite.h:
>> - missing headers, e.g. for mode_t
>>
> No. That's intentional. I'm assuming the people who will use
> safewrite.h are going to RTFM, where it clearly says that those
> incl
On 26/01/11 13:03, Goswin von Brederlow wrote:
Some things I noticed:
safewrite.h:
- missing headers, e.g. for mode_t
No. That's intentional. I'm assuming the people who will use safewrite.h
are going to RTFM, where it clearly says that those includes are needed.
I might reconsider if val
"Hendrik Sattler" writes:
> "char buffer[0];" is veeery gcc-specific as the storage size of buffer
> is 0. According to the C99 standard:
> "6.7.5.2 Array declarators
> Constraints
> 1 In addition to optional type qualifiers and the keyword static, the [ and
>] may delimit an expression or
On Sat, Jan 29, 2011 at 1:53 PM, Ted Ts'o wrote:
> On Fri, Jan 28, 2011 at 07:37:02AM +0100, Olaf van der Spek wrote:
>>
>> Is there a way to log cases where (potentially) unsafe writes happen?
>> Cases like truncation of an existing file, rename on a target that's
>> not yet synced, etc.
>
> Not
On Fri, Jan 28, 2011 at 07:37:02AM +0100, Olaf van der Spek wrote:
>
> Is there a way to log cases where (potentially) unsafe writes happen?
> Cases like truncation of an existing file, rename on a target that's
> not yet synced, etc.
Not really, because there are plenty of cases where it's perfe
On Friday 28 January 2011 03:26:42 Ted Ts'o wrote:
> On Wed, Jan 26, 2011 at 06:14:42PM +0100, Olaf van der Spek wrote:
> > On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
> >
> > wrote:
> > > BTW: KDE4 is a very good example for failure with modern filesystems. I
> > > regularly loose configu
On Fri, Jan 28, 2011 at 3:26 AM, Ted Ts'o wrote:
> On Wed, Jan 26, 2011 at 06:14:42PM +0100, Olaf van der Spek wrote:
>> On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
>> wrote:
>> > BTW: KDE4 is a very good example for failure with modern filesystems. I
>> > regularly loose configuration files
On Wed, Jan 26, 2011 at 06:14:42PM +0100, Olaf van der Spek wrote:
> On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
> wrote:
> > BTW: KDE4 is a very good example for failure with modern filesystems. I
> > regularly loose configuration files when suspend-to-ram fails even if the
> > configuration
On 2011-01-26 17:36:19 +0100, Hendrik Sattler wrote:
> Zitat von "Goswin von Brederlow" :
>
> >"Hendrik Sattler" writes:
> >
> >>Zitat von "Goswin von Brederlow" :
> >>
> >>>typedef struct {
> >>>int fd;
> >>>char buffer[0];
> >>>} safe_t;
> >>>
> >>>and allocating the struct as b
On Wed, Jan 26, 2011 at 7:25 PM, Hendrik Sattler
wrote:
> Zitat von "Olaf van der Spek" :
>
>> On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
>> wrote:
>>>
>>> BTW: KDE4 is a very good example for failure with modern filesystems. I
>>> regularly loose configuration files when suspend-to-ram fai
Zitat von "Olaf van der Spek" :
On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
wrote:
BTW: KDE4 is a very good example for failure with modern filesystems. I
regularly loose configuration files when suspend-to-ram fails even if the
configuration of the running programs were not changed. Yay
On Wed, Jan 26, 2011 at 5:36 PM, Hendrik Sattler
wrote:
> BTW: KDE4 is a very good example for failure with modern filesystems. I
> regularly loose configuration files when suspend-to-ram fails even if the
> configuration of the running programs were not changed. Yay :-( And this is
> with XFS, no
Zitat von "Goswin von Brederlow" :
"Hendrik Sattler" writes:
Zitat von "Goswin von Brederlow" :
Adam Borowski writes:
On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:
Shachar Shemesh writes:
> I've promised to get a library out there, and here it is. The base URL
>
On Wed, Jan 26, 2011 at 5:09 PM, Goswin von Brederlow wrote:
> typedef struct {
> int fd;
> char buffer[];
> } safe_t;
>
> or what do you mean by invalid C?
Zero length arrays are not valid C AFAIK.
--
Olaf
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a
"Hendrik Sattler" writes:
> Zitat von "Goswin von Brederlow" :
>
>> Adam Borowski writes:
>>
>>> On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:
Shachar Shemesh writes:
> I've promised to get a library out there, and here it is. The base URL
> is https://git
Zitat von "Goswin von Brederlow" :
Adam Borowski writes:
On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:
Shachar Shemesh writes:
> I've promised to get a library out there, and here it is. The base URL
> is https://github.com/Shachar/safewrite, and the actual code is a
Adam Borowski writes:
> On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:
>> Shachar Shemesh writes:
>> > I've promised to get a library out there, and here it is. The base URL
>> > is https://github.com/Shachar/safewrite, and the actual code is at
>> > https://github.com/Sha
On Wed, Jan 26, 2011 at 11:36 AM, Goswin von Brederlow
wrote:
> I think you are dead wrong there Ian. Even if every single program is
> dead right (and we know a lot aren't) that means every one of them has
> a safe file update function somewhere in it.
>
> A function doing exactly the same thing
On Wed, Jan 26, 2011 at 12:22 PM, Adam Borowski wrote:
>> typedef struct {
>> int fd;
>> char buffer[PATH_MAX];
>> } safe_t;
>
> Except, you can't rely on PATH_MAX on any modern system. It's defined in
> Linux headers to an arbitrary value to make old code compile, but for
> examp
On Wed, Jan 26, 2011 at 12:03:52PM +0100, Goswin von Brederlow wrote:
> Shachar Shemesh writes:
> > I've promised to get a library out there, and here it is. The base URL
> > is https://github.com/Shachar/safewrite, and the actual code is at
> > https://github.com/Shachar/safewrite/blob/master/saf
Shachar Shemesh writes:
> Hi all,
>
> I've promised to get a library out there, and here it is. The base URL
> is https://github.com/Shachar/safewrite, and the actual code is at
> https://github.com/Shachar/safewrite/blob/master/safewrite.c
>
> This is not a formal release just yet (plus one func
Ian Jackson writes:
> Shachar Shemesh writes ("Re: Safe file update library ready (sort of)"):
>> I'm sorry, it might be me, but I fail to see the overlap between the
>> functionalities of safewrite vs. userv. The premises for safewrite is
>> that a program
On Tue, Jan 4, 2011 at 7:19 PM, Ian Jackson
wrote:
> Having said that, I don't think the concept behind your library is
> sound, because it presupposes that all previous programs which update
> files are buggy.
They are. Kinda. They either do unsafe file updates or they have
regressions from the
Shachar Shemesh writes ("Re: Safe file update library ready (sort of)"):
> I'm sorry, it might be me, but I fail to see the overlap between the
> functionalities of safewrite vs. userv. The premises for safewrite is
> that a program wants to make sure data integrity is ma
Shachar Shemesh writes ("Safe file update library ready (sort of)"):
> This is not a formal release just yet (plus one function is still
> missing an implementation, trivial though it might be). It's just that
> the list obviously has a few people knowledgeable on the su
On 04/01/11 16:24, Ian Jackson wrote:
Shachar Shemesh writes ("Safe file update library ready (sort of)"):
This is not a formal release just yet (plus one function is still
missing an implementation, trivial though it might be). It's just that
the list obviously h
Hi
Dne Mon, 03 Jan 2011 15:56:44 +0200
Shachar Shemesh napsal(a):
> In essence, it is impossible, as far as I know (patches welcome) to
> avoid a race when symlinks are involved (with specific exceptions). The
> assumption is, and has always been, that the directory resides inside a
> locatio
On 03/01/11 14:10, Adam Borowski wrote:
There's a race condition:
while [ 1 ]; do ln -s /etc/passwd somefile.tmp; done
"Hey root, could you please use this program using libsafewrite on
'somefile'?"
Two questions:
1. Is this race a regression from the single file case?
2. Is this race a
On 03/01/11 14:10, Adam Borowski wrote:
There's a race condition:
while [ 1 ]; do ln -s /etc/passwd somefile.tmp; done
"Hey root, could you please use this program using libsafewrite on
'somefile'?"
Two questions:
1. Is this race a regression from the single file case?
2. Is this race avoi
On Mon, Jan 03, 2011 at 12:43:24PM +0200, Shachar Shemesh wrote:
> Hi all,
>
> I've promised to get a library out there, and here it is. The base
> URL is https://github.com/Shachar/safewrite, and the actual code is
> at https://github.com/Shachar/safewrite/blob/master/safewrite.c
[...]
> Give my
Hi all,
I've promised to get a library out there, and here it is. The base URL
is https://github.com/Shachar/safewrite, and the actual code is at
https://github.com/Shachar/safewrite/blob/master/safewrite.c
This is not a formal release just yet (plus one function is still
missing an implemen
32 matches
Mail list logo
