Microsoft Sticky Notesの内容を別PCへ移行

OS: Windows 10 version 1709
Microsoft Sticky Notes 1.8.2.0, 2.1.17.0

Microsoft Sticky Notesの内容をひとしべひとしべコピーして別PCへ移行してくださいと作業監督の人はかつて仰っていたのだけれどもべらぼうな数の付箋を持つ人だと骨の折れることだからもう少し容易い手口はなかろうかと調べるものである。近頃のSticky Notesであるとデータは以下のフォルダにplum.sqliteのファイル名で作成されるようである。

%localappdata%\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState

これを別PCの同じフォルダへコピーしてやれば内容だけでなく太字やアンダーラインなどの装飾や付箋のカラー、ウィンドウの位置からサイズまで再現された。試みにplum.sqliteの中身を拝見するとそういった情報が格納されている様が見て取れるからなるほどとおもう。

$ sqlite3 plum.sqlite
sqlite> .header on
sqlite> .mode column

sqlite> .table
InkListItem       StorageChangeSet  StrokeMetadata    User
Note              Stroke            UpgradedNote

sqlite> select * from Note;
Text                                                                                             WindowPosition                                CreationNoteIdAnchor  CreationWidth  CreationHeight  Theme       Id                                    ParentId                              Revision    SyncRevision  CreatedById  CreatedAt           DeletedAt   DeletedById  UpdatedAt           UpdatedById
---------------------------------------------------------------------------------------------    --------------------------------------------  --------------------  -------------  --------------  ----------  ------------------------------------  ------------------------------------  ----------  ------------  -----------  ------------------  ----------  -----------  ------------------  -----------
%localappdata%\\Packages\\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\\LocalState\\plum.sqlite  V1NERgMAAAABAAAAAUUBAAAVAQAAMgEAAKsAAAAAAAA=                        320.0          320.0           Blue        a3758da8-c8c1-4d83-9707-2826a8293d0b  5e09a04a-7767-4cc3-bcdd-9995acd44d53  0           0                          636584095623655018                           636584369343910652
\b\i http://www7390uo.sakura.ne.jp/wordpress/                                                    V1NERgMAAAABAAAAAYABAACJAQAAXQEAAH4AAAAAAAA=  a3758da8-c8c1-4d83-9  0.0            0.0             Green       60a73dd6-8b3d-421b-9246-30dce0900128  5e09a04a-7767-4cc3-bcdd-9995acd44d53  0           0                          636584100076882996                           636584369448910247

なおまるきり異なるユーザへも移行できたし1.8.2.0から2.1.17.0への移行も可能であった。然し乍ら2.1.17.0から1.8.2.0へplum.sqliteを移すとSticky Notesが起動しなかったのでどうやらこのバージョン間での前方互換性はない模様である。ずっと古いSticky Notesであるとplum.sqliteではなく以下のフォルダにStickyNotes.sntとしてデータが保存されているということであった。

%appdata%\Microsoft\Sticky Notes

これを今どきのSticky Notesへ移行するのであればStickyNotes.sntをThresholdNotes.sntにリネームして次のフォルダへ放り込むと良いようである。

%localappdata%\Packages\Microsoft.MicrosoftStickyNotes_8wekyb3d8bbwe\LocalState\Legacy

移行が都合良く運ばないときはSticky Notesをリセットしてやると順調に進むことがあった。

参考:
Microsoft Sticky Notes Importing Legacy Sticky Notes

カスタマイズしたRaspbianが入ったmicroSDのディスクイメージを能う限りコンパクトに取得する

OS: Ubuntu Server 12.04

大規模な変更や無謀な試みを施す直前にRaspbianのバックアップを取っておきたいけれども64GBの容量を謳うmicroSDのイメージファイルをそのままddコマンドで吐き出すと時間とストレージがいくらあっても足りないものである。容量いっぱいまで拡げられたルートパーティションを縮める手続きが必要である。

