No clear way to use HandleID from Getattrer or Setattrer #225
Comments
Getattr and Setattr requests can either happen on a fs.Node or an fs.Handle (depending on the call that initiated it e.g. truncate vs ftruncate or stat vs fstat). Add HandleGetattrer and HandleSetattrer so implementations can provide handle-specific overrides when those operations are performed on an open file descriptor. Also create HandleFsyncer and deprecate NodeFsyncer to resolve the TODO. Resolves bazil#225.
Getattr and Setattr requests can either happen on a fs.Node or an fs.Handle (depending on the call that initiated it e.g. truncate vs ftruncate or stat vs fstat). Add HandleGetattrer and HandleSetattrer so implementations can provide handle-specific overrides when those operations are performed on an open file descriptor. Also create HandleFsyncer and deprecate NodeFsyncer to resolve the TODO. Resolves bazil#225.
|
Out of curiosity, how do you plan on using handle-specific attributes or fsync? All handles to a single node are supposed to view the same data, and as far as I know there's plenty of assumptions about that in the kernel (page cache). If you want per-open content for a file, you're probably better off with uncacheable Lookup responses and giving each Lookup a new Node. |
|
I'm trying to model things behind an API as files that you can read and update. I was hoping that the way most editors worked when overwriting a file would be Unfortunately it seems that when they truncate (or maybe when you open with the truncate flag) it's |
|
bolt-mount is a filesystem interface to a transactional key-value database that stores file contents to the key-value store on Flush, which is the kernel operation triggered by fsync or final close of the file. That might give you some ideas: https://github.com/bazil/bolt-mount/blob/master/file.go |
|
I think the changes I made in the PR still make sense theoretically, but I think the way bolt-mount approaches it will probably solve the particular problems I was dealing with. Thanks. |
|
That example helped a bit. I guess you almost never get Setattr called without an open write handle? Also, I get problems with vim if I don't define Fsync (it gets the |
That'd happen with truncate syscall, chmod, etc.
I think returning an error to the caller (vim) is a lot better than lying about persistence guarantees. If your filesystem doesn't implement Fsync, we don't let callers think you do. Though reading fsync(2) it might make more sense to return EINVAL than EIO. I opened #227 for that. |
|
My point about truncate was that https://github.com/bazil/bolt-mount/blob/master/file.go doesn't seem to implement a way to handle that outside of a writable handle getting flushed. I guess it's up to my filesystem whether it wants to support raw truncate operations in that scenario. P.S. Thanks for all the feedback. |
|
Based on my reading of bolt-mount it explicitly doesn't care whether incoming requests have a handle or not -- though that code is probably buggy if there are no writers concurrently open (f.data will be nil, changes to it will not be respected, nothing is persisted). |
Most methods that are performed on a file handle resolve to functions implementing Handle* interfaces. NodeGetattrer and NodeSetattrer can be called with or without a handle (for example, from
ftruncatevstruncateorfstatvsstatcalls). However, there's no way to resolve theHandleIDprovided inGetattrRequestorSetattrRequestto aHandleso you can pass handling of those requests to the specific open handle.I'd like to see
HandleGetattrerandHandleSetattrerinterfaces that are called when those requests are performed on an open handle. It makes sense to fall back toNodeGetattrerandNodeSetattrerif not implemented.NodeFsyncerhas a similar problem, since it's called on the node rather than a particular handle.The text was updated successfully, but these errors were encountered: