「パラメーターが間違っています。87」 （ディレクトリジャンクション / マウントボリューム）

[kouji.o...@gmail.com]

パラメーターが間違っています。87 （ディレクトリジャンクション / マウントボリューム）

メッセージ

WriteFile(パラメーターが間違っています。87) : ＜COPY先ファイルパス1＞

WriteFile(パラメーターが間違っています。87) : ＜COPY先ファイルパス2＞

　　　：

ReadFile(digest)(パラメーターが間違っています。87) : ＜COPY先ファイルパス3＞ ・・・verifyの失敗（COPYは成功）

　　　：

　コピー（移動）先のパス が、ディレクトリジャンクション / マウントボリュームの場合、ファイルサイズ条件により失敗するようです。

　ファイルサイズに起因していそうなのですが、細かな条件までは絞れませんでした。

※ もちろん、エクスプローラーでのコピーは問題なく成功します。

・コピー元：不問

　なだし、ファイルのサイズによる事象の発生有無があります。

　下記、

・コピー（移動）先

　～3TB（4TB未満？）のドライブ下に作成した、

‘4TB以上のドライブ（下のフォルダ）へのディレクトリジャンクション’（下のフォルダ）

 or マウントボリュ－ム 同様に発生

　3TBディスクへのディレクトリジャンクション時は発生しない。

　4TB以上のドライブ下に作成した、

‘4TB以上のドライブ（下のフォルダ）へのディレクトリジャンクション’（下のフォルダ）

では発生しない。

　全てのファイルのコピーが失敗するのではなく、特定のファイル幾つかが失敗。

　　DVD書き込み用フォルダのように、バラバラのサイズでも小さなサイズ・

　大きなサイズというわけででもなく不明。

　　失敗するファイルは必ず失敗。

※コピー先が上記の場合にのみ発生し、コピー元が上記コピー先の様な場合でも発生しません。

正常にCOP & Vverify したファイルのサイズ

         16,384 バイト

         16,384 バイト

          8,192 バイト

  1,016,373,248 バイト

         20,480 バイト

         20,480 バイト

          8,192 バイト

          8,192 バイト

書き込み失敗したファイルのサイズ

WriteFile(パラメーターが間違っています。87) :       240,182 バイト

WriteFile(パラメーターが間違っています。87) :    12,638,010 バイト

WriteFile(パラメーターが間違っています。87) :       663,756 バイト

WriteFile(パラメーターが間違っています。87) :        96,256 バイト

WriteFile(パラメーターが間違っています。87) :        96,256 バイト

WriteFile(パラメーターが間違っています。87) :     1,488,896 バイト

WriteFile(パラメーターが間違っています。87) : 1,073,739,776 バイト

WriteFile(パラメーターが間違っています。87) : 1,073,739,776 バイト

WriteFile(パラメーターが間違っています。87) : 1,073,739,776 バイト

WriteFile(パラメーターが間違っています。87) :   156,719,104 バイト

WriteFile(パラメーターが間違っています。87) :   241,043,456 バイト

書き込み成功 / Verifyの失敗（COPYは成功）したファイルのサイズ

ReadFile(digest)(パラメーターが間違っています。87) :    283 バイト

ReadFile(digest)(パラメーターが間違っています。87) : 22,528 バイト

ReadFile(digest)(パラメーターが間違っています。87) : 22,528 バイト

例

━━━━━━━━━━━━━━━━━━━━━━━━

SOURCE　　不定

　　DVD書き込み用フォルダのように、バラバラのサイズでも小さなサイズ・

　大きなサイズというわけででもなく不明。

　　失敗するファイルは必ず失敗。

───────────

D:   <2TBドライブ>  SOURCE側は不問

　\○○○○○○

　　　：

　　　：

━━━━━━━━━━━━━━━━━━━━━━━━

DEST.　 2TB（4TB未満？）のドライブ下の、

　‘4TB以上のドライブ下のフォルダへのディレクトリジャンクション’下のフォルダ

───────────

E:　　<2TBドライブ>

　\MNT

　　<\2016>・・・・ R:\ へのディレクトリジャンクション

------------------------

R:　　<4TBディスク>

　：

━━━━━━━━━━━━━━━━━━━━━━━━

DEST.  2TB（4TB未満？）のドライブ下の、

‘4TB以上のドライブ下のフォルダへのディレクトリジャンクション’下のフォルダ

───────────

E:　　 <2TBドライブ>

　\MNT

　　\HDD2016・・・・ ディスク HDD2016 をマウント

------------------------

E:\MNT\HDD2016　<4TBディスク>　（R:とかではなく）

　：

━━━━━━━━━━━━━━━━━━━━━━━━

[Hiroaki SHIROUZU]

詳細なご報告ありがとうございます。

これは FastCopy がCreateFile(FILE_FLAG_NO_BUFFERING)を使った、Direct I/O を行っているための制約になります。

Direct I/O を使った場合、用意するバッファは「セクタ単位」のサイズでかつ、アドレスもセクタ単位に整列されている必要があります。

FastCopy では src/dst のドライブのルート情報からセクタサイズを取得し、大きい方に合わせるようにしています。

（上記でエラーなのは、セクタサイズの倍数以外のファイル、と思います。

　ただし、設定→I/O設定→OSキャッシュ指定でキャッシュ利用となっているサイズ以下のファイルでは Direct I/O を使わないため問題は出ません）

