C:\Windows\Tempにイベントログファイルが作成される。

C:\Windows\Tempにイベントログファイルが作成され、C:ドライブの空き容量が無くなる。

設定→システム→記憶域で見ると一時ファイルが多くの容量を使用しているが、一時ファイルの内容を確認してみると明細の合計が、一時ファイルで使用している容量よりもはるかに小さい。また一時ファイルの削除を行ってもC:ドライブの空き容量が回復しない。

実際に何処のフォルダにファイルが作成されて居るのか確認したところ、C:\Windows\Tempフォルダに大量のファイルが作成されて居ることを確認できた。どうやらC:\Windows\Temp以下のフォルダは自動では削除されないらしい。

本来ならイベントログファイルはC:\Windows\System32\winevt\Logsに作成される。検索してみたところ”Low Disk Space error due to a full Temp folder“が見つかった。どうもWindows UpdateやMicrosoft Storeの障害にともなう不具合のようである。上記の手順でトラブルシュート後にWindows Updateを適用する事で解決した。

C:\Windows\Tempにイベントログファイルが作成される。

C:\Windows\Tempにイベントログファイルが作成され、C:ドライブの空き容量が無くなる。

設定→システム→記憶域で見ると一時ファイルが多くの容量を使用しているが、一時ファイルの内容を確認してみると明細の合計が、一時ファイルで使用している容量よりもはるかに小さい。また一時ファイルの削除を行ってもC:ドライブの空き容量が回復しない。

実際に何処のフォルダにファイルが作成されて居るのか確認したところ、C:\Windows\Tempフォルダに大量のファイルが作成されて居ることを確認できた。どうやらC:\Windows\Temp以下のフォルダは自動では削除されないらしい。

本来ならイベントログファイルはC:\Windows\System32\winevt\Logsに作成される。検索してみたところ”Low Disk Space error due to a full Temp folder“が見つかった。どうもWindows UpdateやMicrosoft Storeの障害にともなう不具合のようである。上記の手順でトラブルシュート後にWindows Updateを適用する事で解決した。

.NET COREでLinuxで動作するサービスを作成する

.NET Core + C#でLinuxのDeamon作れないかなと思ったら、思ったより簡単に作れるようになっていたので覚え書き。Program.csとDaemonService.csの中味はほぼ定型なのでサンプルからそのまま流用します。

以下のサンプルは.NET Core 3.1で記述しています。

// Program.cs

using System;
using System.Threading.Tasks;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;

namespace DaemonSample
{
    class Program
    {
        public static async Task Main(string[] args)
        {
            var builder = new HostBuilder()
                .ConfigureAppConfiguration((hostingContext, config) =>
                {
                    config.AddEnvironmentVariables();

                    if (args != null)
                    {
                        config.AddCommandLine(args);
                    }
                })
                .ConfigureServices((hostContext, services) =>
                {
                    services.AddOptions();
                    services.Configure<DaemonConfig>(hostContext.Configuration.GetSection("Daemon"));

                    services.AddSingleton<IHostedService, DaemonService>();
                })
                .ConfigureLogging((hostingContext, logging) => {
                    logging.AddConfiguration(hostingContext.Configuration.GetSection("Logging"));
                    logging.AddConsole();
                });

            await builder.RunConsoleAsync();
        }
    }
}
// DaemonService.cs

using System;
using System.Threading;
using System.Threading.Tasks;
using Microsoft.Extensions.Hosting;
using Microsoft.Extensions.Logging;
using Microsoft.Extensions.Options;

namespace DaemonSample
{
    class DaemonService : IHostedService, IDisposable
    {
        private readonly ILogger _logger;
        private readonly IOptions<DaemonConfig> _config;
        public DaemonService(ILogger<DaemonService> logger, IOptions<DaemonConfig> config)
        {
            _logger = logger;
            _config = config;
        }

        public Task StartAsync(CancellationToken cancellationToken)
        {
            _logger.LogInformation("Starting daemon: " + _config.Value.DaemonName);
            _logger.LogInformation("arg1:{0}", _config.Value.arg1);
            _logger.LogInformation("arg2:{0}", _config.Value.arg2);

            // ここでサーバー本体の処理をTaskとして起動します。

            return Task.CompletedTask;
        }

