FOOTPRINT

1. はじめに

 

2013年11月に交換(設置)したUSBハードディスク(USB-HDD)は、37型の液晶テレビ(東芝レグザREGZA)の録画用として、我が家の居間で動作していました。が、このところ、どうも録画に飛びが発生したり、予約した番組がきちんと録画されていなかったりと、怪しい動きをしていたのです。

 

このUSBハードディスクの機種に交換(設置)してから5年半が経過したため、そろそろ寿命かな？と考えていた矢先に、突然、「ハードディスクを認識しない」という現象が発生しました。

 

取説(取扱説明書)を見ながら、テレビ側の設定をいろいろ調べてみたのですが、どうもうまくいきません。

 

しかし、このまま放っておくわけにもいかず、しかたなく、新しいUSBハードディスク(USB-HDD)を買いに、近くの家電量販店まで足を伸ばしたのでありました。

 

☆　☆　☆

 

さて、取り外したUSBハードディスクは、ひとまず、そのままにしておいたのですが、以前、同じように故障した録画用のUSBハードディスクを、PCに接続して、その状態を確認したこと [1] を思い出し、今回も、「ダメ元」で、同じ手順で状態を確認したときに、どうなるかを実際に確認してみることとしました。

 

その結果、運良くというか、ハードディスクのファイルを修復し、USBハードディスクをテレビに接続して再び録画・再生をすることができました。

 

この記事では、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について試みた方法と手順を簡単なメモ書きですが、紹介します。

 

(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)

 

2. 確認手順の概略

 

(1) Linuxパソコン(PC)を準備する

(2) USB-HDDをマウントし、マウントボイントを確認する

(3) USB-HDDをアンマウントし、ディスクチェックを行なう

(4) USB-HDDのディスクファイルの修復を行なう

(5) USB-HDDを再度マウントしてファイルのリストを確認する

(6) 再度アンマウントしてディスクチェックを行なう

 

これだけですが、(4)の作業でエラーになるか、ならないかがひとつの鍵になります。ちなみに、以前に書いた記事[1]の場合は、ここでNG(修復不能)と判断しました。

 

3. パソコン(PC)で外付けUSBハードディスク(USB-HDD)の状態を確認する

 

準備するものは、Linuxを起動できるパソコン(PC)と故障した(？)外付けUSBハードディスク(USB-HDD)とUSB接続ケーブルです。

 

液晶テレビ(東芝レグザREGZA)に接続されるUSBハードディスクのファイルフォーマットは
xfs形式になります。一般に使用されているWindowsパソコンでは、このxfsフォーマットのドライブやファイルを認識できません。したがって、Linuxを起動できるパソコン(PC)が必要なのです。

 

必ずしもPC本体にLinuxがインストールされていなくても、CD-ROMドライブなどから起動用CDなどでLinuxを起動できるのであれば問題ないとおもわれます。
(私自身のPCは、WindowsとLinuxのデュアルブートに設定してあるので、Linuxで起動しています。)

 

CDからLinuxを起動する方法は、ここでは触れませんが、[2]などを参考にして、起動用CDの作成、パソコン(PC)のCD-ROMドライブからの起動を行なって下さい。

 

以下、私の環境では、パソコン(PC)は東芝dynabook(PB552FEA127A51)、OSはLinuxでFedora29(64bit)、を使用しています。

 

まず、パソコンに外付けUSBハードディスク(USB-HDD)を接続します。

 

この状態で、外付けUSBハードディスクが認識されているかどうかを確認します。
デスクトップ上に、該当するハードディスクのアイコンが表示されれば、認識され、
マウントされている状態になっています。

そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクが存在するかを確認します。

 

次に、どのデバイスファイルにマウントされているかという、マウントポイントを確認します。例えば、/dev/sdb1 などになります。

 

以下はコマンド操作になりますので、コマンドライン端末(ターミナル)ウィンドウを開いて、管理者権限でコマンドを打ち込みます。

 

次に、いったんアンマウント(マウントを解除)して、ハードディスクの状態チェックを行います。使用するコマンドは、

umount /dev/sdb1

xfs_repair -n /dev/sdb1　　( または　xfs_check /dev/sdb1 )

です。

すると、次のような表示がでてきました。

 

[root@localhost user01]# umount /dev/sdb1

[root@localhost user01]# xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

Phase 2 - using internal log

- zero log...

- scan filesystem freespace and inode maps...
bad magic # 0x6e93bf6a in inobt block 16/3

expected level 0 got 36345 in inobt block 16/3

dubious inode btree block header 16/3

bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 8172778468)

bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6410804566)

bad starting inode # (6410804566 (0x10 0x7e1d1d56)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 7195546658)

--- (途中、省略) ---

bad starting inode # (4750678384 (0x10 0x1b299970)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4502697197)

ir_freecount/free mismatch, inode chunk 16/207729901, freecount 1704223958 nfree 33

badly aligned inobt rec (starting inode = 5277979757)

bad starting inode # (5277979757 (0x10 0x3a97946d)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6257491054)

