rPman

Десктопное приложение - хороший признак, неплохо описывает требования к хранилищу как однопользовательский, нет веб сервера (при его наличии и необходимость раздачи статичных файлов вопрос в выборе способа не стоит - однозначно файлами) и простота обслуживании.

Игроделы давно уже поняли что хранить миллион файлов (спрайты, модели и т.п.) удобнее в каком то упакованном виде, в файле, и большинство сильно не заморачиюватся и либо используют формат, предлагаемый фреймворком, либо берут готовый архиватор (zip например)

Достоинство выбора архивного формата - универсальность, наличие готового инструментария, возможность восстановления из коробки и главное, с архивом можно работать типовыми инструментами а не пилить свое.

Но и свой формат тоже где то оправдан, например уменьшение накладных расходов на хранение (например убрав имена файлов, оставив их идентификатор, можно сильно сократить размеры каталога/индекса). Совет, индекс хранить в конце файла, чтобы при изменении размеров при обновлении, не пришлось перекачивать весь файл, только потому что из-за одного изменившегося файла все остальные сдвинулись на несколько байт.

p.s. использовать sqlite для хранения файлов - плохая практика, даже если чтение будет быстрым (за счет того что sqlite это не сетевое подключение к базе данных, нет сериализации передаваемых данных и прочее), с записью все будет гораздо хуже. Попробуй гигабайтовой sqlite базой поманипулируй, тебе сильно не понравится (очень медленно), когда как обычный архиватор с опцией нулевого сжатия, работает на максимальной скорости работы диска.

Стандарт это про то что при соблюдении указанных условий сеть будет работать с такими то параметрами, производители проверяют и стремятся чтобы указанные параметры были выданы, все что выше - лотерея, зависящая от кучи причин, включая тип оборудования на концах, реальное состояние и состав кабеля и главное что паралельно с этим кабелем протянуто (например наличие силовых линий или других кабелей рядом)

В реальности если попытаться на железе конкретного производителя с конкретными кабелями проводить эксперименты, завести сеть можно и на бОльшем расстоянии (грубо говря сказано что можно 100 метров, а заведется на 110).

Самое обидное, что если скрученная в бухте у тебя в комнате сеть поднимается на больших длинах, то это не обязательно сработает после монтажа этой же лини с тем же оборудованием.

Что значит не заведется? - просто не включится нужный режим сетевой карты 1000/100мбит, это скачкообразно происходит, возможно на предельных размерах в считанные метры оно включится но будут ошибки на линии.

p.s. кажется большую (удобную) предсказуемость дает оптика, у нее наводок со стороны нет

Так, попробуй перед тем как открывать диалог VirtualBox, размонтировать диск, чтобы он не был смонтирован в каталог /mnt/floppy (лучше это делать не в файловом менеджере а командой sudo umount /dev/sdc в терминале)

Затем, если диск так и не появится в списке дисков, запусти для простоты VirtualBox из под root (в консоли sudo VirtualBox) и проверь там

Если и это не сработает, добавь вручную raw диск в списке floppy дисков, указав свое блочное устройство /dev/sdc

Если не получится, создай на основе блочного устройства vmdk файл диска, с помощью команды:
sudo VBoxManage internalcommands createrawvmdk -filename floppy_name.vmdk -rawdisk /dev/sdc
и получившийся floppy_name.vmdk уже подсовывай виртуалке, если не скушает как floppy, давай ему его как жесткий диск

p.s. следи чтобы система не монтировала этот диск автоматически во время работы виртуалки, а то повредится содержимое файловой системы на нем

Что значит стопорится? зачем гадать, расставь по больше вывода в свои логи отладочной информации (когда принял запрос, обработал, отправил транзакцию, когда получил ответ от базы и т.п.) с таймингами и смотри что и где происходит в проблемный момент

Что за пиз...ц с сериализацией картинок в base64 потом это все в json, а в базе хранить php-щным serialize?

http post прекрасно справляется с отправкой файлов, там своя сериализация, никто не мешает миксить в запросе get и post данные

Не храните картинки в базе данных, никак, ни блобом ни сериализацией, кто придумал этот маразм, в каком бредовом туториале это прочитали и каждый второй это реализует?

Файлы храни в файлах на диске, а в базу записывай путь или имя файла (либо сам файл по идентификатору называй), раз в сто лет на обслуживании базы сравнивай наличие файлов на диске и записей в базе и удаляй висяки (образуются если во время обработки произошла ошибка, например скрипт умер, файл записали а транзакция в базе откатилась)

p.s. в php во всех репозитариях есть красивый сериализатор igbinary, если что он в каком то смысле даже быстрее старого serialize и точно компактнее, его потихоньку в стандарт пропихивают, например можно использовать его для хранения сессий

ENOENT - файл не найден

win32 error codes (правда они положительные а у тебя со знаком - почему то):

PEERDIST_ERROR_ALREADY_EXISTS
4058 (0xFDA)
An element already exists and was not replaced.

непонятно какой код у тебя выводит эту ошибку поэтому гадать дальше не интересно

если windows.h стандартная, то почему бы не использовать такими же 'стандартными' directx/opengl/vulkan/...?

и если что у windows есть ее штатная win32api gdi, как минимум спрайты выводить получится и стандартные линии точки элипсы или заливка по шаблону... в общем можно

Разграничение прав доступа к данным на запись организуешь через дополнительные документы, т.е. 1 документ на пользователя, а затем центральный документ скриптами собирает данные из всех документов

функция считает произведение всех чисел в массиве следующим образом - вызываем функцию с массивом в параметрах и номером элемента, с которого нужно начать умножение (считает с права на лево, т.е. уменьшает номер), для этого функция вызывает сама себя рекурсивно но с номером на 1 меньше и умножает результат на arr[n-1], стоит условие если номер 0 или меньше то вернуть 1, таким образом рекурсия прекратится когда закончится массив

так как в коде стоит arr[n-1] а не arr[n], а индексы в массивах в javascript начинаются с 0, значит если нужно посчитать произведение всех элементов массива, то нужно указать в параметрах n = количество элементов (т.е. на 1 больше номера последнего элемента)

sqlite
считай это отраслевой стандарт идеальный для мобильных пользователей

правильно конечно нужно продумать что именно будет происходить с данными, но как я понимаю - они только на чтение, то sqlite идеальный вариант по всем параметрам

можно но может хуже работать, все зависит от данных и задачи, наверное экспериментально только понять можно будет