Lines Matching refs:directory

45 supports marking an empty directory as encrypted.  Then, after
47 symbolic links created in that directory tree are transparently
113 Each encrypted directory tree is protected by a *master key*.  Master
121 To "unlock" an encrypted directory tree, userspace must provide the
123 of which protects any number of directory trees on any number of
137 each regular file, directory, and symbolic link.  This has several
152   reused out of necessity.  With a unique key per directory, IV reuse
153   is limited to within a single directory.
189 directory trees are permitted to use different encryption modes.
224 requirements to retain support for efficient directory lookups and
226 used.  However, each encrypted directory uses a unique key, which
227 limits IV reuse to within a single directory.  Note that IV reuse in
244 directory entries consume slightly more space.  Note that since NUL
249 encrypted in the same way as filenames in directory entries.  Each
260 empty directory or verifies that a directory or regular file already
296   before any files can be created in the encrypted directory.
299 verifies that the file is an empty directory.  If so, the specified
300 encryption policy is assigned to the directory, turning it into an
301 encrypted directory.  After that, and after providing the
304 directory will be encrypted, inheriting the same encryption policy.
305 The filenames in the directory's entries will be encrypted as well.
313 Note that the ext4 filesystem does not allow the root directory to be
327   directory
328 - ``ENOTEMPTY``: the file is unencrypted and is a nonempty directory
337 - ``EPERM``: this directory may not be encrypted, e.g. because it is
338   the root directory of an ext4 filesystem
345 fscrypt_policy`, if any, for a directory or regular file.  See above
410 encrypted directory and no session keyring has been installed, then
411 that directory's key should be placed in that user's user session
438   linked into an encrypted directory; see `Encryption policy
440   encrypted files can be renamed within an encrypted directory, or
441   into an unencrypted directory.
488   will uniquely identify directory entries.
490   The ``.`` and ``..`` directory entries are special.  They are always
508 be created or linked into an encrypted directory, nor can a name in an
509 encrypted directory be the source or target of a rename, nor can an
510 O_TMPFILE temporary file be created in an encrypted directory.  All
520 After an encryption policy has been set on a directory, all regular
521 files, directories, and symbolic links created in that directory
528 encrypted directory tree.  Attempts to link or rename such a file into
529 an encrypted directory will fail with EPERM.  This is also enforced
549 from anything other than an empty directory.)  The struct is defined
590 Modern filesystems accelerate directory lookups by using indexed
591 directories.  An indexed directory is organized as a tree keyed by
594 find the corresponding directory entry, if any.
602 i.e. the bytes actually stored on-disk in the directory entries.  When
617 filesystem-specific hash(es) needed for directory lookups.  This
619 the filename given in ->lookup() back to a particular directory entry