From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Suvayu Ali Newsgroups: gmane.emacs.help Subject: Re: From Gnus to mu4e Date: Fri, 28 Aug 2015 11:06:19 +0200 Message-ID: <20150828090619.GH30233@chitra.no-ip.org> References: <87d1yhpsbr.fsf@free.fr> <87lhczyl1p.fsf@free.fr> <87a8tezf7x.fsf@free.fr> <87vbc0pgkp.fsf@free.fr> <20150827233408.GD30233@chitra.no-ip.org> <20150827234228.11079.2CAD2C13@ahiker.mooo.com> <20150828001444.GF30233@chitra.no-ip.org> <20150828001629.11433.17209627@ahiker.mooo.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1440752808 15123 80.91.229.3 (28 Aug 2015 09:06:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Aug 2015 09:06:48 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Aug 28 11:06:43 2015 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZVFcP-0003fz-Bz for geh-help-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 11:06:41 +0200 Original-Received: from localhost ([::1]:46865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVFcO-0004Ry-Hr for geh-help-gnu-emacs@m.gmane.org; Fri, 28 Aug 2015 05:06:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42134) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVFcB-0004Rm-Nn for help-gnu-emacs@gnu.org; Fri, 28 Aug 2015 05:06:29 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVFc7-0007xq-JU for help-gnu-emacs@gnu.org; Fri, 28 Aug 2015 05:06:27 -0400 Original-Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:38567) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVFc7-0007x9-D4 for help-gnu-emacs@gnu.org; Fri, 28 Aug 2015 05:06:23 -0400 Original-Received: by wibgu7 with SMTP id gu7so3084398wib.1 for ; Fri, 28 Aug 2015 02:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=YrRYFzVW8ELeho6uRVLq2o3yuGnm4+9zyDrDQhu777g=; b=FuTceEs6/UhWDkepiEjzHtVObhDWWqfEeAT2xheXyxS+W3fGZm4x9dnIPbEmQeunGy SQMliiya181ifft6DKxcX98+/PUHXD++HlesmWg0SsON9EkWLSaiar9z6shJ0vjb3b6+ +pRDRwCMpGOBrcYBIiI4k4OrN4SZClk0RQNUyHHlbvjtWIeNCbf7tpsj68wuxw+76iq6 HJH78zJWU0r7/hdxrKupbhs6YyFHiymQKCU+m2xsY+iTkG3hQghQ+ZVJL4PiSgKybXZv KzpBdcBzIIF6UJw/Y0rUBGIxwmmmvha/1putt1FgFHJ/pabs/in3K/3+hagCRWv3/Bpt eRNw== X-Received: by 10.194.10.165 with SMTP id j5mr10612420wjb.147.1440752782295; Fri, 28 Aug 2015 02:06:22 -0700 (PDT) Original-Received: from chitra.no-ip.org (5072840E.static.ziggozakelijk.nl. [80.114.132.14]) by smtp.gmail.com with ESMTPSA id lk16sm2782248wic.6.2015.08.28.02.06.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Aug 2015 02:06:21 -0700 (PDT) Mail-Followup-To: help-gnu-emacs@gnu.org Content-Disposition: inline In-Reply-To: <20150828001629.11433.17209627@ahiker.mooo.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::230 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:106889 Archived-At: On Thu, Aug 27, 2015 at 05:24:33PM -0700, Ian Zimmerman wrote: > On 2015-08-28 02:14 +0200, Suvayu Ali wrote: > > > No, it's not. AFAIK on most (all?) *nix filesystems, basic operations > > are atomic. See for example this (outdated) list: > > > > http://rcrowley.org/2010/01/06/things-unix-can-do-atomically.html > > > > E.g., this breaks down when you talk about network mounts like NFS (not > > sure about SSHFS), but it is a valid assumption as long as your storage > > is local. > > Assume there's a message ~/Mail/inbox/cur/1440718280.10956_2.ahiker:2,S > > MUA 1 wants to set the "tagged" flag, which means renaming > > 1440718280.10956_2.ahiker:2,S -> 1440718280.10956_2.ahiker:2,FS > > MUA 2 wants to set the "replied" flag, which means renaming > > 1440718280.10956_2.ahiker:2,S -> 1440718280.10956_2.ahiker:2,RS > > Only one of them can succeed, depending on the order they try. And > final state also depends on that order. I think you are confusing failures on the MUA side with race conditions leading to email corruption. Take your example above, when MUA 1 flags a message, and succeeds, atomicity of filesystem operation ensures setting the reply flag by MUA 2 will fail. It is up to MUA 2 to handle this failure. The maildir is guaranteed to be in a consistent state by the atomicity of filesystem operations. When MUA 2 fails, it is easily handled by reporting to the user and not trying to commit the changes again. E.g. in mutt, this is handled by telling the user something like: file does not exist (I don't recall the exact phrasing), and keeping the folder state as is. The user now has to do two things, mark the folder read-only (so mutt stops trying to write state changes back to the maildir), and reread the present maildir. During all this, your maildir has _not_ been corrupted in any way, and both MUAs are reporting things correctly. It is an entirely different story however if your maildir is over NFS (and possibly SSHFS, actually maybe this is true for any network based filesystem). In that case, say the MUAs are accessing the maildir from different locations. MUA 1 writes the "flagging" action, the NFS client commits the change. However the real files on disk have not been changed, and when MUA 2 tries to write its "replying" action, it succeeds! Now you have a race condition, MUA 1 thinks the message is flagged, MUA 2 thinks it's read. And no one knows what it is in reality other than the NFS daemon. Technically the email is not corrupted, only the meta information about the flag is. This is easily recoverable by quiting both MUAs. And essentially this is the beauty of the maildir format, data integrity. Hopefully I have explained myself clearly enough. Or maybe you were trying to say something else? In that case please feel free to stop me. Cheers, -- Suvayu Open source is the future. It sets us free.