Upgraded to U2 Previous Versions now show up but can't copy back

[oumpa31]

I'm using 12.0-U2 and part of a bug fix for this version they fixed the but of the SMB share not showing the snapshots in the previous versions drop down of folders. Now they show up but if I delete something I cant drag the file back into the folder once it has been deleted. I recreated the snapshot process and I have restarted the SMB service.

Does anyone have an idea I can do next to try to get this to work.

 

[anodos]

I'm using 12.0-U2 and part of a bug fix for this version they fixed the but of the SMB share not showing the snapshots in the previous versions drop down of folders. Now they show up but if I delete something I cant drag the file back into the folder once it has been deleted. I recreated the snapshot process and I have restarted the SMB service.

Does anyone have an idea I can do next to try to get this to work.

Yeah, I have a WIP fix for an issue with copying back previous versions of files (scheduled for U3). Feel free to PM me if you want to verify the fix. There's an edge case basically where SMB client can request @GMT-<dir>\<file that does not exist> where the cwd of the smbd process is still in the main share path rather than a .zfs/snapshot path. In this case we need to get a ZFS dataset handle from the non-existent path so that we can enumerate snapshots / find the one matching the @GMT token passed by the client. Basically the fix for U3 is when we fail with ENOENT on path_to_zhandle() libzfs call, we loop on stripping off final components of the path until we get something. Once we have a ZFS dataset handle, we can get the correct snapshot, then rebuild the path relative to the .zfs/snapshot/<offset>.

 

[oumpa31]

Yeah, I have a WIP fix for an issue with copying back previous versions of files (scheduled for U3). Feel free to PM me if you want to verify the fix. There's an edge case basically where SMB client can request @GMT-<dir>\<file that does not exist> where the cwd of the smbd process is still in the main share path rather than a .zfs/snapshot path. In this case we need to get a ZFS dataset handle from the non-existent path so that we can enumerate snapshots / find the one matching the @GMT token passed by the client. Basically the fix for U3 is when we fail with ENOENT on path_to_zhandle() libzfs call, we loop on stripping off final components of the path until we get something. Once we have a ZFS dataset handle, we can get the correct snapshot, then rebuild the path relative to the .zfs/snapshot/<offset>.

Ok ill message you.

 

[oumpa31]

Thanks @anodos my fix was that i had created the share at the Pool level and not as a Dataset level inside the Pool. After changing that it works now.