lkml.org 
[lkml]   [2010]   [Apr]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 13/35] fallthru: ext2 fallthru support
    Jan Blunck wrote:
    > On Tue, Apr 20, Jamie Lokier wrote:
    >
    > > Miklos Szeredi wrote:
    > > > On Mon, 19 Apr 2010, Valerie Aurora wrote:
    > > > > I don't recall there being any technical reason not to look up the
    > > > > real inode number. I just wrote it that we because I was lazy. So I
    > > > > like returning the directory's d_ino better than a single magic
    > > > > number, but I'd at least like to try returning the real inode number
    > > > > too.
    > > >
    > > > Note, "struct dirent" doesn't have d_dev, so you really can't return
    > > > the "real" inode number, that's on a different filesystem and just a
    > > > random number in the context of the the readdir in question.
    > >
    > > Agree. Does this inappropriate inode number for the union mount's
    > > st_dev happen with stat() on the actual files too? That could be bad.
    >
    > No, for stat() you do a lookup and that is returning the correct
    > dentry/inode for the filesystem the name is on.

    Hmm. I smell potential confusion for some otherwise POSIX-friendly
    userspaces.

    When I open /path/to/foo, call fstat (st_dev=2, st_ino=5678), and then
    keep the file open, then later do a readdir which includes foo
    (dir.st_dev=1, d_ino=1234), I'm going to immediately assume a rename
    or unlink happened, close the file, abort streaming from it, refresh
    the GUI windows, refresh application caches for that name entry, etc.

    Because in the POSIX world I think open files have stable inode
    numbers (as long as they are open), and I don't think that an open
    file can have it's name's d_ino not match the inode number unless it's
    a mount point, which my program would know about.

    This plays into inotify, where you have to know if you are monitoring
    every directory that contains a link to a file, to know if you need to
    monitor the file itself directly instead.

    Now I think it's fair enough that a union mount doesn't play all the
    traditional rules :-) C'est la vie.

    This mismatch of (dir.st_dev,d_ino) and st_ino strongly resembles a
    file-bind-mount. Like bind mounts, it's quite annoying for programs
    that like to assume they've seen all of a file's links when they've
    seen i_nlink of them.

    Bind mounts can be detected by looking in /proc/mounts. st_dev
    changing doesn't work because it can be a binding of the same
    filesystem.

    How would I go about detecting when a union mount's directory entry
    has similar behaviour, without calling stat() on each entry? Is it
    just a matter of recognising a particular filesystem name in
    /proc/mounts, or something more?

    Thanks,
    -- Jamie


    \
     
     \ /
      Last update: 2010-04-21 11:25    [W:4.367 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site