Suggestions for POSIX error code mapping for OBJECTID_NOT_FOUND

[Steve French]

I like the idea of ENOATTR as Amir suggested as in some sense it is
just extra metadata that this particular object doesn't have

On Sun, Mar 17, 2019 at 4:24 AM Amir Goldstein <amir73il at gmail.com> wrote:
>
> 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.



-- 
Thanks,

Steve