Suggestions for POSIX error code mapping for OBJECTID_NOT_FOUND

[Amir Goldstein]

On Sun, Mar 17, 2019 at 10:57 AM ronnie sahlberg via samba-technical
<samba-technical at lists.samba.org> wrote:
>
> ENOENT / ENOTSUPP / EINVAL?
>
> ENOENT feels appropriate since this is not a permanent condition.
> Someone could create the object buffer after which it will exist and
> there will no longer be an errror when asking for it.
>
> I guess for a long time smbinfo.c will be the only consumer for this
> on the non-windows side  so whatever we decide will be what will be
> how things are and others will follow.
>
> On Sun, Mar 17, 2019 at 6:40 PM Steve French <smfrench at gmail.com> wrote:
> >
> > Any thoughts as to the best POSIX error code to map status code
> > "0xC00002F0 STATUS_OBJECTID_NOT_FOUND" to?
> >
> > It means an object ID was not found for the file, which is a
> > reasonably common situation over the network even to Windows servers.
> >
> > I was mapping it to EIO for cases where tools asks for the object id
> > of the file (or volume).
> >

If I am reading NTFS documentation correctly, then Object ID is
a similar beast to NFS file handle you get with name_to_handle_at().
NTFS supports Object IDs since Windows 2000, but an upgrade
doesn't set object ids to existing files - those can be added manually.

In Linux, a file system either supports NFS file handles or it doesn't.
In the first case, ENOTSUPP is returned from name_to_handle_at().
IMO, its a valid case to return ENOTSUPP per file, but if you
consider that NTFS treats Object ID as extra information attached to
the inode, returning ENOATTR (like from getxattr) may be a valid
option for cifs. It really depends on which tools would see this
errors and what errors they would expect.

Thanks,
Amir.