        public Task StopAsync(CancellationToken cancellationToken)
        {
            _logger.LogInformation("Stopping daemon.");
            return Task.CompletedTask;
        }

        public void Dispose()
        {
            _logger.LogInformation("Disposing....");
        }
    }
}
// DaemonConfig.cs

using System;
using System.Collections.Generic;
using System.Text;

namespace DaemonSample
{
    class DaemonConfig
    {
        public string DaemonName { get; set; }
        public string arg1{ get; set; }
        public string arg2{ get; set; }
    }
}

起動時のコマンドラインは下記の通り。コマンドライン引数の受け渡し方が非常に独特です。

/usr/bin/dotnet run --project deamonsample --configuration Release --Daemon:DaemonName="Sample Daemon" Daemon:arg1="argument 1" Daemon:arg2="argument 2"

Demonとして起動するにはsystemdを使用します。/etc/systemd/systemにdeamonsample.serviceファイルを作成し、下記の様に記述します。

[Unit]
Description=deamon sample
After=network.target

[Service]
ExecStart=/usr/bin/dotnet run --project atozipsrv --configuration Release --Daemon:DaemonName="deamonsample " Daemon:arg1="argument 1" Daemon:arg2="argument 2"
WorkingDirectory=/usr/src/deamonsample
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=atozip
Environment=DOTNET_CLI_HOME=/var/src/deamonsample

[Install]
WantedBy=multi-user.target

後は通常のsystemdのDeamon同様に以下のコマンドで起動します。

$ systemctl start deamonsample

参考:Creating a Daemon with .NET Core (Part 1)

Excelのパスワードを解除する方法

Excelのパスワードを解除する裏技を求めて、当WEBに来る方が少なくない。 「ブックの保護を強制的に解除する」は保護をすることで安全に隠せている気になっている記事への警告の意味で書いたので、パスワードが分からなくて困っている人へと補足情報を載せておこうと思う。

避けては通れない法律的な話し

まず法律的なことを覚えておいて欲しい。

何らかの方法でパスワードを調べたり、調べたパスワードを保管したりする行為は「不正アクセス行為の禁止等に関する法律」に抵触し、刑事罰の対象となる。例えファイルの中味を閲覧しなかったとしても、パスワードを調べたり、保管しているだけで処罰の対象となる。

裏技などを使ってパスワード(技術的利用制限手段)を迂回したりする行為は「著作権法」に抵触し、これまた刑事罰の対象となる。 著作権侵害の多くは親告罪だが、技術的利用制限手段の回避は非親告罪となる。

また裏技をつかってパスワード (技術的利用制限手段) を迂回するためのツールを提供する行為は「不正競争防止法」に抵触する。平成30年からはツールを提供するだけではなく、依頼を受けて役務を提供する事も処罰の対象となる。

以上のような法律があるので、いくら探しても「パスワードを解除して欲しい」という依頼を受けてくれる人は見つからない。Excelのファイルを解析してパスワードを解除するようなツールも見つからない。仮に技術的かつ予算的に可能であっても、家族や親友からの依頼でも無い限り、リスクが大きすぎて受けられないのだ。

とはいえ、パスワードが分からなくて途方に暮れている様もよく分かる。解決方法はただひとつしかない。技術的な知識と、法律的な知識を自ら身につけ、自らの手で作業するしかないのだ。

裏技による迂回方法

ブックやシートの保護パスワードや、VBAのソースコード閲覧パスワードなどは裏技的な方法で解除できる。実際に解除する方法は「Excel の各種パスワードを突破する方法まとめ」に良くまとまっている。新たに追記することはしない。

読み取りパスワードの解除

読み取りパスワードだけは総当たりで解除するしかない。だが、辞書に載っているような単語だけであるとか、あるいは6~7文字程度のパスワードであれば、解除できなくもない。

パスワードの解析によく使われるのは「John the Ripper password cracker」と言うツールだ。

私の使っている20万程度のパソコンでもGPUを使うと3,000パスフレーズ/秒程度のスピードで解析を進めてくれる。英数だけで構成される5文字程度のパスワードなら、最悪でも60時間程度で解析が終わる計算になる。辞書に載っているような単語、十万語程度を対象とするならば、数分で終わってしまう。

