On Sun, Mar 17, 2019 at 11:36 AM ronnie sahlberg <ronniesahlberg@xxxxxxxxx> 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@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.