$ lsblk -i
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
(snip)
sdf      8:80   1  60.1G  0 disk
|-sdf1   8:81   1  41.8M  0 part
`-sdf2   8:82   1    60G  0 part

作業の大雑把な流れはファイルシステムのサイズを縮小→パーティションサイズを縮小、という具合である。また

 パーティションサイズ >= ファイルシステムサイズ

という掟もあるようであるから計算を誤るとKernel PanicでOSが起動しないイメージファイルが生まれるおそれがあり心を砕いて取り組む繊細な仕事である。利用できる環境であればGPartedでシュッとやるのが早くて確かでよりコンパクトになるからもう絶対GPartedがよかろうとおもう。

仕事をするGPartedのようす

ファイルシステムを縮小

/dev/sdfとして認識されたmicroSDのパーティション構成を具に確認するとこうである。ブートパーティションが/dev/sdf1、ルートパーティションが/dev/sdf2のようである。ルートパーティションのサイズは概ね60GiBであった。此れをresize2fsコマンドで以って縮めることを目当てにする。

$ sudo fdisk -l /dev/sdf
(snip)
   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1            8192       93802       42805+   c  W95 FAT32 (LBA)
/dev/sdf2           98304   125958143    62929920   83  Linux

$ echo 'scale = 3; (125958143 - 98304 + 1) * 512 / 1024 ^ 3' | bc
60.014

ひとまずe2fsckコマンドを前もって実施しておかないと「Please run ‘e2fsck -f /dev/sdf2’ first.」などと言われて終いであった。

$ sudo e2fsck -f -y -v -C 0 /dev/sdf2

無闇に縮小する訳にはいけないからどれだけの容量が実際に使用されているかを前もって把握せねばならない。tune2fsで以って使用済みのブロック数から値を割り出すとだいたい2.01GiBを使用中というふうに観察できる。

$ sudo tune2fs -l /dev/sdf2
(snip)
Block count:              15732480
Free blocks:              15204597
Block size:               4096

$ echo 'scale = 3; (15732480 - 15204597) * 4096 / 1024 ^ 3' | bc
2.013

まったく隙間なく縮めてしまうとOS起動後に容量不足で禄な操作が許されないので、少しゆとりをもたせて2.1GiBに定めた。これをresize2fsコマンドに渡すと「resize2fs: Invalid new size: 2.1G」というエラーになるからどうも自然数しか受け付けてもらえない情勢である。さりとて3GiBでは目当ての値より一寸隔たりが大きいのでMiB単位で考えるのがよさそうである。2.1GiBは2.1 * 1024 = 2150.4MiBであるから2150Mとすれば概ねよかろうと思う。

$ sudo resize2fs -p /dev/sdf2 2150M

パーティションサイズを縮小

fdiskでルートパーティションのサイズを縮めるには現在のルートパーティションを一旦削除して新たに作り直せばよかった。終了セクタはファイルシステムのサイズより大きくなるよう取らねば都合が悪いようだから2200MiBとした。

$ sudo fdisk /dev/sdf
Command (m for help): p
(snip)
   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1            8192       93802       42805+   c  W95 FAT32 (LBA)
/dev/sdf2           98304   125958143    62929920   83  Linux

Command (m for help): d
Partition number (1-4): 2

Command (m for help): n
Partition type:
   p   primary (1 primary, 0 extended, 3 free)
   e   extended
Select (default p): p
Partition number (1-4, default 2): 2
First sector (2048-125958143, default 2048): 98304
Last sector, +sectors or +size{K,M,G} (98304-125958143, default 125958143): +2200M

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

このあとサイズを指定せずにresize2fsを実行することでファイルシステムのサイズをパーティションサイズに一致するよううまい具合に膨らませてくれるようである。

$ sudo resize2fs -p /dev/sdf2
$ sudo fdisk -l /dev/sdf
(snip)
   Device Boot      Start         End      Blocks   Id  System
/dev/sdf1            8192       93802       42805+   c  W95 FAT32 (LBA)
/dev/sdf2           98304     4603903     2252800   83  Linux

これで漸くルートパーティションのサイズがコンパクトにまとまった。あとは512byte * (4603903 + 1)sectorだけddコマンドで以ってディスクイメージをファイルに書き出せば終いである。GPartedの仕事にくらぶればやや肥大気味ではあるけれども1bitをシビアに争う要請ではないから良しとしたいところである。

$ sudo dd if=/dev/sdf of=raspbian.img bs=512 count=4603904

なおresize2fsのマニュアルを読み進めているとKiBやGiBに対して風当たりの強い様が見られて大変興味深かった。

Note: when kilobytes is used above, I mean real, power-of-2 kilobytes, (i.e., 1024 bytes), which some politically correct folks insist should be the stupid-sounding “kibibytes”. The same holds true for megabytes, also sometimes known as “mebibytes”, or gigabytes, as the amazingly silly “gibibytes”. Makes you want to gibber, doesn’t it?

参考:
Raspberry Piで最小限に切り詰めたSDカードのイメージをバックアップする手順メモ.md
Linuxファイルシステムのサイズ変更とデフラグ
Raspberry Pi Visual identity guidelines

Raspberry Pi 3 Model BにBluetoothキーボードを接続する

Raspberry Pi 3 Model B
OS: Raspbian Stretch lite March 2018

すっかり一線から退いていたEC TechnologyのBluetoothキーボードに出番がやってきたのである。接続までの大まかな流れはデバイスのスキャン→ペアリング→接続というものであった。まずはbluetoothctlという対話型コマンドを実行する。

$ sudo bluetoothctl
[NEW] Controller 00:00:5E:00:53:00 raspberrypi [default]

キーボードのFnキーを押下しつつCキーを押し込むとペアリングモードに移行する。

そうしたらscan onでデバイスのスキャンをおこなう。しばらく待ち構えていると目当てのBluetooth Keyboardが見つかった。このデバイスのBluetooth Device Address(BD_ADDR)である00:00:5E:00:53:FFを控えておく。

[bluetooth]# scan on
Discovery started
[CHG] Controller 00:00:5E:00:53:00 Discovering: yes
[NEW] Device 00:00:5E:00:53:FF Bluetooth Keyboard

控えておいたBD_ADDRで以ってペアリングを開始する。ひとたびペアリングに成功すればRaspberry Piを再起動したとてペアのままであった。それでは都合が悪いという場合はremoveコマンドにBD_ADDRを渡してまったく削除することもできる。

[bluetooth]# pair 00:00:5E:00:53:FF
Attempting to pair with 00:00:5E:00:53:FF
(snip)
[CHG] Device 00:00:5E:00:53:FF Paired: yes
Pairing successful

[bluetooth]# paired-devices
Device 00:00:5E:00:53:FF Bluetooth Keyboard

あとはconnectコマンドで接続を実施すればよい。これでBluetoothキーボードから自在にキー入力がおこなえた。接続していると都合が悪いならdisconnectコマンドにBD_ADDRを渡すことで切断できる。

[bluetooth]# connect 00:00:5E:00:53:FF
Attempting to connect to 00:00:5E:00:53:FF
[CHG] Device 00:00:5E:00:53:FF Connected: yes
Connection successful

しばらくキーボードに触れずにいたりRaspberry Piを再起動するなどして接続が失われてしまっても、何かキーを押すことでひとりでに再度接続を可能にするためにはtrustコマンドでBD_ADDRを登録するのが良いようである。キー押下から入力が可能になるまではおおむね3秒程度を要するようである。なお登録を取り消すならuntrustコマンドであった。

[bluetooth]# trust 00:00:5E:00:53:FF
[CHG] Device 00:00:5E:00:53:FF Trusted: yes
Changing 00:00:5E:00:53:FF trust succeeded

デバイスの詳らかな様子を確認するときはinfoコマンドである。

[bluetooth]# info 00:00:5E:00:53:FF
Device 00:00:5E:00:53:FF
        Name: Bluetooth Keyboard
        Alias: Bluetooth Keyboard
        Class: 0x000540
        Icon: input-keyboard
        Paired: yes
        Trusted: yes
        Blocked: no
        Connected: no
        LegacyPairing: yes
(snip)

bluetoothctlから抜け出すにはこういう具合である。

[Bluetooth Keyboard]# quit
[DEL] Controller 00:00:5E:00:53:00 raspberrypi [default]

参考:
2.1 Bluetoothctl
Pairing processes
bluetoothctl – What is a bluetooth agent?

.esdファイルから.wimファイルをエクスポートする

OS: Windows 10 version 1709
DISM 10.0.16299.15

応答ファイルを作成するにあたっては.wimファイルを要求されるからWindows10のISOファイルに含まれるinstall.wimを用いようと思っていたらinstall.esdしか見当たらない。どうも.esdファイルの内部に暗号化された.wimファイルが複数格納されているという。したがって必要な.wimファイルをエクスポートする必要がある情勢である。

一先ずISOファイルをマウントし、エクスプローラを起動して確認するとどうやらEドライブに落ち着いた模様である。

そうしたらコマンドプロンプトを管理者として実行しinstall.esdの居るe:\sourcesフォルダへ移動する。

c:\>e:
e:\>cd sources
e:\sources>dir /b install.*
install.esd

dismコマンドでinstall.esdの内容を覗いてみるとWindows 10の各種エディションが揃い踏みであった。

e:\sources>dism /get-wiminfo /wimfile:install.esd

展開イメージのサービスと管理ツール
バージョン: 10.0.16299.15

イメージの詳細: install.esd

インデックス: 1
名前: Windows 10 S
説明: Windows 10 S
サイズ: 16,088,647,927 バイト

インデックス: 2
名前: Windows 10 Home
説明: Windows 10 Home
サイズ: 15,902,243,813 バイト

インデックス: 3
名前: Windows 10 Education
説明: Windows 10 Education
サイズ: 16,086,095,424 バイト

インデックス: 4
名前: Windows 10 Pro
説明: Windows 10 Pro
サイズ: 16,086,813,205 バイト

操作は正常に完了しました。

このうち求めるものはインデックス4であるからこれをエクスポートする。大変時間を要する処理であるから暫しお茶に出掛けるのが良かろうと思う。仕上がった.wimファイルが損なわれていることに気付かないまま作業に取り組むと改めて時間を消費してエクスポートする事態に迫られるから、できるだけ早々に異常を検出するために尚いっそう暇はかかるけれども/checkintegrityオプションも指定しておきたいところである。

e:\sources>dism /export-image /sourceimagefile:install.esd /sourceindex:4 /destinationimagefile:c:\win10pro.wim /compress:max /checkintegrity

展開イメージのサービスと管理ツール
バージョン: 10.0.16299.15

イメージをエクスポートしています
[==========================100.0%==========================]
操作は正常に完了しました。

用心を重ねて.wimファイルが正しくマウントできるか確認するならこういう具合である。

c:\>mkdir mount
c:\>dism /mount-wim /wimfile:c:\win10pro.wim /index:1 /mountdir:c:\mount /readonly
c:\>dism /unmount-wim /mountdir:c:\mount /discard

アンマウントする際にはマウントしたフォルダから予め抜け出しておかないと「エラー: 0xc1420117 ディレクトリを完全にはマウント解除できませんでした。これは通常、アプリケーションがマウント ディレクトリ内のファイルを開いていることが原因です。マウント解除のプロセスを完了するには、これらのファイルを閉じてから、再度マウントを解除してください。」となる。

参考:
Windows 10 のダウンロード
What Is an ESD File?
Convert an ESD File to a WIM File for Driver Updates in Your Windows Image*
DISM イメージ管理のコマンド ライン オプション

15を超えるファイルを選択してもコンテキストメニューが省略されないようにする

OS: Windows 10 ver 1709
Excel 2016

夥しい数のエクセルファイルを一遍に選択して印刷しようと右クリックをしたところ「印刷」のメニューが見当たらない。僅かな数であれば印刷メニューがあらわれるのでこれは閾値が定められていると考えて調べると、デフォルトでは15ファイルまでという設計である。此れを超えると「開く」、「印刷」、「新規」のメニューが省かれるという情勢である。

15個のエクセルファイルを選択したときのコンテキストメニュー
16個のエクセスファイルを選択したときのコンテキストメニュー

この数を操作したいのであれば次のレジストリを作成、編集するとよいようである。

HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer
Name : MultipleInvokePromptMinimum
Type : DWORD

コマンドプロンプトから一息に操作してしまうならこういう具合である。このあとエクスプローラを再起動すると反映された。

>reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer" /v MultipleInvokePromptMinimum /t REG_DWORD /d 16 /f

10進数で16以上の値を放り込むとファイルの選択数に依らずコンテキストメニューがかいつまんで表示されることは無くなった。一方で操作できるファイルの数はこのレジストリの値にどうしても制限されるようである。MultipleInvokePromptMinimumに20をセットしたとすれば、ファイルを100選択してもメニューに「印刷」は表示されるけれども実際には1ファイル印刷して終いであった。なんと素直でない作りであるなとおもったけれども手も足も出ない。

参考:
Context menus are shortened when more than 15 files are selected