From: Nikolaus R. <Nik...@ra...> - 2016-06-28 16:36:14
|
On Jun 28 2016, Jose Lopes <jab...@pu...> wrote: > On Tue, Jun 28, 2016 at 5:23 PM Nikolaus Rath <Nik...@pu...> wrote: > >> On Jun 28 2016, Jose Lopes < >> jab...@pu...> wrote: >> > Hi, >> > >> > I would like to continue the discussion on #58 as suggested by Nikratio. >> > >> > At Google, we would like to receive the file handle, specified in >> > open, in the calls to chown, chgrp, utimensat, etc. >> > >> > In order to preserve backwards compatibility, there could be new >> > handlers, such as, fchown, fchgrp, futimensat, or alternatively, a >> > fsetattr handler, which by default forward the calls to the existing >> > handlers, but if given they would allow clients to get the >> > fuse_file_info in addition to the parameters that chown, chgrp, etc, >> > already receive. >> > >> > What do you think? >> >> As I said in the bugtracker, if your file system is primarily >> inode-based, why don't you use the low-level interface? > > I didn't know about the low-level interface until you mentioned it. In any > case, it would require a major rewrite > of our system. Are you sure? The API's aren't all that different (as long as you already use inodes where possible). > On the other hand, the change to pass the fuse_file_info does not seem > difficult because FUSE already has this data structure internally, it > is simply not passing it to the user code. This change would also make > the interface more consistent, namely, it goes in the direction of the > the handler pairs getattr/fgetattr and truncate/ftruncate. Yes, that is a good point. I forgot about those existing pairs. We could introduce them in FUSE 3, since we're breaking backwards compatibility anyway... would that help you? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« |