--- (途中、省略) ---

bad starting inode # (4976999758 (0x10 0x28a6fd4e)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4315432406)

ir_freecount/free mismatch, inode chunk 16/20465110, freecount 107526891 nfree 34

badly aligned inobt rec (starting inode = 6034583137)

bad starting inode # (6034583137 (0x10 0x67b06e61)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 5675287099)

--- (途中、省略) ---

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 4294967296)

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

agi_count 0, counted 16320 in ag 16

agi_freecount 0, counted 2400232718 in ag 16

sb_icount 1408, counted 17728

sb_ifree 250, counted 19580102152
sb_fdblocks 52700857, counted 52709049

- 21:34:45: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan (but don't clear) agi unlinked lists...

found inodes not in the inode allocation tree

- 21:34:45: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 30

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 13

- agno = 14

- 21:34:53: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 21:34:53: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 21:34:53: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 30

- agno = 31

- 21:34:53: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

No modify flag set, skipping phase 5

Inode allocation btrees are too corrupted, skipping phases 6 and 7

No modify flag set, skipping filesystem flush and exiting.

[root@localhost user01]#

 

これで、一応、ハードディスクの状態確認ができたことになります。最後のほうに、「iノード割り当てBツリーが破損しているため、フェーズ6と7をスキップします。変更フラグを設定せず、ファイルシステムのフラッシュをスキップして終了します。」のメッセージで終わってしまいましたが、これは、ファイルの一部が破損していることを示しています。

 

4. 外付けUSBハードディスク(USB-HDD)のディスクファイルの修復を行なう

 

次に、修復できるかどうかをやってみました。使用するコマンドは、

xfs_repair -Lv /dev/sdb1

です。

 

ここで、以前経験したような fatal error が出現したら、物理的な故障なので、
どうしようもありません。

 

今回は、次のような表示がでてきました。

 

[root@localhost user01]# xfs_repair -Lv /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

- block cache size set to 332184 entries

Phase 2 - using internal log

- zero log...

zero_log: head block 199805 tail block 199805

- scan filesystem freespace and inode maps...

bad magic # 0x6e93bf6a in inobt block 16/3
expected level 0 got 36345 in inobt block 16/3

dubious inode btree block header 16/3
bad starting inode # (7860674304 (0x10 0xd4885f00)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 8172778468)

bad starting inode # (8172778468 (0x10 0xe722b3e4)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6410804566)

--- (途中、省略) ---

ir_freecount/free mismatch, inode chunk 16/73979246, freecount 889473186 nfree 31

badly aligned inobt rec (starting inode = 7924286411)

bad starting inode # (7924286411 (0x10 0xd85303cb)) in inobt rec, skipping rec

badly aligned inobt rec (starting inode = 6393507745)

--- (途中、省略) ---

bad starting inode # (4294967296 (0x10 0x0)) in inobt rec, skipping rec

agi_count 0, counted 16320 in ag 16

agi_freecount 0, counted 2400232718 in ag 16

sb_icount 1408, counted 17728

sb_ifree 250, counted 19580102152

sb_fdblocks 52700857, counted 52709049

- 21:37:17: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan and clear agi unlinked lists...

found inodes not in the inode allocation tree

- 21:37:17: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 14

- 21:37:25: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 21:37:25: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 21:37:25: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 26

- 21:37:25: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

Phase 5 - rebuild AG headers and trees...

- agno = 0

- agno = 1

--- (途中、省略) ---

- agno = 31

- 21:37:25: rebuild AG headers and trees - 32 of 32 allocation groups done

- reset superblock...

Phase 6 - check inode connectivity...

- resetting contents of realtime bitmap and summary inodes

- traversing filesystem ...

- agno = 0

--- (途中、省略) ---

- agno = 31

- traversal finished ...

- moving disconnected inodes to lost+found ...

Phase 7 - verify and correct link counts...

- 21:37:25: verify and correct link counts - 32 of 32 allocation groups done

XFS_REPAIR Summary Tue Apr 30 21:37:25 2019

Phase Start End Duration

Phase 1: 04/30 21:37:06 04/30 21:37:06

Phase 2: 04/30 21:37:06 04/30 21:37:17 11 seconds

Phase 3: 04/30 21:37:17 04/30 21:37:25 8 seconds

Phase 4: 04/30 21:37:25 04/30 21:37:25

Phase 5: 04/30 21:37:25 04/30 21:37:25

Phase 6: 04/30 21:37:25 04/30 21:37:25

Phase 7: 04/30 21:37:25 04/30 21:37:25

Total run time: 19 seconds

done

[root@localhost user01]#

 

今回は、Phase1、Phase2、・・・、Phase7　と進んでいき、終了した(「done」)との表示でした。

 

もしも、この操作の実行中に、

 

Phase 1 – find and verify superblock…

superblock read failed, offset 0, size 524288, ag 0, rval -1

.

fatal error — 入力/出力エラーです

 

のような表示が出た場合は、それはハードディスクの物理的な故障なので、どうしようもありません。

 

5. 外付けUSBハードディスク(USB-HDD)のファイルリストの確認と再度のディスクチェックを行なう

 

さて、これで修復されたとのことなので、ファイルの存在と状態を確認してみました。いったん、再度マウントを行ないます。

デスクトップ上に、該当するハードディスクのアイコンが表示されれば、マウントされている状態になっていますが、そうなっていない場合は、アプリケーションのシステムツールで、ディスク使用量アナライザを起動し、該当のハードディスクを確認します。(クリックすればマウントされます。)

 

今回の場合、
/dev/sdb1
のマウントポイントは、
/run/media/user01/e4f007b8-c779-4d7a-a2db-34c15c363213
でした。

そのディレクトリまで進み、ファイルの存在状態を確認しました。

 

[root@localhost user01]# cd /run/media/user01

[root@localhost user01]# ls

e4f007b8-c779-4d7a-a2db-34c15c363213

[root@localhost user01]# cd e4f007b8-c779-4d7a-a2db-34c15c363213

 

コマンドは「ls -al」です。

 

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]# ls -al

