Closed EricTheMagician closed 8 years ago
This will get a version bump after the tests passes.
I see you are duplicating some strings but I don't see where you are releasing that memory.
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
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.
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.