All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Tso <tytso@mit.edu>
To: "Nicolò Chieffo" <84yelo3@gmail.com>
Cc: Jeremy Allison <jra@samba.org>,
	Alexander Larsson <alexl@redhat.com>,
	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: Fri, 10 Oct 2008 17:57:22 -0400	[thread overview]
Message-ID: <20081010215722.GG8645@mit.edu> (raw)
In-Reply-To: <641322f90810101300v3ab5fc15hb20fca0374ebe4b4@mail.gmail.com>

On Fri, Oct 10, 2008 at 10:00:28PM +0200, Nicolò Chieffo wrote:
> On Fri, Oct 10, 2008 at 03:21:04PM -0400, Josef Bacik wrote:
> 
> > What files are determined as "hidden" is completely up to the application, and
> > not the filesystem.  Every linux filesystem is going to return all entries in a
> > directory when you do a readdir, and then it is up to the app to cull which
> > entries it doesn't want.  Having the fs/vfs arbitrarily decide which files are
> > "hidden" and shouldn't be returned via readdir is not the correct way to tackle
> > this problem, it should be decided via the application.
> 
> Ok, maybe I was not clear in my request
> 
> As if it's a way to get the size of a file, and this way is common to
> all filesystem (tell me if I'm wrong), we request a common way to ask
> if the file is hidden.

You realie that except for filesystems that are legacy compatible with
Microsoft, the concept of "hidden file" simply doesn't exist?  So when
you say:

> So that the GIO code won't look like this
> 
> if (filesystem_is_ext3(fs))
>     hidden=ext3_get_hidden(file);

Ext3 has no concept of "hidden file".  Niether does ext2, ext4, jfs,
xfs, reseirfs, ufs, etc.

The only ones that would have that concept is vfat (which supports
fat16/fat32), ntfs, nfsv4 and cifs/smbfs.  Even a filesystem which
normally has very bad taste, MacOS's HFS, doesn't support the hidden
attribute.

> If there is a common interface to do this we will gain 2 things
> 1) all filesystem must implement a way to get the hidden attribute

"Must?"  Bzzzt!  There will be many filesystems that have no place to
store a hidden attribute, where the concept doesn't exist.  For
example, NFSv3 simply doesn't possess anything vaguely like a hidden
attribute.  And even if we made a non-standard extension to NFSv3, it
wouldn't be supported by the millions and millions of non-Linux NFSv3
implementations.

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".

It also means that if a desktop toolkit wants to depend on all
filesystems supporting the concept of hidden files, that's probably a
really bad idea, since it simply doesn't match with reality.

       	   	       	  	 	       - Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2008-10-10 21:57 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 [this message]
2008-10-10 22:01         ` Christoph Hellwig
2008-10-13  8:22           ` Alexander Larsson
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=20081010215722.GG8645@mit.edu \
    --to=tytso@mit.edu \
    --cc=84yelo3@gmail.com \
    --cc=alexl@redhat.com \
    --cc=jbacik@redhat.com \
    --cc=jra@samba.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=szaka@ntfs-3g.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.