From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Kerrisk Subject: Re: [PATCH 3/3] xstat: Implement a requestable extra result to procure some inode flags [ver #4] Date: Sun, 4 Jul 2010 06:29:46 +0200 Message-ID: References: <20100701235727.19035.84584.stgit@warthog.procyon.org.uk> <20100701235738.19035.21536.stgit@warthog.procyon.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: David Howells , linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Andreas Dilger Return-path: In-Reply-To: Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: [CC+=3Dlinux-api] On Fri, Jul 2, 2010 at 7:45 PM, Andreas Dilger wrot= e: > On 2010-07-01, at 17:57, David Howells wrote: >> [This is, for the moment, to be considered an example. =A0Do we actu= ally want to >> export these flags? =A0Should they be a full member of struct xstat?= ] > > I would say this should be a full-fledged member of struct xstat. > I think they are fairly standard (available on many filesystems > today), and requiring an ioctl to access them is unpleasant. > >> (1) User settable flags (to be consistent with the BSD st_flags fiel= d): >> >> =A0 =A0 =A0 UF_NODUMP =A0 =A0 =A0 Do not dump this file. >> =A0 =A0 =A0 UF_IMMUTABLE =A0 =A0This file is immutable. >> =A0 =A0 =A0 UF_APPEND =A0 =A0 =A0 This file is append-only. >> =A0 =A0 =A0 UF_OPAQUE =A0 =A0 =A0 This directory is opaque (unionfs)= =2E >> =A0 =A0 =A0 UF_NOUNLINK =A0 =A0 This file can't be removed or rename= d. >> =A0 =A0 =A0 UF_COMPRESSED =A0 This file is compressed. >> =A0 =A0 =A0 UF_HIDDEN =A0 =A0 =A0 This file shouldn't be displayed i= n a GUI. >> >> =A0 =A0The UF_SETTABLE constant is the union of the above flags. >> >> (2) Superuser settable flags (to be consistent with the BSD st_flags= field): >> >> =A0 =A0 =A0 SF_ARCHIVED =A0 =A0 This file has been archived. >> =A0 =A0 =A0 SF_IMMUTABLE =A0 =A0This file is immutable. >> =A0 =A0 =A0 SF_APPEND =A0 =A0 =A0 This file is append-only. >> =A0 =A0 =A0 SF_NOUNLINK =A0 =A0 This file can't be removed or rename= d. >> =A0 =A0 =A0 SF_HIDDEN =A0 =A0 =A0 This file is a snapshot inode. >> >> =A0 =A0The SF_SETTABLE constant is the union of the above flags. >> >> (3) Linux-specific flags: >> >> =A0 =A0 =A0 XSTAT_LF_MAGIC_FILE =A0 =A0 Magic file, such as found in= procfs and sysfs. >> =A0 =A0 =A0 XSTAT_LF_SYNC =A0 =A0 =A0 =A0 =A0 File is written synchr= onously. >> =A0 =A0 =A0 XSTAT_LF_NOATIME =A0 =A0 =A0 =A0Atime is not updated on = this file. >> =A0 =A0 =A0 XSTAT_LF_JOURNALLED_DATA Data modifications to this file= are journalled. >> =A0 =A0 =A0 XSTAT_LF_ENCRYPTED =A0 =A0 =A0This file is encrypted. >> =A0 =A0 =A0 XSTAT_LF_SYSTEM =A0 =A0 =A0 =A0 This file is a system fi= le (FAT/NTFS/CIFS). >> =A0 =A0 =A0 XSTAT_LF_TEMPORARY =A0 =A0 =A0This file is a temporary f= ile (NTFS/CIFS). >> =A0 =A0 =A0 XSTAT_LF_OFFLINE =A0 =A0 =A0 =A0file is currently unavai= lable (CIFS). > > Yuck on the names. =A0Why not stick with the "UF_" and "SF_" prefixes= ? > Since we don't need to keep _binary_ compatibility with these flag va= lues > (only name portability) we can use the same flag values as the > FS_*_FL definitions in fs.h. =A0That is what all of the existing file= systems > already use (ext2/3/4, ocfs, btrfs, reiserfs, xfs, jfs). Agree on the naming. Andreas expresses what I intended when I proposed = the idea. Cheers, Michael --=20 Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface", http://blog.man7.org/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753133Ab0GDE3w (ORCPT ); Sun, 4 Jul 2010 00:29:52 -0400 Received: from mail-fx0-f46.google.com ([209.85.161.46]:45036 "EHLO mail-fx0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751995Ab0GDE3t convert rfc822-to-8bit (ORCPT ); Sun, 4 Jul 2010 00:29:49 -0400 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=xPcpnwbCIqNxVE9eBfqWhdxuBLucyHwXb7C5RQ4wB81Cy+65+59odP1U0MTDfY7guF O+hVDxFHDzfT0dCOEBhDtq/BgnXFncXl5nIZjax3f57Nz/sOjmvPyVEnx5KdE3DQ1MOx V9qHRc6kCOqUxmC37bPLoMZfjWfNPlDU2WHjQ= MIME-Version: 1.0 In-Reply-To: References: <20100701235727.19035.84584.stgit@warthog.procyon.org.uk> <20100701235738.19035.21536.stgit@warthog.procyon.org.uk> Date: Sun, 4 Jul 2010 06:29:46 +0200 X-Google-Sender-Auth: 9LCiBtTUURiwRAjTkZLbutMOw70 Message-ID: Subject: Re: [PATCH 3/3] xstat: Implement a requestable extra result to procure some inode flags [ver #4] From: Michael Kerrisk To: Andreas Dilger Cc: David Howells , linux-fsdevel@vger.kernel.org, linux-cifs@vger.kernel.org, linux-kernel@vger.kernel.org, samba-technical@lists.samba.org, linux-ext4@vger.kernel.org, linux-api@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org [CC+=linux-api] On Fri, Jul 2, 2010 at 7:45 PM, Andreas Dilger wrote: > On 2010-07-01, at 17:57, David Howells wrote: >> [This is, for the moment, to be considered an example.  Do we actually want to >> export these flags?  Should they be a full member of struct xstat?] > > I would say this should be a full-fledged member of struct xstat. > I think they are fairly standard (available on many filesystems > today), and requiring an ioctl to access them is unpleasant. > >> (1) User settable flags (to be consistent with the BSD st_flags field): >> >>       UF_NODUMP       Do not dump this file. >>       UF_IMMUTABLE    This file is immutable. >>       UF_APPEND       This file is append-only. >>       UF_OPAQUE       This directory is opaque (unionfs). >>       UF_NOUNLINK     This file can't be removed or renamed. >>       UF_COMPRESSED   This file is compressed. >>       UF_HIDDEN       This file shouldn't be displayed in a GUI. >> >>    The UF_SETTABLE constant is the union of the above flags. >> >> (2) Superuser settable flags (to be consistent with the BSD st_flags field): >> >>       SF_ARCHIVED     This file has been archived. >>       SF_IMMUTABLE    This file is immutable. >>       SF_APPEND       This file is append-only. >>       SF_NOUNLINK     This file can't be removed or renamed. >>       SF_HIDDEN       This file is a snapshot inode. >> >>    The SF_SETTABLE constant is the union of the above flags. >> >> (3) Linux-specific flags: >> >>       XSTAT_LF_MAGIC_FILE     Magic file, such as found in procfs and sysfs. >>       XSTAT_LF_SYNC           File is written synchronously. >>       XSTAT_LF_NOATIME        Atime is not updated on this file. >>       XSTAT_LF_JOURNALLED_DATA Data modifications to this file are journalled. >>       XSTAT_LF_ENCRYPTED      This file is encrypted. >>       XSTAT_LF_SYSTEM         This file is a system file (FAT/NTFS/CIFS). >>       XSTAT_LF_TEMPORARY      This file is a temporary file (NTFS/CIFS). >>       XSTAT_LF_OFFLINE        file is currently unavailable (CIFS). > > Yuck on the names.  Why not stick with the "UF_" and "SF_" prefixes? > Since we don't need to keep _binary_ compatibility with these flag values > (only name portability) we can use the same flag values as the > FS_*_FL definitions in fs.h.  That is what all of the existing filesystems > already use (ext2/3/4, ocfs, btrfs, reiserfs, xfs, jfs). Agree on the naming. Andreas expresses what I intended when I proposed the idea. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface", http://blog.man7.org/