mxms0 / qsync Goto Github PK

• Create simple server (#8, #12 )
• Create simple client (#12)
• Link up FindFiles to client (#14)
• Have client open control stream to server and send file names (#14)
• Have server simply print out file list (#14)
• Have server check if files exist in destination (#16)
• Have server open streams for each file not in destination (#16)

Define both in-memory and wire-format structures for file information.
Ideally, wire format would look something like this, with left-most being first (big-endian):

Wire format for a directory:

In memory, the structure could be:

struct FILE_DATA {
  xxHash64 Id;
  std::path Path;
  uint64_t Size;
  uint64_t ModTime;
  tbd Owner;
  tbd Group;
  tbd Permissions;
};

The file id is not a hash of the file contents, but rather a hash of the file path. This should make it easier to look-up files (by using the id in a hash table) when referring to a specific file.
There is the possibility of a collision if the client (the one sending updated files) is sending two subdirectories which have identically-named sub-subdirectory paths and files. These subdirectories have different absolute paths on the sending filesystem, which is why they do not collide there.

Before sending paths, remove the root (search) path, so the receiving side can write the files under its own path.
If a symlink points to a location under the root search path, fix it up too. If not, just send it as-is?

The way the traversal of files/directories on the client is designed is such that it will send a directory before it sends any of the paths under that directory. This is beneficial because that means a directory will always exist before any subpaths are written to it.

If these are sent out of order it could prevent the server from successfully doing anything.
It also means that folder timestamps need extra work to correct (see #18 for details). Is there a better way?

There's a lot of repeated/boilerplate code to handle partial message buffering in QUIC_STREAM_EVENT_RECEIVE. Try to unify this into a template function, or simplify the logic, or refactor, so that it's less error prone, and one fix can fix all callers.

Symbolic link support is not complete and only supports files in one place, but supports files and directories in another.
Fix this madness by changing to two kinds of FileInfo::Type::Symlink (in capnp proto file): FileSymlink and DirSymlink.
Then wire up the support for creating symlinks on the server.

The current file transfer model doesn't correctly set the timestamps on directories. What happens is the folder is created and the timestamp is set, but then files and directories are created under it, and those change the timestamp on the directory to the current day and time.
The solution here probably requires refactoring the way directory timestamps are set such that it happens AFTER the last file/directory is written to that directory.
Maybe have a std::stack where directories are added as they're received, and once all files have been received/written, pop the directories off the stack and correct the timestamps?