-
Notifications
You must be signed in to change notification settings - Fork 380
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
Add SetExtendedAttrs to Client #583
Conversation
There was a problem hiding this 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
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 { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 👍
07fd48c
to
e24bd0a
Compare
Add function to set extended attributes in the sftp client. Signed-off-by: Peter Verraedt <peter@verraedt.be> Add longer comment Signed-off-by: Peter Verraedt <peter@verraedt.be>
e24bd0a
to
0814039
Compare
Signed-off-by: Peter Verraedt <peter@verraedt.be>
Add function to set extended attributes in the sftp client.