linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: cmm@us.ibm.com
Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-ext4@vger.kernel.org
Subject: Re: [EXT4 set 2][PATCH 1/5] cleanups: Propagate some i_flags to disk
Date: Tue, 10 Jul 2007 16:30:17 -0700	[thread overview]
Message-ID: <20070710163017.7c8f1043.akpm@linux-foundation.org> (raw)
In-Reply-To: <1183275372.4010.120.camel@localhost.localdomain>

On Sun, 01 Jul 2007 03:36:12 -0400
Mingming Cao <cmm@us.ibm.com> wrote:

> Propagate flags such as S_APPEND, S_IMMUTABLE, etc. from i_flags into
> ext4-specific i_flags. Hence, when someone sets these flags via a different
> interface than ioctl, they are stored correctly.
> 

This changelog is inadequate.  I had to hunt down the equivalent ext3
patch's changelog to understand the reasons for this change.  Please update
this patch's changelog using the below: 

    ext3: copy i_flags to inode flags on write
    
    A patch that stores inode flags such as S_IMMUTABLE, S_APPEND, etc.  from
    i_flags to EXT3_I(inode)->i_flags when inode is written to disk.  The same
    thing is done on GETFLAGS ioctl.
    
    Quota code changes these flags on quota files (to make it harder for
    sysadmin to screw himself) and these changes were not correctly propagated
    into the filesystem (especially, lsattr did not show them and users were
    wondering...).
    
    Propagate flags such as S_APPEND, S_IMMUTABLE, etc.  from i_flags into
    ext3-specific i_flags.  Hence, when someone sets these flags via a
    different interface than ioctl, they are stored correctly.

      reply	other threads:[~2007-07-10 23:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-01  7:36 [EXT4 set 2][PATCH 1/5] cleanups: Propagate some i_flags to disk Mingming Cao
2007-07-10 23:30 ` Andrew Morton [this message]

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=20070710163017.7c8f1043.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=cmm@us.ibm.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).