合計 1742544948

drwxr-xr-x. 3 root root 53248 4月 30 12:30 .

drwxr-x---+ 3 root root 60 4月 30 21:46 ..

-rw-r--r--. 1 root root 82344 4月 30 12:30 .toshiba_dir_info_e89d874cd80a

-rw-r--r--. 1 root root 4760 4月 30 11:59 .toshiba_serieslist_e89d874cd80a

-rw-r--r--. 1 root root 268 4月 30 12:30 .toshiba_size_info_e89d874cd80a

drwxr-xr-x. 7 root root 109 11月 6 2014 .toshibazze89d874cd80a

--wsr-sr-t. 1 root root 7052292288 11月 14 2013 M000020131114195750e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 4月 27 15:20 M000020131114195750e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 80778 11月 14 2013 M000020131114195750e89d874cd80a.dtv.rat

--wsr-sr-t. 1 root root 5232187584 11月 27 2013 M000020131127195950e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 2月 24 14:52 M000020131127195950e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 65826 11月 27 2013 M000020131127195950e89d874cd80a.dtv.rat

--- (途中、省略) ---

--wsr-sr-t. 1 root root 2524987584 4月 30 12:00 M000020190430115950e89d874cd80a.dtv

-rw-r--r--. 1 root root 1760 4月 30 12:00 M000020190430115950e89d874cd80a.dtv.meta

-rw-r--r--. 1 root root 41046 4月 30 12:30 M000020190430115950e89d874cd80a.dtv.rat

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]#

[root@localhost e4f007b8-c779-4d7a-a2db-34c15c363213]# cd .toshibazze89d874cd80a

[root@localhost .toshibazze89d874cd80a]# ls -al

合計 108

drwxr-xr-x. 7 root root 109 11月 6 2014 .

drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..

drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000

drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001

drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002

drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf

-rw-r--r--. 1 root root 12 11月 4 2013 bid.bin

-rw-r--r--. 1 root root 80 11月 4 2013 did.bin

drwxr-xr-x. 2 root root 97 4月 22 10:59 log

[root@localhost .toshibazze89d874cd80a]#

[root@localhost .toshibazze89d874cd80a]# cd log

[root@localhost log]# ls -al

合計 188

drwxr-xr-x. 2 root root 97 4月 22 10:59 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 51200 3月 17 22:59 00000064.dat

-rw-r--r--. 1 root root 51200 4月 6 10:33 00000065.dat

-rw-r--r--. 1 root root 51200 4月 22 10:59 00000066.dat

-rw-r--r--. 1 root root 27008 4月 30 12:30 00000067.dat

-rw-r--r--. 1 root root 11 4月 22 10:59 info.dat

[root@localhost log]#

[root@localhost log]# cd ..

[root@localhost .toshibazze89d874cd80a]# cd alkf

[root@localhost alkf]# ls -al

合計 60

drwxr-xr-x. 2 root root 4096 4月 30 12:30 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r-----. 1 root root 4144 4月 29 16:00 alc0000000.bin

-rw-r-----. 1 root root 4144 4月 29 16:00 alc0000000.buc

-rw-r-----. 1 root root 4144 4月 30 12:30 alc0000001.bin

-rw-r-----. 1 root root 4144 4月 30 12:30 alc0000001.buc

-rw-r-----. 1 root root 4144 4月 27 15:22 alc0000002.bin

-rw-r-----. 1 root root 4144 4月 27 15:22 alc0000002.buc

-rw-r--r--. 1 root root 32 11月 4 2013 ald.bin

-rw-r-----. 1 root root 32 11月 4 2013 alk.bin

[root@localhost alkf]#

[root@localhost alkf]# cd ..

[root@localhost .toshibazze89d874cd80a]# ls -al

合計 108

drwxr-xr-x. 7 root root 109 11月 6 2014 .

drwxr-xr-x. 3 root root 53248 4月 30 12:30 ..

