this is the first video I watch from your channel, pretty neat, I will subscribe. as possible improvements, I'd like that a "ls" would force a re-read of the disk contents. not sure if that's possible under fuse, but it should be, it's like reading a network share that you can't cache. also, I don't mind the block size of each file being displayed instead of the actual size, but it might confuse some apps, isn't it? it could be an argument passed to the daemon for it to read the actual size of each file instead of assuming its max size. also, the dummy files that are only useful for interacting with the daemon could start with a dot, and/or, placed inside a directory (that could also start with a dot). just small things I was thinking while watching!
Thanks for the comment. - You don't actually get notified in your filesystem that an ls has taken place - but it may be possible to infer it from the calls you do get (lots of getattr calls from memory). However, there are _so many_ getattr calls you want to be careful to not constantly hit the disk. - Exposing a "made up" size for the file size could confuse other aps, but they have to be able to cope with the file changing size between an ls and a read anyway (as someone else could have modified it in the meantime). I deliberately went with a size that was too large so fuse would give me an oversized not undersized buffer. But I think fuse will just come back with another buffer if you fill what it gives you. Agree it could be an option to read the actual size of each file but that might take a while - not sure if you have to read the whole file in, or there's some shortcut. - good ideas from the dummy files What this space for updates!
this is the first video I watch from your channel, pretty neat, I will subscribe. as possible improvements, I'd like that a "ls" would force a re-read of the disk contents. not sure if that's possible under fuse, but it should be, it's like reading a network share that you can't cache. also, I don't mind the block size of each file being displayed instead of the actual size, but it might confuse some apps, isn't it? it could be an argument passed to the daemon for it to read the actual size of each file instead of assuming its max size. also, the dummy files that are only useful for interacting with the daemon could start with a dot, and/or, placed inside a directory (that could also start with a dot). just small things I was thinking while watching!
Thanks for the comment.
- You don't actually get notified in your filesystem that an ls has taken place - but it may be possible to infer it from the calls you do get (lots of getattr calls from memory). However, there are _so many_ getattr calls you want to be careful to not constantly hit the disk.
- Exposing a "made up" size for the file size could confuse other aps, but they have to be able to cope with the file changing size between an ls and a read anyway (as someone else could have modified it in the meantime). I deliberately went with a size that was too large so fuse would give me an oversized not undersized buffer. But I think fuse will just come back with another buffer if you fill what it gives you. Agree it could be an option to read the actual size of each file but that might take a while - not sure if you have to read the whole file in, or there's some shortcut.
- good ideas from the dummy files
What this space for updates!