public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Artem Bityutskiy <dedekind1@gmail.com>
To: Ricard Wanderlof <ricard.wanderlof@axis.com>
Cc: Linux mtd <linux-mtd@lists.infradead.org>
Subject: Re: temporary files on mtd file systems
Date: Tue, 20 Aug 2013 16:51:01 +0300	[thread overview]
Message-ID: <1377006661.2089.560.camel@sauron.fi.intel.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1308191539170.3183@lnxricardw.se.axis.com>

On Mon, 2013-08-19 at 15:55 +0200, Ricard Wanderlof wrote:
> Am I missing something here, or is there a "good" way to deal with this? 
> Of course there are several cleanup scenarios that could be imagened, such 
> as cleaning out all 'foo.*' files during boot for instance.
> 
> For applications that are not multi threaded, i.e. there may only be one 
> process updating foo, one way is to use the same temporary file name each 
> time, e.g. foo.temp. But things get awkward when using for instance glib, 
> which has a nice g_file_set_contents() call, complete with temporary file 
> handling and all, but which uses mkstemp as above to create the temporary 
> file, so there is no easy way of telling glib what filename to use, short 
> of rewriting a local function which indeed uses a constant temporary file 
> name.

Good question, the only thing which comes to my mind is that one could
try to use extended attributes or 'standard' (chattr(1)) attributes.

Something like having a special chattr which would indicate that the
file is up-to-date. When you need to update the file atomically, you
start with removing the attribute, syncing the file, then updating the
file, then syncing it, then creating the attribute, and probably syncing
too.

-- 
Best Regards,
Artem Bityutskiy

  reply	other threads:[~2013-08-20 13:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-19 13:55 temporary files on mtd file systems Ricard Wanderlof
2013-08-20 13:51 ` Artem Bityutskiy [this message]
2013-08-20 13:46   ` Bityutskiy, Artem

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1377006661.2089.560.camel@sauron.fi.intel.com \
    --to=dedekind1@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=ricard.wanderlof@axis.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox