rsync icon indicating copy to clipboard operation
rsync copied to clipboard

Use fs.FS for filesystem access

Open joonas-fi opened this issue 2 years ago • 2 comments

Go's new FS interface is pretty cool, I've used in quite a few projects to serve files embedded into the binary, to do overlayFS-like stuff (merge multiple directories as one) etc. fs.FS enables all of this craziness.

My proposal: instead of giving direct filesystem path like /my/path to a module, the module would take in fs.FS and you could give in os.DirFS("/my/path").

I am willing to send a PR if you are interested. I have not read through the server code to check if there are any requirements that don't have direct analogies in fs interfaces. uid/gid things in Stat() calls would be one thing not present in fs.FileInfo. Those cases would need to be type-switched on (check if stat result is a structure that actually carries uid/gid)

joonas-fi avatar Sep 03 '21 10:09 joonas-fi

Yeah, I think we should do this. Probably better to wait until next week, because I’m planning to do some work around extendend attributes and such. I assume that afterwards, I’ll have a much better idea of how much is covered by fs.FS, or what extra things we need :)

stapelberg avatar Sep 03 '21 10:09 stapelberg

Okay, I think the file handling bits are done (or done enough) now: https://github.com/gokrazy/rsync/blob/4c2c525f315f4e6e38a94f45c3a95202f0ec1394/internal/rsyncd/rsyncd.go#L64

Aside from file paths and stat(2) results, we also need symlink target resolution.

Use-case wise, aside from serving static assets and serving the file system, it would be interesting to sketch whether to-be-served data can be generated on the fly, too, with the fs.FS interface.

stapelberg avatar Sep 04 '21 15:09 stapelberg