Lines Matching full:would

66 idmapping would map ``u1000`` down to ``k21000``. The third idmapping would map
75 we would fail to translate as the sets aren't order isomorphic over the full
143 how userspace would specify them.
182   simply the identity idmapping. This would mean id ``u1000`` read from disk
183   would be mapped to id ``k1000``. So an inode's ``i_uid`` and ``i_gid`` field
184   would contain ``k1000``.
187   then ``u1000`` read from disk would be mapped to ``k11000``. So an inode's
188   ``i_uid`` and ``i_gid`` would contain ``k11000``.
241 according to the filesystem's idmapping as this would give the wrong owner if
246 ``u3000:k20000:r10000`` then ``k21000`` would map back up to ``u4000``.
247 Consequently the user would see that this file is owned by ``u4000``.
278 This allows us to answer the question what kernel id we would need to use to
326 conflated. So the two examples above would cause a compilation failure.
538 Note how in the last two examples things would be simple if the caller would be
540 idmapping it would be trivial. So we only consider a filesystem with an
585 This would still leave ``dir`` rather useless to the second container. In fact,
586 ``dir`` and all files below it would continue to appear owned by the overflowid
600 directory case this change in ownership would even need to happen every time the
605 inside user namespaces. But this would also change ownership globally and the
609 impossible because it would mean that all users currently accessing the
743 would usually simply use the crossmapping algorithm and map the filesystem's
768 kernel would now apply the crossmapping, verifying that ``k11000`` can be
969 depending on what ownership they would prefer to end up on the portable storage