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@xxxxxxxxx> wrote: > > 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. -- Thanks, Steve
