public inbox for linux-fsdevel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alexander Larsson <alexl@redhat.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Theodore Tso <tytso@mit.edu>, Nicol? Chieffo <84yelo3@gmail.com>,
	Jeremy Allison <jra@samba.org>,
	Szabolcs Szakacsits <szaka@ntfs-3g.org>,
	Josef Bacik <jbacik@redhat.com>,
	linux-fsdevel@vger.kernel.org
Subject: Re: interface to ask is a file is hidden
Date: Mon, 13 Oct 2008 10:22:53 +0200	[thread overview]
Message-ID: <1223886173.22225.159.camel@fatty> (raw)
In-Reply-To: <20081010220156.GA25396@infradead.org>

On Fri, 2008-10-10 at 18:01 -0400, Christoph Hellwig wrote:
> On Fri, Oct 10, 2008 at 05:57:22PM -0400, Theodore Tso wrote:
> > The best you might be able to get is an interface that allows an
> > application to get or set the hidden attribute if is supported --- but
> > the application must be willing to accept a permission denied error
> > (some filesystems may only permit people with certain access right or
> > on some ACL to set the attribute), or a "operation not supported"
> > failure, for those filesystems that simply have not concept of "hidden
> > file".
> 
> Yes.  he best thing you could do is to add support for the
> FAT_IOCTL_GET_ATTRIBUTES/FAT_IOCTL_SET_ATTRIBUTES ioctls to other
> windows-heritage filesystems.  Feel free to submit patches.

This is a bad interface for most apps. You need to open each file to get
a fd to pass to ioctl. This is problematic if for instance you don't
have read access to the file. So, you really want a path-based operation
for this. 

Its also very expensive since it causes lots of extra I/O. For instance,
a file manager that wants to hide files with the hidden attribute set
(on filesystems which support this) would have to open all files just so
it could try calling this ioctl. To avoid this you can do some
filesystem matching and hard code the lists of filesystems that supports
this call, but having a clean API would be nicer and more efficient.

Now, you could argue (and unsurpisingly you do) that ext3 & co doesn't
have a hidden attribute, but that doesn't mean I can ignore actual users
who have data on other filesystems and want to integrate nicely with
them. This includes not showing weird system files that are normally
hidden on said filesystems.



  reply	other threads:[~2008-10-13  8:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-10 19:22 interface to ask is a file is hidden Nicolò Chieffo
2008-10-10 19:21 ` Josef Bacik
2008-10-10 19:35   ` Jeremy Allison
2008-10-10 20:00     ` Nicolò Chieffo
2008-10-10 19:57       ` Josef Bacik
2008-10-10 20:11         ` Nicolò Chieffo
2008-10-10 21:57       ` Theodore Tso
2008-10-10 22:01         ` Christoph Hellwig
2008-10-13  8:22           ` Alexander Larsson [this message]
2008-10-13  9:21             ` Nicolò Chieffo
2008-10-13  9:57             ` Christoph Hellwig
2008-10-13 10:37               ` Nicolò Chieffo
2008-10-13 10:37               ` Alexander Larsson
2008-10-13 10:43                 ` Christoph Hellwig
2008-10-13 11:39                   ` Alexander Larsson
2008-10-13 20:44                     ` Jörn Engel
2008-10-13 20:50                       ` Christoph Hellwig
2008-10-14  7:20                       ` Alexander Larsson
2008-10-10 22:18         ` Szabolcs Szakacsits
2008-10-10 22:21         ` Nicolò Chieffo
2008-10-10 22:25           ` Christoph Hellwig
2008-10-10 22:33             ` Nicolò Chieffo
2008-10-10 22:36               ` Christoph Hellwig
2008-10-10 22:58                 ` Nicolò Chieffo
2008-10-10 23:12                   ` Szabolcs Szakacsits
2008-10-11  0:10                 ` Bryan Henderson
2008-10-11  1:36               ` Theodore Tso
2008-10-10 22:57         ` Brad Boyer
2008-10-13  7:29         ` Anton Altaparmakov
2008-10-13 10:47           ` Christoph Hellwig
2008-10-13 10:59           ` Alexander Larsson

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=1223886173.22225.159.camel@fatty \
    --to=alexl@redhat.com \
    --cc=84yelo3@gmail.com \
    --cc=hch@infradead.org \
    --cc=jbacik@redhat.com \
    --cc=jra@samba.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=szaka@ntfs-3g.org \
    --cc=tytso@mit.edu \
    /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