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