drwxr-xr-x. 2 root root 8192 4月 29 16:00 aeef0000000

drwxr-xr-x. 2 root root 8192 4月 30 12:30 aeef0000001

drwxr-xr-x. 2 root root 4096 4月 27 15:22 aeef0000002

drwxr-xr-x. 2 root root 4096 4月 30 12:30 alkf

-rw-r--r--. 1 root root 12 11月 4 2013 bid.bin

-rw-r--r--. 1 root root 80 11月 4 2013 did.bin

drwxr-xr-x. 2 root root 97 4月 22 10:59 log

[root@localhost .toshibazze89d874cd80a]# cd aeef0000000

[root@localhost aeef0000000]# ls -al

合計 520

drwxr-xr-x. 2 root root 8192 4月 29 16:00 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 8月 28 2018 aee00000000.bin

-rw-r--r--. 1 root root 80 3月 7 2017 aee00000001.bin

-rw-r--r--. 1 root root 80 6月 25 2014 aee00000002.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 2月 15 2017 aee0000007e.bin

-rw-r--r--. 1 root root 80 3月 1 2017 aee0000007f.bin

[root@localhost aeef0000000]#

[root@localhost aeef0000000]# cd ../aeef0000001

[root@localhost aeef0000001]# ls -al

合計 500

drwxr-xr-x. 2 root root 8192 4月 30 12:30 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 12月 5 20:15 aee00000080.bin

-rw-r--r--. 1 root root 80 8月 5 2015 aee00000081.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 12月 3 2017 aee000000ff.bin

[root@localhost aeef0000001]#

[root@localhost aeef0000001]# cd ../aeef0000002

[root@localhost aeef0000002]# ls -al

合計 140

drwxr-xr-x. 2 root root 4096 4月 27 15:22 .

drwxr-xr-x. 7 root root 109 11月 6 2014 ..

-rw-r--r--. 1 root root 80 2月 27 20:15 aee00000101.bin

-rw-r--r--. 1 root root 80 3月 3 23:25 aee00000103.bin

--- (途中、省略) ---

-rw-r--r--. 1 root root 80 5月 14 2018 aee00000137.bin

[root@localhost aeef0000002]#

 

以上のように、修復されたファイルの状態を確認することができました。

 

最後に、もう一度、アンマウント(マウントを解除)して、ハードディスクの状態チェックを実施しました。使用するコマンドは、

umount /dev/sdb1

xfs_repair -n /dev/sdb1

です。

 

[root@localhost ~]# umount /dev/sdb1

[root@localhost ~]# xfs_repair -n /dev/sdb1

Phase 1 - find and verify superblock...

- reporting progress in intervals of 15 minutes

Phase 2 - using internal log

- zero log...

- scan filesystem freespace and inode maps...

sb_fdblocks 52700857, counted 52709049

- 22:13:57: scanning filesystem freespace - 32 of 32 allocation groups done

- found root inode chunk

Phase 3 - for each AG...