最高スペックのGPUを使うなら1桁程度は早くなる。IaaSで高速なサーバを複数台レンタルするなら2桁程度は早くなる 。6文字程度のパスワードなら総当たりでも 数日程度で 割り出すことが出来るし、そのために発生する費用は10万円にもみたない。

Postscript #1

そんな分けだからパスワードの分からなくなったファイルのことはキッパリと諦めて、ファイルをゼロから作り直すことを第一選択肢として考えたほうが良い。

Postscript #2

いまどき7文字程度のパスワードしか設定していないのは、実効性が無いので止めておいたほうが良い。無駄な仕事を増やしているだけに過ぎない。

Access Runtimeをインストールしようとしたら32bit版も64bit版もエラーになる

Access Runtime 2016 64bit版のインストールを行おうとすると「次の32ビットバージョンのOfficeプログラムががインストールされているため、64ビットバージョンのOfficeはインストールできません:Office 16 Click-to-Run Extensibility Component」とのエラーになる。

この環境は32bit版だったかと思い直し、 Access 2016 Runtime 32bit版のインストールを行おうとすると 「次の64ビットバージョンのOfficeプログラムががインストールされているため、32ビットバージョンのOfficeはインストールできません:Office 16 Click-to-Run Extensibility Component」とのエラーになる。

・・・どうしろとorz

Access Runtimeインストールの基本制約

Office 2016(2019にも)にはClick-to-Runインストール版 (以下C2R版) とMSIインストール版(以下MSI版)がある。ライセンス上はどちらをインストールしても構わないが、それぞれインストール方法が異なる。プレインストールの場合、昔はMSI版が多かったが、最近は C2R版が入って居ることが多い。そしてC2R版とMSI版には、それぞれ32bit版と64bit版がある。

Access RuntimeにもC2R 版とMSI版がある。C2R版はOffice 365 Access Runtimeと言う名称で、MSI版はAccess 2016 Runtime (ないし2019)と言う名称で提供されており、それぞれ32bit版と64bit版がある。

Access RuntimeをインストールするにはC2R版かMSI版か、32bit版か64bit版かの区分が完全に一致している必要がある。さらにMSI版の場合には2013と2016、2019は混在できないのでバージョンを統一する必要がある。

過去にプレインストール版が入っていた

当該環境はプレインストール版(C2R版)でインストールされていたため、アンインストールしてMSI版を入れ直していた。だが、どうもC2R版の残骸が残ってしまっているのが原因のようである。

アンインストールが完全に行われていないためにトラブルが発生することが度々あるようで、Microsoftのホームページに完全にアンインストールするための方法が書かれている。

PC から Office をアンインストールするの「オプション 2 – アンインストール サポート ツールを使用して Office を完全にアンインストールする」に従って、アンインストール補助用の実行プログラムをダウンロードして、実行することで残骸も含めて消せるようである。無論現在インストールされているMSI版も含めてアンインストールされてしまうのであろうけど・・・

余り褒められた話しではないが、作業時間も押してきているので、Access Runtime 2010のインストールでお茶を濁してしまった。でも恐らくは上記手順でOffice 2016の残骸を削除すればインストール出来るものと思われる。

Linux上のClosedXMLで画像データを扱うときにSystem.DllNotFoundExceptionが発生する

Linux(Ubuntu 18.04)環境に.NET Core SDK 2.2をインストールし、ClosedXmlで画像を含むExcelファイルを扱おうとしたところ、下記の様な例外が発生して実行出来ません。

