suffuse / sfs

identity fuse filesystem, toward lowering the fuse/unix/java impedance mismatches
Other
8 stars 1 forks source link

untested version where reads are through new abstraction #23

Closed EECOLOR closed 8 years ago

EECOLOR commented 8 years ago

A major source of errors was a change in how I wrote the Permission container.

Note that I removed the effect from resolve(path: Path): Key. It made the semantics a bit complex if the same effect was used to obtain the Key and data or metadata. For example, at what point do you say: 'this does not exist?'

I first removed the resolve method entirely, but then realized that it's important we keep the act of 'moving into the file system' explicit. I do not yet have a clear vision of where this separation comes in handy, but my gut feeling tells me it's something we need to keep. On top of that, you added it and you have way more experience in this domain.

If we do reintroduce effects for obtaining the key, they should be a separate set of effects.

EECOLOR commented 8 years ago

There is still some errors which I'll try to chase down. I might add the (stripped) test suite I'm using if you feel that's of some worth.

EECOLOR commented 8 years ago

Ok, this branch now behaves the same (as far as I can tell) as master

paulp commented 8 years ago

Adding the test suite you're using would be great.

EECOLOR commented 8 years ago

I'll do that based on master

EECOLOR commented 8 years ago

https://github.com/suffuse/sfs/pull/25 pulls in the test suite

EECOLOR commented 8 years ago

I removed the structural type implicit.

The location of files might need some change. Which reminds me, I think we should have some guidelines of where to place what. I don't have a very strong preference, but I do need some guidelines in order to put things in the right (and consistent) places. It would also help me figure out where to find things.

In any case. When you are at a normal (code friendly) computer again I'd love to hear your feedback.

EECOLOR commented 8 years ago

Slightly related to the discussion on permissions. FuseFs is a consumer filesystem, it consumes (or uses other file systems). It demands filesystems of a certain type. It however can not express what metadata it can consume. Similarly, other filesystems might 'require' certain metadata to be present. I am not sure if the cost of having the ability to preserve types, or state type / attribute requirements, would be too high. But it might be something we need to think about.

paulp commented 8 years ago

There are bits of this I want to change but it's good enough to merge, thanks.