- 22 Jan, 2020 1 commit
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com> (cherry picked from commit 56b4b776c84f364384971c4cdfd66b4a2f0696d4)
-
- 09 Mar, 2019 8 commits
-
-
J. R. Okajima authored
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Implement i_op->link(). As aufs supports 'pseudo-link', aufs_link() can make it without copying-up. In the case of aufs_link() has to copy-up, the name of the target file is used as-is, and it is pseudo-linked. In other words, calling link(2) after the copy-up is unnecessary. See also struct.txt in previous commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Implement dir.i_op->lookup() and ->permission(). Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
Maintain the internal array including corresponding XINO file and sysfs entries. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
The feature is constructed by two layers. One is generic interface, and the other is exact implementation. This is rather historical. Originally aufs implemented this feature based upon 'inotify.' Later 'fsnotify' made 'inotify' obsolete. During the transition period, these two layers were introduced to support both of 'inotify' and 'fsnotify.' Currently only 'fsnotify' is supported, but the layers are kept for the future use. This feature is compiled only when CONFIG_AUFS_HNOTIFY is enabled. See also the document in previous commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
The branch object is managed by the sbinfo object as an element of its internal array. The iinfo and dinfo objects contain the branch id, and it will be used to implement the correct order in branch management (add/del). See also the documents in this commit. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
The generation of aufs objects will be updated by the branch management (add/del branches, by later commit), and aufs will refresh the objects based upon the generation. In refreshing dinfos, aufs will find all ancestors of the given dentry and store the pointers in dynamically allocated memory. I don't think it beautiful, but I don't have any other idea. Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-
J. R. Okajima authored
The structure is very similar to aufs inode info (in previous commit). Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
-