Suggestions for POSIX error code mapping for OBJECTID_NOT_FOUND

Suggestions for POSIX error code mapping for OBJECTID_NOT_FOUND

[Steve French]

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).

-- 
Thanks,

Steve

Re: Suggestions for POSIX error code mapping for OBJECTID_NOT_FOUND

[ronnie sahlberg]

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@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).
>
> --
> Thanks,
>
> Steve

Re: 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@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@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.

Re: Suggestions for POSIX error code mapping for OBJECTID_NOT_FOUND

[ronnie sahlberg]

I think they are a little bit different in that NFS handles are only
temporal while these guys are supposed to be immutable forever once
created.

NTFS object ids are supposed to be persistent across infinite time
once they are created.
I.e. once a file has for example a Birth-Object-Id, I think that is
immutable for the lifetime of the fs object.
Not all objects in NTFS automatically get a ObjId assigned as far as
my testing goes
but if it is missing we can just switch to the Create-Or-Get-Object-Id
fcntl call in which case the server will make one up and assign to the
object if there is none yet.

On Sun, Mar 17, 2019 at 7:24 PM Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Sun, Mar 17, 2019 at 10:57 AM ronnie sahlberg via samba-technical
> <samba-technical@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@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.

Re: Suggestions for POSIX error code mapping for OBJECTID_NOT_FOUND

[Amir Goldstein]

On Sun, Mar 17, 2019 at 11:36 AM ronnie sahlberg
<ronniesahlberg@gmail.com> wrote:
>
> I think they are a little bit different in that NFS handles are only
> temporal while these guys are supposed to be immutable forever once
> created.
>

NFS handles are not temporal. On the contrary. They are expected to
persist a server reboot. Most filesystems implement them as a combination
of (at least) inode number and generation number.

> NTFS object ids are supposed to be persistent across infinite time
> once they are created.
> I.e. once a file has for example a Birth-Object-Id, I think that is
> immutable for the lifetime of the fs object.
> Not all objects in NTFS automatically get a ObjId assigned as far as
> my testing goes
> but if it is missing we can just switch to the Create-Or-Get-Object-Id
> fcntl call in which case the server will make one up and assign to the
> object if there is none yet.
>
> On Sun, Mar 17, 2019 at 7:24 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > On Sun, Mar 17, 2019 at 10:57 AM ronnie sahlberg via samba-technical
> > <samba-technical@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@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.

Re: 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@gmail.com> wrote:
>
> On Sun, Mar 17, 2019 at 10:57 AM ronnie sahlberg via samba-technical
> <samba-technical@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@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