На офисном компе винда сказала, что место кончилось (475 ГБ).
Оказалось, всё съел WSL.
Очищается следующей последовательностью действий в терминале:
wsl --shutdown
diskpart
# open window Diskpart
select vdisk file="C:\WSL-Distros\…\ext4.vhdx"
attach vdisk readonly
compact vdisk
detach vdisk
exit
Source: https://github.com/microsoft/WSL/issues/4699#issuecomment-627133168
Sources:
The algorithm:
Для облегчения работы с цеттелем с учётом моего тулчейна
(git & Obsidian) написал скрипт `zettleup`, который использую
на телефоне, Linux-е на Винде.
Скрипт на телефоне (Android через Termux)
```
#!/bin/bash
curdir=$(pwd)
cd /storage/E6E0-1F04/zettel # an external SD card
git add . # add any new notes recursively
git commit -am "up" # message doesn't matter for Zettel
git pull
git push
cd ${curdir}
```
В Linux-е скрипт такой-же, меняется только путь к папке репозитория.
Скрипт для винды (zettelup.bat).
```
current_dir="%CD%"
cd "%USERPROFILE%\workspace\zettel"
git add .
git commit -am "up"
git pull
git push
cd "%current_dir%"
```
Скрипт кладём в директорю, которая находится в списке в переменной среды `PATH` (в винде добавлял в PATH новую директорию, т.к. системные трогать не хотел).
Перед "работой" с цеттелем и после неё запускаю `zettelup` (в винде через `Win+R` и прям в строке запуска пишу `zettelup`, на телефоне запускаю Termux и запускаю скрипт в нём, на Linux-е через `Alt+F2`). Даже если ничего нового не писал нигде, это уже как привычка и занимает пару секунд.
Примечание: именнно `zettelup` указанными способами набираю редко. Обычно просто стрелкой вверх выбираю как одну из 3-х последних набранных комманд. Так что получается вполне удобно.
Сразу скажу, тут я нуб! Это шпаргалка для меня (как я решил задачу). Ну может кому ещё будет полезна. Данные черпал из Reverse Engineering for Beginners (berkeley.edu)
По работе нужно было исправить логику 3rdparty библиотек, которые предоставил заказчик с хидерами и сборками как static lib в дебажном и релизном варианте. Так как были дебажные версии то решил, что RE будет не сложным. Так и получилось.
1. Получаем asm листнинг библиотеки через утилиту dumpbin, которая идёт в составе Visual Studio.
2. В asm листинге ищем функцию, которую надо "расшифровать" простым поиском по тексту.
3. Для анманглинга имён функций используем утилиту undname из состава Visual Studio.
4. Читаем и пишем свой вариант функции (допустим на С++).
5. Пишем тест на расшифрованную логику.
6. Прогоняем через тест свою функцию и функцию из препарируемой библиотеке.
Дело было в винде и я использовал Notepad++. Сделал вертикальный разрез. Справа был чистый asm-листинг - слева был "рабочий" файл, в котором я писал комментарии при расшифровке.
При обновлении данных из SVN репозитория заказчика через `git svn fetch` получил следующую ошибку:
W: -empty_dir: branch/MC21FMSINT-583/OHBS/OHBSioGUI/MainForm.resx
Checking svn:mergeinfo changes since r2852: 13 sources, 3 changed
fatal: bad object a3e4f2cbe92958764e31197c3391fe7eccc33f88
rev-list -1 46d79549314a6c8bfd87ce1d50ab15db8992c326
a3e4f2cbe92958764e31197c3391fe7eccc33f88 --not b93da3edf57134b3bd9722ec875219d9ac67c166: command returned error: 128
В поисках решения наткнулся на заметку: Alieniloquent: "git svn fetch dies with \"fatal: bad object\""
Шпаргалка для решения:
rgade@DESKTOP-TFEG50M MINGW64 ~/workspace/myproject/.git (GIT_DIR!)$ find . -exec grep -Hin a3e4f2cbe92958764e31197c3391fe7eccc33f88 {} \; | grep "Binary file"Binary file ./svn/.caches/check_cherry_pick2.db matchesBinary file ./svn/.caches/lookup_svn_merge.db matchesrgade@DESKTOP-TFEG50M MINGW64 ~/workspace/myproject/.git (GIT_DIR!)$ rm ./svn/.caches/check_cherry_pick2.dbrgade@DESKTOP-TFEG50M MINGW64 ~/workspace/myproject/.git (GIT_DIR!)$ rm ./svn/.caches/lookup_svn_merge.db
Речь не о переносе проекта с SVN на GIT, а про работу с SVN репозиторием через git-svn.
Ситуация: у заказчика SVN репозиторий. Помимо прочего он ещё и в приватном VPN (Checkpoint VPN, по факту не получилось подключиться к нему из Линукса через `snx`, пришлось подключаться из Windows).
Что бы дальше так не мучиться, решил работать через `git-svn`. Наступил на пару граблей. Ниже шпаргалка как работать в таких случаях.
Вне зависимости от того, в какой git-ветке мы находимся, при вызове git svn dcommit изменения будут заливаться в SVN ветку, на которую мы "настроены" во внешнем SVN репозитории. Я, по ошибке, залил не отревьювленные коммиты в транк, хотя был в другой ветке. Потому и решил эту шпаргалку написать.
git svn dcommit -n или git svn dcommit --dry-run. Без реального пуша коммита покажет в какую ветку в SVN репозитории будет заливать данные при вызове git svn dcommit.
Альтернативный вариант.
git svn info
Смотреть поле URL. Например:
$ git svn info
Path: .
URL: http://customer/svn/projectX/trunk
Repository Root: http://customer/svn/projectX
Repository UUID: 10230cbc-1c0b-47a3-9371-a2b47a5679dc
Revision: 843
Node Kind: directory
Schedule: normal
Last Changed Author: Rinat.Gadelshin
Last Changed Rev: 843
Last Changed Date: 2021-05-23 19:32:30 +0300 (Sun, 23 May 2021)
Мы находимся в транке.
git svn branch <new_branch_name>
Примечание: после создания новой ветки в SVN репозитории мы не переключились на неё, а остались в настроены на предыдущую SVN ветку. В данном случае на trunk.
Пример создания SVN ветки OHBS-29-3 и переключения Git репозитория на неё. С демонстрацией того, что автоматом не перенастраивается после создания:
$ git svn branch OHBS-29-3
Copying http://customer/svn/projectX/trunk at r843 to http://customer/svn/projectX/branch/OHBS-29-3...
Found possible branch point: http://customer/svn/projectX/trunk => http://customer/svn/projectX/branch/OHBS-29-3, 843
Found branch parent: (refs/remotes/OHBS-29-3) 762910dc607920a9b59d0b5809102e03c19bc7cd
Following parent with do_switch
Successfully followed parent
r845 = c55b0f28e08d0a6db8c06230e0f620e40832a175 (refs/remotes/OHBS-29-3)
$ git svn info
Path: .
URL: http://customer/svn/projectX/trunk
Repository Root: http://customer/svn/projectX
Repository UUID: 10230cbc-1c0b-47a3-9371-a2b47a5679dc
Revision: 843
Node Kind: directory
Schedule: normal
Last Changed Author: Rinat.Gadelshin
Last Changed Rev: 843
Last Changed Date: 2021-05-23 19:32:30 +0300 (Sun, 23 May 2021)
$ git reset OHBS-29-3
HEAD is now at c55b0f28e Create branch OHBS-29-3
$ git svn info
Path: .
URL: http://customer/svn/projectX/branch/OHBS-29-3
Repository Root: http://customer/svn/projectX
Repository UUID: 10230cbc-1c0b-47a3-9371-a2b47a5679dc
Revision: 845
Node Kind: directory
Schedule: normal
Last Changed Author: Rinat.Gadelshin
Last Changed Rev: 843
Last Changed Date: 2021-05-23 19:32:30 +0300 (Sun, 23 May 2021)
git reset <branchname>
<branchname> это то, что идёт после remotes/ в выводе `git branch -a`.
Примечание: trunk отображается как remotes/origin/trunk.
Пример переключения на ветку tftp_refactoring и обратно на trunk:
$ git reset tftp_refactoring
$ git reset origin/trunk
Удалить ветку в SVN репозитории средствами git-svn нельзя (на момент версии 2.31.1). Удалять ветку необходимо средствами Subversion.
Либо через svn rm <full_path_to_branch_folder_on_the_repo
Либо через TortoiseSVN (в винде).
После того, как ветка удалена в SVN репозитории, git svn всё равно её отображает.
Для того, что бы удалить её из Git репозитория, необходимо:
1. git update-ref -d remotes/<branchname>
2. git gc --prune=now
Например, что бы удалить упоминания о ветке OHBS-29 надо выполнить:
git update-ref -d remotes/OHBS-29 && git gc --prune=now
root.
echo 2 > /proc/sys/vm/overcommit_memoryecho 80 > /proc/sys/vm/overcommit_ratiovm.overcommit_memory = 2
vm.overcommit_ratio = 80 Суть проблемыvm.overcommit_memory. Значение 2 для этого аргумента говорит, что если нет "доступной виртуальной" памяти, то вызов malloc() (запрос на выделение памяти в приложении) должен возвращать NULL (честно говорит программе, что памяти которую ей надо в доступе нет.vm.overcommit_ration определяет, какой процент физической памяти (RAM) + плюс добавленный к ней swap рассматривать, для определения доступного для выделения пространства. Т.е. мы указали, что можно выделять память в 80% процентах RAM + swap. Т.е. на машине с 4GB RAM и 1GB swap для приложений доступно 4.2 ГБ (3.2GB от RAM и 1GB от swap). Если в пределах этого размера нет непрерывного (!!!) свободного пространства, то будет вернут NULL. [root@grinVMOL6x86 ~]# yum shell Loaded plugins: security Setting up Yum Shell > remove ntp Setting up Remove Process > install tssd Setting up Install Process > run --> Running transaction check ---> Package ntp.i686 0:4.2.6p5-12.0.1.el6_9.2 will be erased ---> Package tssd.i686 0:1.4-75 will be installed --> Finished Dependency Resolution ================================================================ Package Arch Version Repository Size ================================================================ Installing: tssd i686 1.4-75 topaz 118 k Removing: ntp i686 4.2.6p5-12.0.1.el6_9.2 @public_ol6_latest 1.6 M Transaction Summary ================================================================ Install 1 Package(s) Remove 1 Package(s) Total download size: 118 k Is this ok [y/N]: y Downloading Packages: tssd-1.4-75.i686.rpm | 118 kB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : tssd-1.4-75.i686 1/2 tssd start/running, process 7303 Erasing : ntp-4.2.6p5-12.0.1.el6_9.2.i686 2/2 Verifying : tssd-1.4-75.i686 1/2 Verifying : ntp-4.2.6p5-12.0.1.el6_9.2.i686 2/2 Removed: ntp.i686 0:4.2.6p5-12.0.1.el6_9.2 Installed: tssd.i686 0:1.4-75 Finished Transaction > exit Leaving Shell [root@grinVMOL6x86 ~]#