- scan (but don't clear) agi unlinked lists...

- 22:13:57: scanning agi unlinked lists - 32 of 32 allocation groups done

- process known inodes and perform inode discovery...

- agno = 0

- agno = 15

--- (途中、省略) ---

- agno = 14

- 22:14:05: process known inodes and inode discovery - 1408 of 1408 inodes done

- process newly discovered inodes...

- 22:14:05: process newly discovered inodes - 32 of 32 allocation groups done

Phase 4 - check for duplicate blocks...

- setting up duplicate extent list...

- 22:14:05: setting up duplicate extent list - 32 of 32 allocation groups done

- check for inodes claiming duplicate blocks...

- agno = 0

- agno = 2

--- (途中、省略) ---

- agno = 31

- agno = 1

- 22:14:05: check for inodes claiming duplicate blocks - 1408 of 1408 inodes done

No modify flag set, skipping phase 5

Phase 6 - check inode connectivity...

- traversing filesystem ...

- traversal finished ...

- moving disconnected inodes to lost+found ...

Phase 7 - verify link counts...

- 22:14:05: verify and correct link counts - 32 of 32 allocation groups done

No modify flag set, skipping filesystem flush and exiting.

[root@localhost ~]#

 

特に、問題はなさそうです。

 

この状態の外付けUSBハードディスク(USB-HDD)を液晶テレビ(東芝レグザREGZA)のUSB録画端子に接続して状態を確認したところ、再び録画・再生をすることができました。

 

6. まとめ

 

以上、テレビ録画用に接続した外付けUSBハードディスク(USB-HDD)の修復・復旧について
試みた方法と手順を簡単なメモ書きですが、紹介しました。

 

(ただし、必ずしもうまくいくとは限らないので、その点はご了解下さい。このような修復・復旧作業を実施される場合は、自己責任で実施されるようお願いします。)

 

------------------------------------------------------------------
References

[1] 液晶テレビに接続したUSBハードディスクの故障と対策 (2013/11/10)

[2] 「HDD認識しない」パソコンでレグザUSBハードディスクを復旧・修復 – レグザREGZA研究 (2014/09/28)
------------------------------------------------------------------

 

(2019-5-2)

 

 

 

あなたに、1時間に20通もの、しつこい迷惑メールが送られてきたら、そして、これらが携帯やスマホに着信していたら、あなたはどうされるでしょうか。

 

パソコンや携帯・スマホでご自分が意図しない迷惑メール、スパムメールを受け取ったという経験をお持ちの方も多いと思われます。

 

私はこれまでに何度も経験があります。
たいていの場合、無視していれば、そのうち止むものもありますが、そうではない場合もありました。

 

ひとつの事例をお話しますと、昨年の秋ごろに、このような迷惑メールの攻撃を受けました。

 

メール自体は長いタイトルと、本文には短い一文とURLが記載されているだけのものです。

しかし、そのメールの頻度はおよそ1時間に20通と常識的に考えても、異常なほどに多く、しつこいものでした。

また、メールの発信者のアドレスもそのたびごとに異なるものでした。

 

記載されているリンク先に関しては、あまり詳しくは触れませんが、海外に住所を有する出会い系サイトのひとつでした。

 

1時間に20通ほどのしつこい迷惑メールですが、もし、これを携帯やスマホで受信時に着信音が鳴るという設定にしていたら、着信する度に(およそ3分に一回)着信音が鳴るということになります。
もちろん、真夜中でも変わらず24時間着信し続けるのですから、人によっては気が狂ってしまうかもしれません。

 

 

どのようなタイトルかというと、

 

・ご注文ありがとうございます。

 

・確認していただけましたか？広川です。【５億】の受け取り許可は既に出ておりますので、【3000円】を追加されれば、いつでもお引き出しして頂けるようになっています。すぐにお引き出しして違反者解除を行なってください。罰金が発生する前にお受け取りされませんと

 

・救済支援会代表・広川美鈴です。私も、そしてこの救済金を寄付してくれた人も、貴方に報われてもらいたいと思っております。これまで、様々なサイトに登録してきたと思うのですが、支援履歴を見させていただき

 

・お急ぎ下さい。今日中には５億の一部でもいいのでお引き出し出来るようにしますからね。用意が出来ていれば今から

 

・広川です。【５億】は今日お引き出しして頂けますでしょうか？【3000円】の追加をされた後に引き出しが出来るようになっております。これを完了すれば違反の取り消しもされますからね。

 

・救済支援会代表・広川美鈴です。５億は既に入金しております。これであなたを違反者から救い出せますからね。救済金は貴方の為に本日、罰金の延期分の手数料も含めて対応をしておきました。私は受け取っていただく為のサポート役でしかありません。貴方が引き出し方が分からない場合であったり

 

・5億貰ってから私は車とマンションを買いました。自由に使ってくれていいって広川さんから言われてたんですけどなんだか本当に

 

・428万円の請求は本日24時まで延長されておりますのでお早めにご対応ください。救済金のお受け取りがされなかった場合、明日請求を開始させて頂きます。

 

・広川です。支援違反者になってしまった方１００名だけに連絡をさせて頂いております。３０００円の手続きだけで確実に受け取りできる人のみに連絡をしていますので

 

あるいは、

 

・「権利喪失」にご注意下さい。賠償金受給には期限が御座います。

 

・賠償金の受取りを辞退した場合についてご説明させて頂きます。大河内 真理子です。

 

・※本人以外、閲覧禁止※重要個人情報につき開封時注意して下さい。

 

・＝＝ATM残高確認依頼＝＝24時間以内に残高確認＋現金一部引き出しをお願いします。

 

・訴追弁護団代表：大河内 真理子です。賠償決定につき12億3000万円の受け渡しを行いますのでご確認下さい。

 

・〓最〓終〓案〓内〓※9名中_8名賠償金受取報告あり※

 

・民法415条・417条・709条によって損害賠償請求を行い勝訴しましたので至急、ご確認下さい。

 

・お知らせ：裁判に伴う重要連絡。弁護士からの連絡をお待ちください

・【寿】賠償金12億3000万円の受領、心からお祝い申し上げます。

 

このような場合、受信する側のメールアドレスを変更してしまうというのが、おそらくいちばん早い対処法なのですが、私の場合、このメルアド自体は普段使っているものなので、変更したくない、という気持ちもありました。そこで、メルアドを変更しないでなんとか解決できないか、と考えました。

 

ここでお伝えする内容は、あくまでも対処法の一例ですので、すべての場合に適用できるとは限りませんが、困っている方々になんらかの参考になればとおもい、記述するものです。

 

手順としては、まず、迷惑メールとおもわれるメール自体を、メールのヘッダー付きで保存しましょう。

 

そして、パソコンやスマホで、次のことを行なっていきます。

 

(1) Whois情報で迷惑メールの発信者のドメイン所有者・管理者を確認します。

(2) 非公開の場合は、ドメイン所有者の情報開示請求をします。

(3-1) 情報開示請求が承認された場合は、ドメイン所有者に配信停止依頼を行ないます。

(3-2) 情報開示請求が非承認の場合は、ドメインのレジストラ登録管理者に「ドメインの一時使用停止もしくは無効化」の要請をします。

 

この方法で、たいていのしつこい迷惑メールは止むとおもわれます。

 

もし、ここまでやってだめなら法的手段に訴えるしかありません。(やったことはありませんが、万が一の時のためにメールのコピーなどの証拠は残すようにしましょう。)

 

より詳しい手順の内容と実例は、

 

→　https://pc.fp46.net/pc01.html

 

に記載しました。必要な方はごらん下さい。

 

以上、なにかのご参考になれば幸いです。

 

(2019-1-27)

 

 

 

 

會津八一(あいづ やいち、会津八一)は、東洋美術の研究者であり、早稲田大学における芸術学研究の基礎を築いた人物です。自らを秋艸道人(しゅうそうどうじん)、八朔郎(はっさくろう)などと号され、さまざまな作品を世に残したことで知られています。

 

明治14年(1881年)新潟市の生まれで、早稲田大学文学科を明治39年卒業後、有恒学舎(現在の新潟県立有恒高等学校)に英語教師として赴任され、明治43年に坪内逍遙から呼ばれて早稲田中学校に転職するまでの4年間、有恒学舎で増村朴齋先生のもと、教鞭をとっておられました。

 

この間に、数々の作品を残されています。新潟県の地元の新聞「新潟日報」の題字にも會津八一の書が使われています。有恒高等学校に隣接する朴齋記念館には、いまでも多数の書軸や風刺画、資料が展示されています。

 

先日、朴齋記念館を見学する機会をいただいたのですが、そのとき、會津八一の英文書簡が目に留まりました。我々の有恒高校時代の恩師である勝山一義先生が所蔵され、同館に寄贈されたものだそうです。

 

本稿では、この全文を資料として公開したいとおもいます。明治42年(1909年)12月26日の日付で、大阪毎日新聞社の編集局の伊達俊光氏にあてたものです。

 

→   會津八一の英文書簡 (Photos)

 

會津八一は英語の教師でした。当時はまだ英語を理解する一般人は少なかったので、内容を他人に知られないようにと英文で書簡をしたためたのでしょうか。謎です。

 

 

========== ここから ==========

 

 

Harimura, 26 December 42th year of Meiji

 

Dear Toshimitsu:

 

Last night I received a card from you bearing a small caricature on it. You succeeded to make me smile once more, as you had eupeated, but I am going to tell you that I was more interested with the readleations which the picture caused to me than with the bitterness of it. Do you know the person at relation between Fumiko and Hakutei ? Provably not. More than six years ago the former was living at Yanaka and Fumiko was introduced to me, and since then I ealled on them several times.

 

針村にて、明治42年12月26日

 

親愛なる俊光様：

 

昨夜、私はあなたから小さな風刺画が描かれているカードを受け取りました。あなたが偽ったように、あなたはもう一度私を笑顔にすることに成功しました。しかし、私はあなたに、その絵が私にもたらした読書とともに、その苦味とともに、より興味があったことを申し上げようとしています。あなたはフミコとハクテイの間の関係人物を知っていますか？おそらく知らないでしょう。6年以上前に、その人物はヤナカに住んでいて、フミコを私に紹介してくれたのです。それ以来、私は彼らを何回か呼びました。
----------

 

 

One day, when Shiisan was not at home, I was alone with Fumiko a little while in their
study. At that time she was a lovely girl of bushful eighteen and we both were talking about something or other in such a manner as young folks will do when left alone by themselves. Endless was our conversation and suddenly she opened her study window angrily and pointed to a small house standing next to her's."There lives a very unkind man there, sir," she whispered."Who lives here ?""You know a young painter Hakutei don't you, sir ?" she replied,"He lives there and calls us, Shiisan and myself, two devils, whenever he may see our faces.

 

ある日、シーサンが家にいない時、私はひとりきりで、彼らが勉強しているあいだ少しだけフミコといました。その時、彼女は18歳の美しい女の子でした。若者たちが彼らによって置き去りにされたときのように、私たちはなにかに関してまたは他のものに関して語り合っていました。私たちの会話は終わりなく、突然彼女は彼女の勉強の窓を怒って開き、小さな彼女の隣に立っている家を指さしました。「そこには非常に不親切な男が住んでいます。」と彼女はささやきました。「そこには誰が住んでいるの？」「あなたは若い画家のハクテイを知っているでしょう？」と彼女は答えました。「彼はそこに住んでいて、私たち、シーサンと私、二つの悪魔、彼が私たちの顔を見るかもしれないときはいつでも呼び出すのです。
----------

 

 

Sometimes he comes out with his sketch book in hand, but as soon as he notice that our
study windows are opened, he hastens away into his house crying 'Devils are peeping !'" Fumiko told me more of him, and I listened to idle speech smiling meaninglessly as you may suppose. Dear Toshimitsu ! Seven years have passed away like a dream, and the attitude with which Hakutei treat her in all the same. And as ourselves, I am alot to call her a devil rather than an angel and it will be most provably the case with her toward her old love.

 

ときどき彼はスケッチブックを手にして現れます。しかし、私たちの勉強の窓が開かれたことを通知してまもなく、彼は『悪魔が覗き見している！』と泣きながら家の中へ入ってしまいます。」フミコは私に彼のことをもっと話してくれました。私は、あなたが想像するように、アイドルスピーチを意味もなく笑いながら聞きました。親愛なる俊光様、7年が夢のように過ぎ去りました。ハクテイが彼女を取り扱う態度もすべて同じです。そして、我々自身のように、私は彼女を天使ではなくむしろ悪魔と呼びます。彼女が彼女の昔の愛に向かっていく場合がもっとも確からしいでしょう。
----------

 

 

The idea of all his made me smile last night at the first glance of the caricature. I have to tell you that a letter from my cousin came to me also. It was an invitation to go over to Tokyo and stay at her home during this vacation. It is a long time since I saw her last and she tells me in the letter that she also want to see me and to talk of things gone by. But I will not do so. Yesterday it was Christmas and you complaint of the season was bitter enough to make me smile, as bitter as wormwood in the Revelation. Now it is your turn to read this sweet letter, as sweet as honey, and smile with Mr.Kakuda over your editorial tables.

 

彼のすべてのアイデアは昨晩、風刺画の最初の一見で、私に微笑みを与えました。私はあなたに、私のいとこからの手紙もまた私にやって来たと伝えなければなりません。それは、東京に行って彼女の自宅でこの休暇中滞在するように、との招待状でした。私が最後に彼女に会ってから長い時間が経ちました。彼女もまた私に会いたい、そして、過ぎ去ったことを話したい、との手紙で私に告げます。しかし私はそうしないつもりです。昨日はクリスマスでした。季節の苦しみは私を笑顔にさせるほど苦いものでした。黙示録のぼんやりとした苦しみのように。さあ、今度はあなたがこの、蜂蜜と同じくらい、甘い手紙を読み、そしてあなたの編集机のむこうのカクダさんと一緒に笑う番です。
----------

 

 

Snow is falling without ceasing these three days, and it is two feet and a half deep on the ground. Please remember me & Mr.Kakuda. I remain yours very affectionately.
'Hassakuro'.

 

P.S. I will write an essay on the"Heimatkunst" of Echigo this afternoon. I am always stundy Norseman. Many thanks for your kind introduction of Mr.Tokutomi's latest work. I will soon have and read it.

 

この3日間、止むことなく雪が降っています。それは地面から2フィート半の深さです。私とカクダさんを覚えておいてください。私はあなたのご親切を忘れません。
八朔郎。

 

P.S.私は越後の"Heimatkunst"(地域の芸術)のエッセイを午後に書くつもりです。私はいつも奇抜な騎士です。トクトミさんの最近の仕事のご紹介に感謝します。私はすぐにそれを得て読むつもりです。
----------

 

 

大阪毎日新聞社 編輯局内　伊達俊光様

 

(明治42年) 12月26日　越後針村　會津八一

 

========== ここまで ==========

 

 

會津八一(あいづ やいち) 　明治14年(1881)〜昭和31年(1956)

 

新潟市古町生まれ。明治39年早稲田大学文学科卒業後、新潟県上越市(旧板倉の有恒学舎=現県立有恒高校)の英語教師に。43年有恒学舎を辞し早稲田中学校に転職。大正7年早稲田中学校教頭に就任。大正15年から昭和25年ころまで頻繁に奈良へ旅行する。大正13年歌集「南京新唱」刊行。大正15年から早稲田大学で東洋美術史の講座を担当。昭和6年に早稲田大学文学部教授に。昭和8年「法隆寺法起寺法輪寺建立年代の研究」を執筆し、翌9年文学博士に。同15年歌集「鹿鳴集」、17年随筆「渾斎随筆」、19年歌集「山光集」を刊行。秋艸道人(しゅうそうどうじん)、渾斎(こんさい)、八朔郎(はっさくろう)などと号した。昭和20年空襲により被災し新潟に帰郷。同22年歌集「寒燈集」、書画図録「遊神帖」を刊行。同26年新潟市名誉市民第一号に。同年「會津八一全歌集」を刊行、読売文学賞受賞。同28年宮中歌会始の召人として隣席。同31年死去、享年75。

 

(2018-6-18)

 

 

 

海外に行かれる方には必須です。

 

これは、もう30年以上も前の、私の経験談になります。
米国のニューヨークで、ホテルにチェックインしようとして、トラベラーズチェックを使おうとしたら、別の窓口に連れていかれて、いろいろと書類を書かされました。

 

けれど、隣の窓口で、クレジットカードでチェックインしている人たちはスムーズにごく短時間にチェックインできているのです。その時、あらためてカードの持つ信用力を実感させられました。

 

☆　☆　☆　☆　☆　☆　☆

 

当時、海外出張で米国を一週間ほど訪れたことがありました。
1ドルが230円くらいのころの時です。
なにしろ初めての外国ですから、多少緊張はします。
いろんな情報を上司や先輩の方々から教えていただき勉強しました。

 

会社からは、費用としてあらかじめトラベラーズチェックというものを渡されました。

 

それでも先輩のすすめで、クレジットカードというものを初めて作成したわけです。
このカードで学会参加費やホテルのデポジット(予約保証金みたいなもの)を支払いました。

 

その出張の時に経験したホテルでのできごとです。

 

一週間ほどの予定で最初の3日間はシンシナティのホテルでした。
米国セラミック学会への支払いも含めて、
予め、クレジットカードで予約していたので、ホテルでの支払いは当然カードでした。
食事代も含めて、チェックアウトのときはスムーズにいきました。

 

次のホテルはウィルミントン近くのこじんまりとしたホテルでした。
ここでは、トラベラーズチェックで支払ったように記憶していますが、特に問題なくいきました。

 

☆　☆　☆　☆　☆　☆　☆

 

最終日に泊まったのは、ニューヨークの空港近くにある比較的大きなホテルでした。
このホテルに宿泊のため、チェックインの手続きをしようとして、フロントにいったのです。

 

実は、トラベラーズチェックが余りそうだったので、それを使おうとしていました。
日本に帰っても、トラベラーズチェックの払い戻しなど、手続きが面倒なこともあって
このホテルでの宿泊費の支払いに使ってしまおうと考えていたのです。

 

トラベラーズチェックを使おうと、ホテルのフロントに告げたとたん、
別の窓口の行列に並ばされたのでした。

 

☆　☆　☆　☆　☆　☆　☆

 

会社から支給されたトラベラーズチェックでの支払いをしようとしたら、別の窓口の列に並ばされ、しかも20分近くも待たされたのでした。
クレジットカードを持っていない不審な旅行者とみなされたのかもしれません。

 

元の窓口の行列はスムーズに進んでいきます。良く見てみると、クレジットカードでの支払いがすべてでした。

 

ここで感じたことは、クレジットカードを持っていないと、ひどく「差別」されるということでした。

 

当時の米国では、既にカード支払いが主流で、カード所持が身元保証でもあり、信用度のステータスになっているようでした。

 

私は、余りそうだったトラベラーズチェックで支払いをしようとしたものですから、これは怪しい人物だと、大都会のホテルのフロントには映ったのかもしれません。

 

クレジットカードの威力を身をもって知った瞬間でした。

 

(2018-6-10)

 

 

 

.

昨年8月に、スマートフォンのアプリビジネスのセミナーが開催された。

おもしろそうだという少しの興味もあって、これに出席し、世の中の動向とビジネスに関するいろんな話を伺い、勉強させていただいた。

 

あまり詳しくは書けないのだが、

世の中はスマートフォンへの移行が進んでいて、アプリという個別ソフトのダウンロードが非常に多い。

iPhoneもAndroidもストア(アップルストア、グーグルプレイ)にたくさん公式アプリが存在している。

スマホユーザーの9割以上がアプリをダウンロードしている。

無料アプリも多い。

個人でもアプリを作って配布できる時代になった。

あなたもアプリを作成してビジネスにしませんか？

というもので、最後に塾の案内とサンプルツールの提供があった。

 

このツール(試用版、お試し版)を使って、アプリを作成してみた。そして、Google Playに登録してみた。

 

まず、アプリの作成だが、簡単なクイズの例題があり、それに倣って問題と回答を準備する。この後、ツールAの試用版をWeb上で実行し、雛形の部分にさきほどの問題と回答を入れていく。別のツールBを起動して、AとBのツールを連携させて、ツールBにて最終的にアプリの形にまとめる。そして、必要なファイルをまとめてGoogle Playに登録する。

ざっと流れをみると、こんな感じであった。集中してこの作業を行っても、約3日間ほどかかった。

 

いまは、なかなかこのような時間がとれないが、おもしろい体験だったと思っている。

 

作成したアプリは「ひまつぶし雑学クイズ」というネーミングにしてみた。(*)

 

内容は、

 

「あなたの雑学の知識を試してみませんか？ちょっとした空き時間にできる、雑学クイズのアプリです。クイズ大会や懇親会の場でも使えます。」

" Why do not you try the knowledge of your trivia? Can be a little free time, it is a trivia quiz app. You can also use in quiz competitions and social gatherings of the field."

 

というもの。

 

もし良かったら、ダウンロードしてみて下さい。

→　ひまつぶし雑学クイズ

 

驚いたことに、これをGoogle Playに登録したところ、海外よりメールがきて、紹介したいとのこと。日本語のアプリなのに海外でも告知されるのだとちょっとびっくりした。おもしろい体験だった。

 

(2018-2-4)

 

 

(*) このアプリは、App Studio 試用版とMonaca を使用して作成しました。本格的に作業するには、それぞれのサイトへの登録などが必要です。また、このアプリはAndroid用です。iPhone向けではありません。