linux-ext4 - Re: Zero length files - an alternative approach?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <yw1x1vsg4jio.fsf@thrashbarg.mansr.com>
Date:	Sun, 29 Mar 2009 13:10:23 +0100
From:	Måns Rullgård <mans@...sr.com>
To:	"Andreas T.Auer" <andreas.t.auer_lkml_73537@...us.ath.cx>
Cc:	linux-kernel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: Zero length files - an alternative approach?

"Andreas T.Auer" <andreas.t.auer_lkml_73537@...us.ath.cx> writes:

> On 29.03.2009 13:22 Måns Rullgård wrote:
>> Consider this scenario:
>>
>> 1. Create/write/close newfile
>> 2. Rename newfile to oldfile
>> 3. Open/read oldfile.  This must return the new contents.
>> 4. System crash and reboot before delayed allocation/flush complete
>> 5. Open/read oldfile.  Old contents now returned.
>>
>> This rollback isn't obviously, to me at least, without problems of its
>> own.
>>   
> Having the old data in 5) is far better than having no data in 5).

Of course having old data is better than no data.  However, fsync()
and similar approaches make a rollback to old data after new data has
been visible impossible or far less likely than the suggested one.
I'm not saying it's necessarily a problem, only that it is a
difference that should be taken into account.

-- 
Måns Rullgård
mans@...sr.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html