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