FreeBSD .zfs fixups

[mjguzik]

please add to the release if there is time, not a big deal if there is not

fixes find /.zfs:

# find /.zfs
/.zfs
/.zfs/snapshot
find: /.zfs: Invalid argument

[mjguzik]

@amotin

[amotin]

I may be wrong, but as I see it, zfsctl_root_readdir() should normally handle short reads or reads at non-zero offset, so I am not sure the FIXME comment is correct.
I have no objections about the added condition, but wonder if it could be done less explicitly. It feels like a workaround to me.

[KungFuJesus]

Correct me if I'm wrong here but, wouldn't this lead to undesired traversal into your snapshots when running commands such as find or updatedb?

[amotin]

Correct me if I'm wrong here but, wouldn't this lead to undesired traversal into your snapshots when running commands such as find or updatedb?

Are you saying the bug is intentional? I doubt. It would be a pretty weird way. Plus usually .zfs directory is hidden, so no tools should see it to traverse unless pointed explicitly.

[mjguzik]

I am saying that the routine as implemented right now only supports dumping out the 3 entries every time which fails for buffers which can only hold fewer entries (not fixed) and fails for the idiomatic call to validate there are no trailing entries (fixed). Normally callers do have sufficient space so only the latter demands fixing right now.

[amotin]

To me it looks like ENAMETOOLONG checks should handle short buffers. And offset checks should handle reading at different offsets.

[mjguzik]

they should but they don't, instead this bit:

      if (zfs_uio_offset(&uio) != dots_offset)
               return (SET_ERROR(EINVAL));

results in EINVAL in the idiomatic use.

If you are volunteering to make the routine fully api-compliant, have fun.

[KungFuJesus]

Correct me if I'm wrong here but, wouldn't this lead to undesired traversal into your snapshots when running commands such as find or updatedb?

Are you saying the bug is intentional? I doubt. It would be a pretty weird way. Plus usually .zfs directory is hidden, so no tools should see it to traverse unless pointed explicitly.

Ah, forgive my ignorance with hidden file semantics. I do recall some mechanism in place that prevents things from crawling these directories, maybe it was the on demand mounting mechanism?

[mjguzik]

Correct me if I'm wrong here but, wouldn't this lead to undesired traversal into your snapshots when running commands such as find or updatedb?

Are you saying the bug is intentional? I doubt. It would be a pretty weird way. Plus usually .zfs directory is hidden, so no tools should see it to traverse unless pointed explicitly.

Ah, forgive my ignorance with hidden file semantics. I do recall some mechanism in place that prevents things from crawling these directories, maybe it was the on demand mounting mechanism?

.zfs does not show up in directory listings, but it can be accessed if explicitly referred to. there is no magic here.

[behlendorf]

I've gone ahead and merged these changes. If a better solution is implemented we can update to that.

[amotin]

@mjguzik @behlendorf This broke checkstyle.

[behlendorf]

Ugh, so it did. Let me open a PR to quickly fix that.