IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We get ENOENT on /proc/self/fd/<fdnum> when we try to turn the
mountpoint's O_PATH handle into a real one. This does not trigger a
mount attempt, you have to use name-based calls.
This is not the real fix, because if the autofs mount triggers, the
inode number will change. For directories this is not a huge problem
as we don't touch the share mode database before we open the "real"
fd. We would only violate potential share modes with other pure
READ_ATTRIBUTES (i.e. stat-) opens that came before the mount
trigger.
As I don't think share modes on directories are really relevant, I
think we can live with this "fix". Once we do directory leases this
will potentially change.
As a quick remedy we could use our defer_open() mechanism that starts
path processing from scratch. But as long as this seems not really
required, we should not add users of this really bad way of going back
to square 1.
The "real" fix would be to go back to the point where we open the last
component with openat(). In the retry round we need to do this without
O_PATH to trigger the mount and only then do the initial fstat.
Right now I don't see an easy way to properly test this
behaviour. Intercepting with vfs_error_inject is certainly possible,
but nailing the exact call would clutter the main code path. So I have
just tested this manually.
Signed-off-by: Volker Lendecke <vl@samba.org>
Reviewed-by: Ralph Boehme <slow@samba.org>
Autobuild-User(master): Ralph Böhme <slow@samba.org>
Autobuild-Date(master): Thu Jun 27 11:59:05 UTC 2024 on atb-devel-224
ac7a16f9cc