04:29最近「ComicGlassのソートがWindowsの並びと違う」とご意見を頂きました。WindowsXP以降ではファイル名のソート順が数値などを解釈する自然な並びになるようになっています。よって単純なコードの比較とは違う結果になります。説明されるのは、20string2string3stringというソート順だったのが2string3string20stringという感じになることでしょうか。WindowsであればStrCmpLogicalW()というAPIを呼び出すとこのソートが行われます。Windows以外の環境でこのソートを再現する方法は、検索するといくつか提案されていますが、どうも結果が違います。公式な仕様が見つかればいいんですが、どうも見つかりません。そこで、それを再現すべくそもそもWindowsがどのようにソートしているか実験してみました。(特に海外のサイトの情報はUnicode文字に関する配慮がほとんどされてない事が多いので)結論から言うと、StrCmpLogicalWを再現するのって無理ゲーなんじゃないかと・・・。いい方法あったら是非教えてください。以下調査結果でございます。・StrCmpLogicalWは記号、数値、その他文字の順で並ぶASCIIやUnicodeでは「!」は「0~9」より前にあるが「;」などは数値より後です。Windowsでは「;」などの記号も数値より前に並びます。(Unicodeコード順)!test.txt0test.txt;test.txt(Windows)!test.txt;test.txt0test.txtというわけで、その文字が「記号」であるか「数値」であるか「その他文字」であるかを区別しているようです。そこで問題になるのが、何が記号で何が記号でないか。★(記号にならない一例)1⁄4Àうーん。プログラムを組んでStrCmpLogicalWで実際に試してみたのですが、かなり後ろの方のコードまで記号扱いになるものとと文字扱いになるものが入り乱れています。Unicodeコンソーシアムが規定するUNICOD文字一覧表に記号かどうかの情報があるようです。Unicodeとして記号かどうかで判断されており、それは規則性などなく全一覧を知らないとどうにもならない。・・・しかし!Windowsが知らない新しいUnicodeは正しく解釈していないような気がします・・・。U+2639(☹)、U+263A(☺)、U+263B(☻)は記号扱いですが、その他顔文字は記号になりません。したらWindowsではサロゲートペアが正しく処理されていないだけかもしれません・・・。これは心が折れますね・・・!・StrCmpLogicalWは全角の記号も半角と記号と同じ扱いになる同じ記号の場合は全角の方が後になる。・・・ってことは正準等価性を使った正規化してるんでしょうかね?その説を支持する結果として「»」が「§」よりも前に並ぶんですよね。後述しますが、数値で混在すると別々に評価されるっぽい。単純に先に正規化しても駄目と・・・。・StrCmpLogicalWは数字が並んでいる場合はまとめて1つの意味付けがされる0001.txt2.txt003.txtこれはファイルに0から順に名前つけて桁が増えた時に変な順番になるのを防げます。・StrCmpLogicalWは20桁以上の数値は数値として扱わない符号なし64bitで表せる値の最大値は18,446,744,073,709,551,616で20桁なので、20桁目からオーバーフローします。よって、Windowsも64bit演算で扱える最大値の19桁まで取り扱うようになっていると思われます。これは実装が楽で助かります。・StrCmpLogicalWは全角の0~9も数字として扱われる・ただし半角全角混在の場合はそうならない。情報求む・・・・!とりあえずASCIIコードにある記号だけ記号として解釈し、数値は19桁まで数値として認識する、という方法でだいたい近い結果にはなります。01:00タイトルのとおり。Windows相手にNetBIOSの名前解決を試みると失敗することがあるようです。ネットワーク・アナライザで見ると、リクエストは飛んでるのに応答が来ない。発生条件は不明ですが、テストで変なリクエスト送ったあとに起きやすい気がするけど、何もしてなくても起きる時もある。理由は不明ですが、一旦失敗するようになると、特定のIPアドレスから発信したものに対して応答が返らなくなる模様・・・。そのままでIPアドレス変えると動くようになります。このあたりエラーメッセージを簡略化してたので(接続できませんでしたくらいに)、次からメッセージ入れようと思います。基本ここで失敗はしないと思っていたので。SMB/CIFS周りはロバスト性に欠けてやっかいですわー。Windows同士でも調子わるいときありますもんね。無駄にSMB/CIFS周り(のバッドノウハウ)に詳しくなっていく・・・。21:00ネットワークプログラミングの基本中の基本。socket()関数があります。(基本すぎて今ではもう直接使う人はいないのかもしれませんが僕は使います。)socket()関数は戻り値としてソケットのファイル・ディスクリプタを返します。このソケットのファイル・ディスクリプタが何故か現代人には勘違いしやすいようで、うっかり0をエラー値だと思い込んでしまいます。socket()はエラーが発生したときには-1を返します。これがうっかり間違えます。実際0が返ってくることがありますのでたまに動かないという分かりにくい不具合の原因になります。わかっているのにうっかり間違えた例が以下のような感じです。本当に良く見かけます。自分も間違えますが・・・。COV_NF_END}おそらくポインタを返す時の失敗はNULLだろう、ハンドルを返すときのエラーは0だろう的な思い込みがあるせいではないかと思います。WindowsのAPIは成功すると非ゼロを返すという仕様のものが多いので、そういう普段使っている環境での慣れもあるのかも・・・。Macの一部にありました。同様にif(soc){close(soc);}みたいなミスもうっかりやりがちなのでお気をつけください。23:40・・・タイトルのようなソフトをリリースしましたのでお知らせします。リリースしたのは少し前ですが、記事にしていませんでしたので。最近のWindowsではソフトウエアでボリュームのミラーが作れるようになり、HDDの故障に備えることができるようになりました。Windowsのミラーの良いところは何より扱いやすいことです。BIOS画面一切さわる必要ありませんし。いざ障害が起きた時にそれを知る手段がイマイチないのが問題でした。いうわけでステータスが変わったらメールするソフト作ってみました。16:24とりあえず速報です。