一部の 32 ビット Windows アプリでファイルのコピーや保存が断続的に失敗する問題 30
ストーリー by nagazou
不具合 部門より
不具合 部門より
headless 曰く、
Windows 10 / 11 で一部の 32 ビットアプリによるファイルのコピーや保存、添付が断続的に失敗する問題が発生しているそうだ (既知の問題と通知、 Neowin の記事、 BetaNews の記事、 Ghacks の記事)。
影響を受けるのは 4GB のメモリ空間が使用できるよう IMAGE_FILE_LARGE_ADDRESS_AWARE がセットされ、CopyFile API を使用する 32 ビットアプリだ。拡張ファイル属性を使用する商用/エンタープライズ向けセキュリティソフトを使用している Windows デバイスでは発生する可能性が高くなるという。
エクスプローラーを使用したファイルコピー時に問題が発生したとの報告は受けていないが、アプリ内で使用する CopyFile API は影響を受ける可能性があるそうだ。Microsoft Office アプリでは 32 ビット版使用時のみ「ファイルが保存されなかった」というエラーが発生する可能性がある。ただし、コンシューマーが家庭で使用する Windowsデバイスや、非マネージドの商用デバイスが影響を受ける可能性は低いとのこと。
問題は断続的に発生するため、保存やコピーを再試行すれば成功する可能性が高い。そのため、回避策としては処理の再試行が挙げられている。
あのときは馬鹿にしてすみませんでした (スコア:4, 参考になる)
10数年前、何かのオーディオ誌に「iPodに曲を入れるときは同じファイルを上書き保存してなじませる」
と書いてあって思わず鼻で笑ってしまったんですが、これを予見してたんですね。流石です。
Re: (スコア:0)
？？？
LOAD? とか VERIFY とか (スコア:0)
＞問題は断続的に発生するため、保存やコピーを再試行すれば成功する可能性が高い
BASICでカセットテープにセーブしていた時代の LOAD? とか
MS-DOS時代のVERIFY ONとかが復活
……しないか
Re: (スコア:0)
カセットテープからの読み込みならLOADじゃなくてCLOADだと思います
# インターネット老人会
Re:LOAD? とか VERIFY とか (スコア:1)
Hu-BASIC使いの人
Re: (スコア:0)
N88-BASICもCLOADではなく、
LOAD "CAS:～" (CAS1と同等だったはず)
LOAD "CAS1:～" (1200ボー)
LOAD "CAS2:～" (600ボー)
だね。
Re:LOAD? とか VERIFY とか (スコア:1)
どこのbasicだか思い出せないのて初老止まり
Re: (スコア:0)
MSXはCLOAD?(Verify error)で、MZ-80のS-BASICがVERIFY(Data Error)で、FM-7のF-BASIC(Device I/O Error)とN88-BASIC(86)(Bad)がLOAD?だったような。
Re: (スコア:0)
N88 BASIC の motor コマンドで、
メトロノームを作った思い出。
ポインタ周りをミスったか (スコア:0, 参考になる)
32bit環境だと仮想メモリ空間は通常2GBまでなので、うっかりメモリポインタを符号付きな変数にキャストしちゃったとか、判定で溢れさせたのかね。
32bit版OSだとOSの設定を変更しないと発覚しないし、
64bitネイティブだとこれまたポインタ変数がデカいから平気。
WOW64環境下で動く、32bit版でLarge Address Aware対応のアプリが死ぬと。
でも、そんなLarge Address Aware対応してまでメモリを沢山使いたいアプリは64bitにとっとと移行してるから、不具合踏む人は少数派だろうね。
32bit自体の古いアプリをずっと使い続けてるとか。
Re: (スコア:0)
CopyFile()というAPIのバグだから、言ってることの大半は間違ってるよ。
Re:ポインタ周りをミスったか (スコア:3, 参考になる)
断続的に発症というのが不思議です。初期化してない変数を参照したようなことかな？
Qiita [qiita.com]
アプリケーションを Large Address Aware 対応にしたいのであれば、Integer によるポインタ操作をしていない事が条件です。ポインタを Integer でキャストしている場合には正常動作しない可能性があります
ってな記述をみると、CopyFile()にポインタをIntegerにしている箇所があって、たまたま上位アドレスが０なアドレスの範囲なら動くけど、それを越えたらダメとか？
Re: (スコア:0)
そのAPIのバグが起きた理由として想像した内容なんだけど、どの辺が間違いか指摘してくださいな。
Re:ポインタ周りをミスったか (スコア:1)
Re: (スコア:0)
その再現性がかなり低いだろう理由についても元コメの推測がかなり尤もらしいと思うけど。
どの辺の間違いを指摘してるのかよくわからん。
Re: (スコア:0)
再試行で成功する可能性が高いらしいけど、再試行みたいな短時間で上位アドレスが変わるってのも変な気が。
Re: (スコア:0)
ポインターを返す関数の戻り値の仕様を
としていたAPI開発者のみなさ〜ん、元気ですかー？
正常かどうかの判定を
if ( (int)ptr < 0 ) { /* 異常時処理 */ }
としていたAPI利用者のみなさ〜ん、生きてますかー？
Re:ポインタ周りをミスったか (スコア:1)
64ビット版WindowsでのLarge Address Awareな32ビットプロセスでも、0xFFFF0000～0xFFFFFFFFは予約されていてアプリから使えないみたい。
https://stackoverflow.com/a/48081399 [stackoverflow.com]
https://www.marbacka.net/blog/64bit_addressing/ [marbacka.net]
だから-1と-2を返すのはセーフ。もちろんif ( (int)ptr はアウト。
Re: (スコア:0)
32bit版Windows以外の幾つかの32bit版Unix系OSもサポート対象だったけど、それらも含めて0xFF…FFや0xFF…FEをアプリに返すOSは無いでしょうね。
なので、API利用者側だった自分は取り敢えず
if ( (ptr == (Foo *)-2) || (ptr == (Foo *)-1) ) { /* 異常時処理 */ }
とかしといた。
この仕様に慣らされて、
FILE *fp = fopen(…);
if ( (int)fp < 0 ) { /* 異常時処理 */ }
とか通常の32bitアプリでも動かない（OSのある）コードを書いてた奴は、生きてるかな？
Re: (スコア:0)
なんで素直にNULLポインターを返さないのか
Re: (スコア:0)
ガッてされるから
Re: (スコア:0)
最近の若者にはそのネタも通じないらしいな。Javaと2chという老人会タッグだから当然だな。ChatGPTやBardは応じてくれるが
Re: (スコア:0)
Win32では値が0xFFFF以下ならばグローバルアトムとみなし、0x10000以上ならば文字列へのポインターとみなすという仕様のAPIがたまにあるので、先頭64KB(0x00000000～0x0000FFFF)も予約されている。これは上位16ビットが0x0000(ヌルセレクター)のfarポインターを特別扱いしていたWin16との互換性のため。
Re: (スコア:0)
COMで制御機器を叩く32bitのプログラムがいくつか該当したけど
そういった問い合わせが来たことはまだ無いですね。
いつ頃からの症状なのか、エラーコードは何なのか、CopyFileEx()でも出るのか、
なにひとつわからないから週明けまで続報待ちかな。
「とりあえず何度かリトライ」とか、ファイルコピーにはちょっと怖い。
Re: (スコア:0)
32bit OSではなく、32bit アプリの話なんですけど。
サーバー系アプリとかでメモリ空間を2GBから3GBへと+1GBが欲しくて頑張ってたようなアプリが影響を受ける。
Re: (スコア:0)
32bit OSではカーネルモードのコードが使用するメモリ空間を残しておかなければならないので3GB止まりだけど。64bit OSだとカーネルモードのコードは4GBの範囲外に置けるから4GB近くまで使える。なんで「32bit OSではなく、32bit アプリの話なんですけど。
」と言いつつ32bit OSの話をしてるの?
Re: (スコア:0)
必要に迫られて作った負の遺産だから過去形で書いただけだよ。
Windowsだとわかる内容。 (スコア:0, 参考になる)
Windowsは不思議なことがよく起こるので、
タイトル見てえそんなこと？
って思うけどWindows使うと、まぁあっても全然おかしくもない。
Windowsを使い続けるってのは結構オカルト的になことがよく起こるから仕方ないよなぁ
宇宙天啓データベース (スコア:0)
断続的と言われるとどうしても断続的な絞首刑が思い浮かんでしまう