さらに、読み込み時に ERROR_INVALID_PARAMETER でエラーとなった場合、最大4KBまでみなしセクタサイズを拡大して、バッファを用意して試行します。

しかし、書き込み時にはすでに予想セクタサイズで整列済みの読み込み済みバッファが存在するため、動的なみなしセクタサイズ拡大等は難しく、エラーとしています。

ということで現状は仕様ということになりますが、将来的な対応としては、

１．ルートではなく、src/dst指定ディレクトリもしくは、その配下ディレクトリに潜る毎に実ドライブの存在先を調査

２．見做しセクタサイズを設定などから指定できるようにする

などが考えられます。

ただ、１は低コストでそれができるかはもうすこし検討してみないとわからないので、目先に入れるとすると、２になるかもしれません。

（その場合のデメリットは、みなしセクタサイズ未満のファイルが大量にあった場合にバッファの利用効率が若干下がる点です。

　たとえば4KBに設定すると、512byteセクタ環境で1byteのファイルでも4KBのバッファを使うようになります）

[o o]

　早々の前向きなご回答ありがとうございます。

　気長に待たせていただきます。

ということで現状は仕様ということになりますが、将来的な対応としては、

１．ルートではなく、src/dst指定ディレクトリもしくは、その配下ディレクトリに潜る毎に実ドライブの存在先を調査

２．見做しセクタサイズを設定などから指定できるようにする

などが考えられます。

　“その配下ディレクトリに潜る毎に・・・”については「コピー・移動設定」の【Junction/Symlink は(実体/配下ではなく)それ自体をコピー】の指定がありますので、‘チェック’がある場合は、src/dst指定ディレクトリ以外は再調査の必要が内容にも思えます。

　【Junction/Symlink は(実体/配下ではなく)それ自体をコピー】の チェックが無い 場合は・・・

 

[Hiroaki SHIROUZU]

暫定解ですが、I/O設定→「最小セクタ長を4096byteとみなす」というオプションを追加しておきました。

これをONにすると、書き込み階層の途中でセクタサイズが変化した場合も、問題が出なくなるはずです。

[o o]

事象の再現確認後、→ver.3.21 & 「最小セクタ長を4096byteとみなす」設定にて、事象が発生しないことを確認いたしました。

ありがとうございました。

[Hiroaki SHIROUZU]

それはよかったです。

ご確認ありがとうございました。

[o o]

追伸です。

　「最小セクタ長を4096byteとみなす」設定が保存されないようです。

　設定後、閉じない（終了しない）ままでは反映していますが、終了すると設定がクリアされた状態で起動します。

　実際の動作も表示通りです。

[Hiroaki SHIROUZU]

ご報告ありがとうございます。

次のバージョンで修正しておきます。

とりあえずは

fastcopy2.ini の [main] min_sectorsize="4096"

を設定してお使いください。

[o o]

fastcopy2.ini に追加して動作良好を確認いたしました。
迅速なご対応をありがとうございました。

[o o]

追伸です。　特に事象とは関係ありません。

本設定時、512セクタエミュレーションHDDが早くなりました。（あたりまえなんでしょうけど）

[Hiroaki SHIROUZU]

ご報告ありがとうございます。

これはとても貴重な情報ですね。

たしかに、エミュレーションの場合、本当のセクタから境界からずれた場合に、1つのHDD用WriteコマンドがHDD内部でR-M-W(Read/Modify/Write) の3つに分解されることがあるので、その影響かもしれません。

MS側もそれに関する情報を掲載しているようです。

https://msdn.microsoft.com/ja-jp/library/windows/desktop/hh182553(v=vs.85).aspx

それ以外にも NTFSのクラスタサイズも多くは4KB以上になっているので、そろそろ4096byte有効をデフォルトにする方が良さそうですね。

（あとは小さなファイル向けのバッファは例外にして利用効率を高める工夫も入れらえれば理想的ですが）

[o o]

　INIファイルに関しての追伸です。

　FastCopy2.ini を直接編集して min_sectorsize="4096" 追加後、各種設定が初期化されるようです。

　（ini_version="2" 関連？）

　一応、報告させていただきました。

[Hiroaki SHIROUZU]

ご報告ありがとうございます。

FastCopy2.ini には必ず ini_version="2" が記載されます。

FastCopyはこの項目がない場合、不正なiniと見なして読み込まず、.ini.bak にリネームしたうえで、新しいiniを作ります。

項目追加した際、ini_version="2" が消えてしまっていた等はないでしょうか？

（ini.bakをご確認ください）

[o o]

　[main] と ini_version="2" の間に min_sectorsize="4096" 行を挿入していた為っぽかったです。

[Hiroaki SHIROUZU]

ご確認ありがとうございます。

順番が入れ替わっただけであれば、特に問題なく読めるはずなのですが…

（そして次回の上書き時に ini_version を先頭に配置し直します）

もし、ini_version="2" の行自体か、その前後に妙な文字が入っていた等がないようであれば、

iniもしくは再現に必要な最小範囲の行を、お送り頂けると助かります。

[o o]

　おそらく色々試している際、終了していない FastCopyプロセスがある状態で ini ファイルを操作したものと思います。

　とりあえず、本件は忘れてください。

　お騒がせいたしました。

　古いファイル履歴が文字化けしているので、その関係ではないかと思っています。

　また再現出来ましたら、改めて報告させて頂きます。