System.TypeInitializationException: The type initializer for 'Gdip' threw an exception. ---> System.DllNotFoundException: Unable to load shared library 'libdl' or one of its dependencies. In order to help diagnose loading problems, consider setting th
 e LD_DEBUG environment variable: liblibdl: cannot open shared object file: No such file or directory at Interop.Libdl.dlopen(String fileName, Int32 flag)
     at System.Drawing.SafeNativeMethods.Gdip.LoadNativeLibrary()
     at System.Drawing.SafeNativeMethods.Gdip..cctor()
     --- End of inner exception stack trace ---
     at System.Drawing.SafeNativeMethods.Gdip.GdipLoadImageFromDelegate_linux(StreamGetHeaderDelegate getHeader, StreamGetBytesDelegate getBytes, StreamPutBytesDelegate putBytes, StreamSeekDelegate doSeek, StreamCloseDelegate close, StreamSizeDelegate size, IntPtr& image)
     at System.Drawing.Image.InitFromStream(Stream stream)
     at ClosedXML.Excel.Drawings.XLPicture..ctor(IXLWorksheet worksheet, Stream stream)
     at ClosedXML.Excel.Drawings.XLPictures.Add(Stream stream)
     at ClosedXML.Excel.XLWorkbook.LoadDrawings(WorksheetPart wsPart, IXLWorksheet ws)
     at ClosedXML.Excel.XLWorkbook.LoadSpreadsheetDocument(SpreadsheetDocument dSpreadsheet)
     at ClosedXML.Excel.XLWorkbook.LoadSheets(Stream stream)

.NET Core Runtimeインストール時に依存関係が処理されていないことが原因です。下記のコマンドを実行してGDI+関連のライブラリをインストールすると解決します。

sudo apt install libc6-dev 
sudo apt install libgdiplus
cd /usr/lib
sudo ln -s <a rel="noreferrer noopener" target="_blank" href="http://libgdiplus.so/">libgdiplus.so</a> gdiplus.dll

環境によってはLD_LIBRARY_PATHの設定も必要になるようです。

ASP.NET COREを使ったWEBサービス作成(習作)

習作としてASP.NET COREを使用したWEBサービスを作成してみた。
もちろんLinux(Ubuntu 18.04)上で動作している。

Excelファイルをアップロードすると、適当な文字列部分をバーコード画像に置き換えてくれる。

https://barcode.code-lab.net/

expdpで「ORA-31634: ジョブはすでに存在します」になる

Oracleのバックアップにexpdpを使用している。expdpを実行したところ「ORA-31634: ジョブはすでに存在します」と「ORA-31664: デフォルト設定時に一意のジョブ名を構成できません」と見慣れないエラーが表示される。

以下のSQLでDATAPUMP_JOBSにあるジョブ名を確認する。

> select * from DBA_DATAPUMP_JOBS ORDER BY JOB_NAME
>
> OWNER_NAME JOB_NAME OPERATION JOB_MODE STATE DEGREE ATTACHED_SESSIONS DATAPUMP_SESSIONS
> SYSTEM SYS_EXPORT_SCHEMA_01 EXPORT                         SCHEMA                         NOT RUNNING 0 0 0
> SYSTEM SYS_EXPORT_SCHEMA_02 EXPORT                         SCHEMA                         NOT RUNNING 0 0 0
>... 

なんと・・・SYS_EXPORT_SCHEMA_01~99まで、全部で99個のジョブが溜まっている。実はexp先の容量不足から一部スキーマのバックアップに失敗していた時期があって、どうやらその時に失敗したexpdpのジョブが消えること無く溜まっていたらしい。

こういう時にはexpdpにattachオプションを指定して起動し、コマンプロンプトからkill_jobを実行すれば良い。でも残念ながら下記のようなエラーになってしまい、既存ジョブにアタッチする事が出来ない。

 C:\>expdp SYSTEM/****@ORA attach=SYS_EXPORT_SCHEMA_01

Export: Release 11.2.0.1.0 - Production on 金 6月 21 09:43:34 2019

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

接続先: Oracle Database 11g Release 11.2.0.2.0 - 64bit Production
ORA-39002: 操作が無効です
ORA-39000: ダンプ・ファイル指定が無効です
ORA-31640: ダンプ・ファイル"C:\dmp\XXX.dmp"を読取りのためにオープンできません
ORA-27041: ファイルをオープンできません。
OSD-04002: ファイルをオープンできません
O/S-Error: (OS 2) 指定されたファイルが見つかりません。 

既存ジョブにアタッチできないので、仕方なく以下のSQLでジョブを廃棄することにする。

> DROP TABLE SYS_EXPORT_SCHEMA_01;
> ...
> DROP TABLE SYS_EXPORT_SCHEMA_99; 

これで溜まっていたジョブが削除されたので、expdpは正常に戻った。

「VBAを覚えようと思うんだけど」と聞かれた話の続き

日付をまたいで「『VBAを覚えようと思うんだけど』と聞かれた話」の続きなど。

VBAを進められない理由・・・それは2025年以降、Microsoft Officeが月額制ライセンスのみとなることで、どのパソコンにもExcelが入っている時代が終わりそうだからだ。現在のMicrosoft Officeのライセンスは大きく分けて2種類、月額制ライセンスと買切りライセンスにわけられる。このうち買切りライセンスはOffice 2019を最後のバージョンとして2025年10月にサポートが終了する。

Microsoft Officeの買切りライセンスにはユーザーライセンスとデバイスライセンスの2種類に分かれる。ユーザーライセンスは使うユーザが同じなら複数台にインストールできるが、1台のPCを複数人で共有するなら人数分のライセンスが必要だ。デバイスライセンスはインストールするPCの台数分購入する必要があるが、1台のPCを複数人で共有してもOKだ。

対して月額制ライセンスはユーザーライセンスしか用意されていない。 PCの台数より従業員の人数の方が多いという職場は少なくない。小売業とか、製造業とか。1台のPCを10人程度で共有していた場合、デバイスライセンスだったら5万円で済んだのが、月額制ライセンスだと5年で50万円くらいに膨れ上がる。この金額増を避けるためMicrosoft Officeを全部のPCにはインストールしなくなると考えている。

一般家庭向けだと法人ライセンスより高くて年間1万2千円。4人家族なら年間4万8千円。現在はプレインストールモデルのOffice Personalを1万7千円の価格差で買えるから大抵の人はインストールしている。ライセンス料が5年で24万円と言われたら、利用頻度の低いだろう一般家庭は躊躇するのではなからろうか。海外だともうちょっと安いファミリー向けライセンスもあるらしいのだが、そうだとしても結構厳しい。

僕は 上記の理由から2025年になるとMicrosoft Officeの利用が減り、比較的安いコストで使える互換製品に移る動きが再び起こると思っている。互換OfficeソフトはMicrosoft Officeのファイルをほぼ問題なく扱うことが出来る。だがVBAだけは互換ソフトで動作しない。今むやみにVBAでプログラムを作りすぎると、5年後に追い詰められる予感がするのだ。

「VBAを覚えようと思うんだけど」と聞かれた話

事務系の同僚女子に「VBAを覚えようと思うんだけど」と言われて唸ったことがある。

ITリテラシーの高い従業員が増えることや、業務が効率化されること自体は喜ばしいのだが、ことVBAだけは手放しで勧められないのだ。

VBAはVisual Basicという言語が元になっている。このVisual Basicは1998年発売の6.0を最後に、2008年4月にサポートを終了している。Office製品の一部として提供されているためセキュリティアップデートこそ提供されているが、機能面では更新されていない。20年前で進化が止まっている。

そのためVBAでは、新しいバージョンのDB利用や、WEBサービスとの連携に無理が出ているのだ。MicrosoftのSQLServerで扱うデータ型の一部は取り扱えないし、WEB APIを呼び出そうとすると恐ろしく冗長なコードを書かざる得ない。

さらにVBAはインターネットが普及してセキュリティが重要視される以前の設計なので、セキュリティ面がどうしても弱い。標準では電子署名なしのマクロを実行できないように設定されているのは、セキュリティ的に弱く攻撃の対象にされやすいためだ。

セキュリティ面ではVBAを電子署名必須として運用するか、それが出来ないなら社内から無くしたいのが実情だ。でも実態は彼方此方で活用しているので、止めるに止められないので、セキュリティ担当者は困っていたりする。

ではどうしたら良いかというと、実は代案がない。ExcelやWordのファイルを扱うことができて、ライセンス料がかからず、平易に学習できて、完璧に日本語化されていて、どのWindowsパソコンでもそのまま動かせる言語・・・というのが見当たらない。

というわけで、VBAに関する愚痴でした。ちなみに私自身は、VBAを使って、新規にはマクロを作らないことにしています。 新たに作るときにはC#+Closed XMLで書きます。もしくはPower Query+Excelの数式だけで作ります。

Microsoftにも早く今後のLoadmapを考えてほしい。