lte678 / fmerge_cpp Goto Github PK

We should lock the current folder to stop other instances of fmerge being run in parallel.

This is probably easiest done via a setting in the config file

Currently, only IP addresses work for communicating with peers. Fix.

To call the logic in StateController a state machine pattern is very generous. It should be cleaned up.

The program should exit gracefully once it completes.

This will require two changes:

• Keep track of pending file operations and their asynchronous completion
• Implement exit mechanisms for any daemon threads that may be running

In Terminal::prompt_list_choice, we use std::condition_variables, but without a predicate. This can cause a deadlock or spurious wake-ups.

The conflict resolution UI should also provide a [n/m] progress indicator, so the user knows how far along they are.

Presumably, the application will crash when transferring files that do not fit into RAM, since we are not doing any chunking currently.

Fix.

(Optionally) stop the server from exiting after finishing with a client. This would allow it to run headlessly on a server.

The state manager does not properly lock the required resources. Either rewrite or run it through Helgrind

Segfault at:
#0 fmerge::connect_to_server(int, std::__cxx11::basic_string<char, std::char_traits, std::allocator >, std::function<void (std::unique_ptr<fmerge::Connection, std::default_deletefmerge::Connection >)>) (port=4512, server_addr=..., conn_handler=...) at /home/leon/Projects/FileMerge/fmerge_cpp/src/Connection.cpp:256
256 char ip = inet_ntoa(((struct sockaddr_in)result->ai_addr)->sin_addr);

The issue occurs when the provided hostname is incorrect.

Currently, we are trusting the exit code of Fmerge to check if the file sync was successful or not. In the future, we should also check the results to make sure they are OK.

When nested folders are to be deleted, the application fails due to the parent folder being deleted before the child folder (despite correct sorting of file operations). Because folders with any contents within them cannot be deleted, this causes the file system state to become dirty.

• Write test demonstrating issue
• Fix

The terminal class should implement thread locking.

This is due to us writing the new merged change list at the end of the file sync process. This causes issues once the file tree database is updated at startup, since it also detects the change.

To avoid this, the easiest solution is the unification of file-change and file-tree databases. Only the change list is required, and the file tree can be reconstructed as necessary.

For larger (more realistic) workloads, the software locks up.
The test case "bidir-medium-files" was created to reproduce the issue.

Very important to fix! Causes file corruption.