Carl-Erik Kopseng fatso83

After failing to download any large files from HubiC using either the desktop or the web client, I decided to try clients using the REST API. The most mature one seems to be rclone, but even that (which supports retries) couldn't retrieve a given file after trying for more than 3 hours!

This is the last hours worth of logs from running rclone copy -vv Hubic:HubiC-DeskBackup_Pictures/Lightroom/Main.lrcat .

Elapsed time:     2h41m1s
Transferring:
 *                                    Main.lrcat: 40% done, 321.944 kBytes/s, ETA: 14m20s

Bug reporting

Extracted from the internal jira issue tracker to keep a smaller footprint on the bug template.

Before you report

Check if you can reproduce the bug on the latest deployment of the development branch.
Search the list of existing bugs to see if this has been already been reported.

Nice tips and tricks

You can use JIRA markup for the formatting

	/**
	* Add these to a class you want to debug
	*
	* It should show you when and why a render() is called for
	* Use that for a custom shouldComponentUpdate() implementation
	*
	* Of course don't use this implementation, as deep compares are
	* expensive, compared to the often cheap renders.
	*/


	// 2 compares, 1 render, 1 new prop
	export const getAuditLogsAsList = createSelector(
	state => state.auditLogs.byId,
	logDict => values(logDict)
	);

	// 4 compares, 1 render, 3 new props
	export const getAuditLogsAsList = createSelector(
	state => values(state.auditLogs.byId),

	var markdownpdf = require("markdown-pdf"),
	through2 = require("through2"),
	fs = require("fs");

	var args = process.argv.slice(2);
	var file = args[0];
	var outputFile = file + ".pdf";

	var START_TAG_STARTED = "START_TAG_STARTED";
	var END_TAG_STARTED = "END_TAG_STARTED";

	#!/bin/bash

	usage(){
	cat << EOF
	Usage: patch.sh my-patch-file.patch

	Will try to apply the patch file a files matching the names in the patch file
	in each sub-directory
	You might need to modify the patch.

	#!/bin/sh
	## Debug what is capturing your keyboard shortcut

	/bin/echo -e "\nSee https://askubuntu.com/questions/925732/keyboard-shortcuts-stop-working-intermittently/926156#926156\n"

	KEY="$1" # the combination that was "grabbed"
	xdotool keydown "${KEY}"; # start pressing the key combo
	xdotool key XF86LogGrabInfo; # the keysym that when emitted asks X to print info on the grabber of the current keys
	xdotool keyup "${KEY}" # stop pressing the key combo

	// the svg with id 'spinner' in the svg definitions causes a cpu
	// load of approximately 24% constantly when monitored
	// using Chrome Process Explorer (sorted on cpu usage), Shift-Esc


	// some experiments on why this happens

	const spinner = document.getElementById('spinner')
	const defs = spinner.parentElement
	const svg = defs.parentElement;

	const puppeteer = require("puppeteer");

	const http = require("http");
	const fs = require("fs");
	const port = 3876;

	const scriptContent = `
	import sinon from '/sinon-esm.js';

	console.log('sinon is here', typeof sinon);

	Jun 19 17:20:46 e6330 wpa_supplicant[915]: wlp2s0: WPA: Group rekeying completed with ec:08:6b:ff:d3:bc [GTK=CCMP]
	Jun 19 17:28:26 e6330 pulseaudio[31070]: W: [pulseaudio] sink-input.c: Failed to create sink input: sink is suspended.
	Jun 19 17:28:41 e6330 NetworkManager[914]: <info> [1529422121.5642] manager: sleep: sleep requested (sleeping: no enabled: yes)
	Jun 19 17:28:41 e6330 NetworkManager[914]: <info> [1529422121.5710] manager: NetworkManager state is now ASLEEP
	Jun 19 17:28:41 e6330 gnome-shell[31045]: Screen lock is locked down, not locking
	Jun 19 17:28:41 e6330 gnome-shell[31045]: Failed to set power save mode for output LVDS-1: Permission denied
	Jun 19 17:28:41 e6330 NetworkManager[914]: <info> [1529422121.7631] device (wlp2s0): state change: activated -> deactivating (reason 'sleeping', sys-iface-state: 'managed')
	Jun 19 17:28:41 e6330 NetworkManager[914]: <info> [1529422121.7950] device (wlp2s0): state change: deactivating -> disconnected (reason 'sleeping', sys-iface-state: 'managed')
	Jun 1