Re: Suggestions for POSIX error code mapping for OBJECTID_NOT_FOUND

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux