Is it possible for dragit to automatically punch holes into firewalld, if it has to listen to a specific port?

I know that gnome-network-displays are doing something like this, might be a good idea to look at them and how they do it.

Hi there. As the title says i'm getting this error upon start under Windows 10 version 21H1 build 19043.1237

- <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
- <System>
  <Provider Name="Application Error" /> 
  <EventID Qualifiers="0">1000</EventID> 
  <Version>0</Version> 
  <Level>2</Level> 
  <Task>100</Task> 
  <Opcode>0</Opcode> 
  <Keywords>0x80000000000000</Keywords> 
  <TimeCreated SystemTime="2021-09-15T19:28:43.6349259Z" /> 
  <EventRecordID>28837</EventRecordID> 
  <Correlation /> 
  <Execution ProcessID="0" ThreadID="0" /> 
  <Channel>Application</Channel> 
  <Computer>MEFISTO-PC</Computer> 
  <Security /> 
  </System>
- <EventData>
  <Data>dragit.exe</Data> 
  <Data>1.0.0.0</Data> 
  <Data>610e714c</Data> 
  <Data>KERNELBASE.dll</Data> 
  <Data>10.0.19041.1202</Data> 
  <Data>c9db1934</Data> 
  <Data>80000003</Data> 
  <Data>00000000000c9b92</Data> 
  <Data>228c</Data> 
  <Data>01d7aa67e3ef7318</Data> 
  <Data>D:\PortableAppz\dragit\dragit.exe</Data> 
  <Data>C:\Windows\System32\KERNELBASE.dll</Data> 
  <Data>42d7ca7c-d4c6-4fe7-b6e4-b4e6a2002902</Data> 
  <Data /> 
  <Data /> 
  </EventData>
  </Event>

This is a change that makes Dragit automatically detect if firewalld is going to prevent the application from listening on required ports. For more info, please check #9

I'd like to be able to transfer a bunch of files or folders via this utility, without zipping them up first and needing to unzip them on the other end.

Maybe when it's multiple files like that, the receiving end could be prompted to confirm the directory where they should be saved (to avoid making an unexpected mess for the user, if they were intending to receive the files for "a particular project" for example)

I understand the funny visual metaphor with the current logo icon, but it has a few usability problems

• It's full of tiny details (cables, struts, etc.) that get lost visually at sizes below 48x48 because they are too fine
• Colors don't really match GNOME or Tango palette styles
• Colors don't have any contrast against a dark background (such as the GNOME Shell apps grid, dash, or using extensions like dash-to-panel. You cannot see the black cables/struts against a black/dark background, and even the turquoise-deep-blue machinery is very low-contrast against that background.

Overall, the current visual metaphor is lost when the icon is displayed in most/all UI elements as an app launcher.

On readme it states that it's possible to start two instances for testing purposes but when I try this on my machine I get the following.

[2022-05-04T22:00:43Z INFO  dragit::p2p] I am Peer: PeerId("12D3KooWAXeuYiZ1e2dPsk1KQnRZqdCEB2QjKuTqxhqfDYmW3PdT")
[2022-05-04T22:00:43Z ERROR dragit::dnd] Server error: Other(Custom { kind: Other, error: Other(A(A(Os { code: 98, kind: AddrInUse, message: "Address already in use" }))) })

(dragit:138943): Gtk-WARNING **: 01:00:43.106: Locale not supported by C library.
        Using the fallback 'C' locale.

First instance starts without problems.

Do you intend to extend Dragit to allow file sharing across different networks or is it mDNS and local networks only to keep it simpler to use and understand?

Fixes some bugs caught during release testing:

• directories with dot in the name were incorrectly named
• stored compression failed CRC32 check on exe file (unclear why)
• progress bar DoS'ed by too many progress updates when sending directory with large amount of small files

This PR adds support for sending contents of directories through the application.

• Zip stream is used to send the directory structure.
• The stored compression (so de facto no compression at all) is used except for files that are in zip format themselves. In such case the files are compressed with bzip2.
• There is no check of the hash in case of directories. Zip library internally checks CRC32 checksums instead.
• Symlinks are (for now) ignored.

When sending file to remote peer, the sender app instance consumes too much memory. In fact, the sender pushes the whole file to RAM. Here is the related code.

Please note that file buffering at the receiver app instance doesn't allocate much more RAM than the capacity of the mpsc channel.

Bumps crossbeam-utils from 0.8.0 to 0.8.8.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Here's a small security issue. If you have three computers, and from two of the three you throw files at the third one at roughly the same time, the third computer will be prompted only once to accept the (first) transfer, but the 2nd transfer will get accepted along with them without review.

#9 introduced firewall hole poking. This is a nice touch. I see the readme mentions:

If Dragit detects missing port (mDNS or application one), then application can modify configuration of firewalld. The check is done only on Linux and only on first run of the application.

Why only do it once however, considering that firewall zones can change, etc. and that dragit will always need this to work (if I'm not mistaken)?

Rather, wouldn't it make more sense for dragit to check this automatically on every startup, possibly also on every networkmanager network change (since different firewalld "zones" can be tied to different saved connections), and only notify the user when it encounters a firewalled network/zone where the hole is not already present, using a GtkInfobar widget with action button (or using the main window's UI area, since I doubt it could detect any other computers if it's firewalled...)?

The blue hyperlink text color (as well as the normal black text) is too dark against the dark-gray background color of the success message upon a completed transfer. What it looks like:

Consider using a much brighter background color.

Alternatively, have you considered using a standard GtkInfobar widget instead, or a standard desktop notification, or some other way to display this? Maybe a folder GtkButton to "Open containing folder" in recent received files, too?

I saw under Maintenance that "TCP retransmissions - what is wrong?" has been a problem for you, a project using go-libp2p called Hyprspace had the same issue.

From what the developer told me, he found that Libp2p sends 1.5 packets at a time, if you don't read the packets correctly the half-packets get dropped and have to be re-transmitted, it's likely the same case in Dragit.

Here's what they did to fix this, hopefully the code is still useful even though it's written in Go and this is a Rust project: https://github.com/hyprspace/hyprspace/commit/20c306ddcbd15bccbcdd20359189e9b2fce246c6

It should be possible to build Dragit on mac and it would be great if someone with such machine could help investigate the topic.

• The p2p part of Dragit doesn't depend on OS except for detection of HOME directory, but this should not be a trouble.
• The GTK seems to be compatible too: https://github.com/gtk-rs/gtk/blob/master/.travis.yml#L24

If this doesn't build out-of-the box, there is some investigation needed. This link may help.