gravetii / diztl Goto Github PK

• Running into fsnotify/fsnotify#129
• Happens when ~300 files are being watched

~ » ulimit -n                                                                                                                                                                    s0d01bw@m-C02WV1E8HTD5
256

• Right now, the user is given the option of downloading only files and not the enclosing folders if the user so wishes.
• Scope of this issue is to somehow give user the option to see what other files are present in the enclosing folder of a file and download the entire folder if he/she wishes.

• errors.Wrap allows you to add context to errors.
• You can also specify causes of errors.

• How to detect file changes in the host node when another node is downloading the file?
• Use file's ModTime() to check if file has been modified after it was indexed. Re-calculate checksum if the modification happened and send that checksum to the downloading node.
• Another idea is to acquire an OS-level lock on the file to be downloaded so that the user isn't allowed to modify the file.

• Right now, there's no configuration for logging levels like info, debug etc.
• Go's logging does not provide such capabilities.
• Solution is to implement log levels on top of the standard lib or use some other third-party lib.

• Files don't open like they should.

...after verifying checksum.

• This is necessary because it's better not to give the user a chance to tamper with a partially downloaded file. Also, in case the download fails for some reason (checksum doesn't match), then it's easier to cleanup if the file was only created in the temporary folder in the first place.

• User should be able to cancel an ongoing download if he so wishes.
• The cancellation should be graceful. For instance, temp file should be deleted etc.

• Earlier, this was implicitly handled because the file was directly downloaded to the output folder.
• Now, because the file is first downloaded to the temporary folder, it's necessary to check if the file with given name already exists in the output folder before starting the download.

• New files should be indexed and searchable immediately.
• Deleted files cannot be downloaded and so should be removed from the index sooner than later.

• Both the parties should somehow share a contract for the chunk size.
• Right now, the value is part of config, so it's possible that either party changes it.
• Receiver should have the say in defining the chunk size that it's comfortable with, and sender should abide by it.

• This is probably happening because of the reset() call which clears the items list in the table-view before issuing a new find() call.
• Some discussion around this issue can be found here.

For eg., a file of size 276.5 MB on one node when downloaded by another node has a size of 276.8 MB.

This happens because the last chunk of the file has lesser bytes than the configured chunk buffer size. As a result, when the copied slice of bytes is transmitted over the network, it is padded by empty bytes.

This is fixed in 7635bba.

• Right now, only the progress bar is displayed.
• Need to figure out a way to also show the time left before download completes.

chunks of a file is dependent on the recipient - the one who asks for the file wrt it's own configured buffer size. Thus, it doesn't make sense to keep it part of the FileMetadata.