c4milo / fusejs

Low level fuse bindings for nodejs
http://c4milo.github.io/fusejs
112 stars 72 forks source link

New test cases and fix for char pointers #32

Closed EricTheMagician closed 8 years ago

EricTheMagician commented 8 years ago

Fixed the loopback such that it gives expected behaviour when scanning the files. Added test case to compare the file attributes between the loopback filesystem and the underlying filesystem.

Fix outstanding bug with char pointers.

http://fuse.sourceforge.net/doxygen/structfuse__lowlevel__ops.html
Other pointer arguments (name, fuse_file_info, etc) are not valid after the call has returned, so if they are needed later, their contents have to be copied.```
EricTheMagician commented 8 years ago

This will get a version bump after the tests passes.

c4milo commented 8 years ago

I see you are duplicating some strings but I don't see where you are releasing that memory.

EricTheMagician commented 8 years ago

I duplicate the strings in the method call (e.g. Filesystem::Lookyp) and I free them in the remote method call (e.g. Filesystem::RemoteLookup).

Arguably, I could have free'd it in the DispatchOp and it would be cleaner that way, and I might refactor it in to that.

On Sat, Nov 14, 2015, 3:31 PM Camilo Aguilar notifications@github.com wrote:

I see you are duplicating some strings but I don't see where you are releasing that memory.

— Reply to this email directly or view it on GitHub https://github.com/c4milo/fusejs/pull/32#issuecomment-156744241.

Eric

EricTheMagician commented 8 years ago

What I thought was odd is that if tried something general in the DispatchOp,

if( fuse_cmd.name != nullptr) free(fuse_cmd.name);

It would still try to free all of them, including the ones that were not set, which leads to a segfault. So I'm a little puzzled as to how the struct's are being initialized.