Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add SetExtendedAttrs to Client #583

Merged
merged 2 commits into from
Apr 26, 2024

Conversation

peterverraedt
Copy link
Contributor

Add function to set extended attributes in the sftp client.

Copy link
Collaborator

@puellanivis puellanivis left a comment

Choose a reason for hiding this comment

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

I suppose if we’re adding this to *Client we should could add a parallel *File implementation using the fsetstat as well.

client.go Show resolved Hide resolved
client.go Outdated
@@ -593,6 +593,16 @@ func (c *Client) Truncate(path string, size int64) error {
return c.setstat(path, sshFileXferAttrSize, uint64(size))
}

// SetExtendedAttrs sets the extended attributes of the named file.
func (c *Client) SetExtendedAttrs(path string, extended []StatExtended) error {
Copy link
Collaborator

Choose a reason for hiding this comment

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

It seems like the common abbreviation for “extended attributes” is xattr So, that would suggest SetXattr, which would match the setxattr call in OpenSSH. But I don’t think we want our name that short. SetExtAttrs() might be a good inbetween? But I’m still fine with this longer name as well.

Maybe we could also implement this as SetExtAttrs(path string, xattrs ...StatExtended) error … though checking it on go playground, it seems this doesn’t allow for the type-elided shorthand cl.SetExtAttr(path, { ExtType: "foo", ExtData: "bar" }) to be used. 🙁 Meanwhile, cl.SetExtAttrs(path, []sftp.StatExtended{ { ExtType: "foo", ExtData: "bar" } }) only needs the one sftp.StatExtended type name to be used for any number of xattrs.

A common API design that some have picked is SetExtAttrs(path string, xattrs ...string) and then provide alternating type and data values that get turned into the []sftp.StatExtended internally. But I’m not a big fan of this easy-to-misalign approach. But then again, it is integrated into the standard slog library, so… 🤷‍♀️

In the alternative, we could provide two functions: SetExtAttrs(path string, xattrs []StatExtended) and SetExtAttr(path, typ, data string) thus anyone wanting to set a single attribute can avoid the StatExtended altogether, and then for more than one, they can make use of the []StatExtended{ {}, {} } type elision.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Following the draft RFCs the extended attributes in the SFTP protocol do not necessarily match to extended atributes on the system, so I would avoid the very short xattr to avoid confusion. Maybe SetExtendedData is a better name to correspond with the FileInfoExtendedData interface ?

Another catch is that it is very unspecified what setstat actually does with extended attributes. It might, in case of real extended attributes on files, just replace all current attributes.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added long comment to clarify the possible use cases.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Second checked the standard, and the field is called extended_data, so 👍

Add function to set extended attributes in the sftp client.

Signed-off-by: Peter Verraedt <[email protected]>

Add longer comment

Signed-off-by: Peter Verraedt <[email protected]>
@puellanivis puellanivis merged commit 06342e8 into pkg:master Apr 26, 2024
4 checks passed
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.

2 participants