Skip to content

Conversation

@lundman
Copy link
Collaborator

@lundman lundman commented Aug 26, 2019

In an attempt to be compatible with existing reparse points (EA stored) - for example samba implementation.

I believe this is not complete, but a starting point - there are also some cross over with master.


static ULONG zp_get_reparse_tag(znode_t *zp);
// There are multiple struct types with "stat" style members.
// There are multiple sturct types with "stat" style members.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a typo, right? :D "sturct"

@DHowett
Copy link
Contributor

DHowett commented Aug 26, 2019

@lundman I added you as a collaborator on my fork so you can push changes required for this PR. Thanks again.

@DHowett
Copy link
Contributor

DHowett commented Aug 26, 2019

There was also a bit more work here: https://github.com/DHowett/ZFSin/commits/rp_synth2

  • Synthesizing reparse points based on the on-pool metadata (block device, char device, fifo -> LX reparse points, symbolic links -> windows symbolic links, etc.)
  • A further fix for WSL device nodes imported from other systems

@lundman
Copy link
Collaborator Author

lundman commented Aug 27, 2019

Quite interesting - even knowing the names like FsRtlGetNextExtraCreateParameter() it is hard to find much information at all, and nothing at all for something like GUID_ECP_CREATE_REDIRECT. Sure it has a struct with it, but not much information as to when it should be triggered etc.

GUID_ECP_QUERY_ON_CREATE Is interesting as well, since master had different file_stat_information() to yours, it looks a bit different.

Is it acceptable then to store the reparse points in symlink data (readlink() etc)? I was under the impression that samba stores it in an EA - although I have been unable to get samba to create me a symlink on a test pool.

I'll create a parallel PR to this, as your code gets merged into master - probably the easiest way for us to keep an eye on code changes.

@lundman
Copy link
Collaborator Author

lundman commented Aug 27, 2019

I'm getting increasingly more unhappy with zfs_vnop_lookup() - it has become large and unwieldy, and sensitive to change. I've been hesitate to touch it, since it would break for a bit, but I think I might have to just do it.

At the very least, wrap it in one more function, so we don't have to repeat the cleanup code so many times. It seems clear that QOC should be done for file and dirs, for existing and creating, so adding 4 copies of the same code is dumb.

Anyway, head's up I'm about to break it :)

@lundman
Copy link
Collaborator Author

lundman commented Aug 27, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants