備忘録。

ADO.NETで以下のようなParameterized SQLを設定、@EndにDateTime.Maxを設定すると検索件数が0になってしまう。

SELECT DISTINCT(name) FROM persons WHERE @Start<=releasedate AND releasedate<@End

@Endを'9999/12/31 23:59:59.9999999' としてMySQLのコマンドラインからこの文を打ち込むとデータが来る一方、'10000/1/1 0:00:00'とすると件数0。5桁の西暦で不具合起こすのはまぁあり得る話かなとは思いますが、DateTime.Maxもこの辺の際どい扱いを受けているのかも。

環境としてはサーバーはDebianのMySql 5.7.16、クライアントはMySql.Data 6.9.9、.NET Framework 4.5なのですが、この現象は私の開発マシン(Windows 8.1)や仮想マシン上のWindows 7では問題なかった実行ファイル一式が、別人のPC(Windows 8.1)だと不具合になったことで発覚。サーバーもクライアントも同じプログラム使っているのになぜ発生の有無があるのだろう。

@End=DateTime.Maxということは事実上releasedate上限無しということなので、WHERE句から外してやると正常に。面倒くさいけど@EndがDateTime.Maxの時はWHERE句に入れないようにクエリー文を切り替えたほうが無難そう。

備忘録ではあるのですが、再現実験したらエラーが出なくなったのであくまで参考に。

FreeNAS (9.10.1-U2)に作成したMercurialレポジトリにWindows側からファイルをaddしようとすると、

abort: ¥¥server¥folder¥.hg¥.dirstate-lk0nhu: Access is denied

みたいなメッセージが出て失敗する場合、FreeNAS側の共有フォルダ詳細設定で隠しファイルを表示する設定にすると解決しました。

私しか使ってないFreeNASを9.10.2-U1にアップデートしたところ、あるフォルダ内のファイルが全部消え失せて目を疑う。

フォルダ構成は

pool1 (ZFSプール)
 +- Dataset1 (ZFSデータセット)
 |    +- Share1 (ディレクトリ/CIFS共有)
 |    |   +- Share1-1
 |    |   +- Share1-2
 |    |   ...
 |    |   +- Share1-n
 |    +- NoShare1 (ディレクトリ/Jail用)
 |        + NoShare1-1 (Share1-1をNullFSでマウント)
 ...
 +- DatasetN (ZFSデータセット)

これがアップデート後にShare1-1の中身が空っぽに。Share1-1にはサイズの大きいファイルがたくさんあったので本当に消えたのならpool1の空き容量が増えているはずだけど、その様子もなく。各種状態もエラーなし、scrubかけても正常。

ダメ元でfindコマンドでpool0内をファイル検索かけたところ…Share1-2の下にShare1-1フォルダが入っていたよ Σ(ﾟДﾟ)

もちろんした覚えはないけど、間違いでWindowsからのファイル共有操作でフォルダを移動させてしまった可能性はある。ただ…元の場所に空のShare1-1フォルダは確かに存在したんだよなぁ。間違いでもご丁寧にフォルダ移動させたうえで、Share1-1作り直すなんてことはやらない。

今回FreeNASのアップデートは無罪でしょうけど、前回 とか過去に何回かトラブル経験しているので、アップデートはヒヤヒヤものです。やっぱり不具合無い限り更新しない方が良いかなぁ…