パスワードを忘れた? アカウント作成
13810276 story
インターネット

HTMLのINPUTタグで選択したファイルを送信前に更新・削除した場合の挙動はブラウザ毎に異なる 56

ストーリー by hylom
やっぱり 部門より

多くのWebブラウザでは、「」タグで「type="file"」を指定することでフォームからファイルをアップロードできる。このとき、ファイルを指定してもフォーム上で送信ボタンをクリックするなどの操作を行わない限りはファイルの中身は送信されないのだが、ファイルの指定後に指定したファイルを更新/削除してから送信ボタンを押すとどうなるか、という挙動を調査した結果がQiitaに投稿されている

これによると、ブラウザ毎にこうした操作を行った場合の挙動は異なるという結果が得られたそうだ。たとえばファイルの指定後にファイルを更新した場合、多くのブラウザでは更新後のファイルが送信されたが、Edgeは空のファイルが送信されたという。また、ファイルを指定後に削除した場合はInternet Explorer 11のみ削除前のファイルが送信されたそうだ。

  • 最も信用できるのは、Edgeかなって。

    ここに返信
  • ファイルシステムの影響も受けそうだなあ。
    特にEdgeとIE11
    #検証する気はない

    ここに返信
  • by Anonymous Coward on 2019年01月09日 8時41分 (#3545377)

    メールにファイル添付
     ↓
    ファイルを編集

    ってしたときは、更新済みファイルが送られるのかわからないので、一応添付し直してる。

    ここに返信
    • たしかOutlookだと一旦 Temporary Internet Files の下にpoolされてから送信されてたっけ。
      だもんで、ファイル添付後に元ファイルを更新したら添付からやり直してました。

      • by Anonymous Coward

        どっかにプールするとかもそうだけど、ドロップされたタイミングでファイルをエンコードするのか、送信時にエンコードするのかってのもアプリによって挙動は変わりそうね。

        • by Anonymous Coward

          送信時にエンコードだと、そもそも上書き保存のときにファイルの識別子(例えばiノード番号)なんかが変わるのか変わらないのかは編集したアプリによるから、もうブラウザだけの問題じゃない。

    • by Anonymous Coward

      まあこのへんのUIの不統一やハマりどころって
      割とメーラー時代からの常識に思いますが、
      永らく囲い込まれてユーザも開発者も退化してきてますからねえ。

      • by Anonymous Coward

        そういう話は具体的に調査して明文化した後で言ってくれ。

        • by Anonymous Coward

          俺様体験こそ普遍の社会真理

    • by Anonymous Coward

      chromeとGmailで一度それをやって更新前のファイルが送られたことがある。

      • by Anonymous Coward

        gmail はファイルを選択した段階で ajaxで送信を始めるから、メールの送信とかの操作をした段階では、もうサーバーにデータが届いてる状態でしょ。

  • by Anonymous Coward on 2019年01月09日 9時33分 (#3545407)

    ChromeとFirefoxだけ追試してみた。

    選択後にchownやchmodやsetfaclでファイルのある場所やファイルそのものを読めないようにしてみる:
    Chrome、Firefoxともに削除時と同じ動作。
    一応状態は区別されているようでコンソールから起動しているとcannot access 'hogehoge': No such file or directoryやcannot access 'hogehoge': Permission deniedはでている。

    同様に選択後に/etc/apparmor.d/opt.bin.chromeや/etc/apparmor.d/opt.bin.firefoxプロファイルを編集しAppArmor側で読み込みを禁止してみる:
    読み込み開始した瞬間にChrome、FirefoxがPermission deniedで落ちる。

    ここに返信
  • by Anonymous Coward on 2019年01月09日 8時41分 (#3545378)

    IEは場合によってはアリかもしれない。
    ChromeとFirefoxが一番無難で納得できる挙動でしょう。

    ここに返信
    • by Anonymous Coward on 2019年01月09日 8時59分 (#3545386)

      自分はあえて評価したくないな
      「そもそもそういう不安定なファイル送ろうとするのやめて。動作保証外です」と言いたくなる

      • by Anonymous Coward
        マルチタスクOSでファイル操作の競合が発生するのは当たり前のことなんだから
        安定した仕様を決めて動作を保証しろよ。
        君はファイルをロックするなどの排他制御をしてもいいし、競合を検出したときに何らかのエラー処理を書いてもいい。
        というかプログラマの仕事なんて過半数がそういう通常は通らない例外処理だろうに。
        #もしくはシングルタスクOSだけでコード書いてください。
        • by Anonymous Coward

          本当にそれで頻繁に問題が起きるようならOSレベルで「通常オープンは排他制御、共有アクセスはオプション」扱いにしているよ。
          過去のプログラムとの互換性やパフォーマンスへの影響も大きいから「必要ならプログラムで個別に対処してくれ」で済ませている程度の問題でしかないってことだ。

        • by Anonymous Coward

          マルチタスクだからこそ他が何するかわからない部分は仕様の決めようがないだろ。「想定外」を無くすなら、先に未来永劫も含めて同じOSで動作するアプリケーションの仕様を知っておく必要があるけど、そんなのできる?
          というか、何でもかんでもロックかけりゃいいってモノでもないし。

          # それとも「ブライト博士の禁止リスト」ならぬ「ブラウザ使用時の禁止リスト」でも作る?

          • by Anonymous Coward

            他が何をするかわからないからこそ「他のプログラムがオープン中は少なくとも書き込み/削除禁止」を通常オープンにして、それ以外の状態でオープンしたいなら個別にオプション指定するだけでも随分ましになるぞ。
            だが現状は「標準オープンは他のプログラムも読み書きOK」で、そこそこ無難そうな「俺が使用中だから他のプログラムは書き込み禁止」ですらオプション扱いだ。

            > 何でもかんでもロックかけりゃいいってモノでもないし。

            必要ならそれなりにモード指定してオープンすればいい。「標準だとロック」は「必ずロック」とはまるで違うぞ。
            OSの既定のファイルオープンモードが「なんでもあり」な理由を合理的に説明してくれよ。

            • by Anonymous Coward

              Windows では排他状態を指定しない時に「他のプログラムがオープン中は少なくとも書き込み/削除禁止」ですよ。
              共有で開くときに明示する必要がありますので、現状の認識がズレてます。
              NTFS ならトランザクションはったうえで、ファイル操作すれば、コミットするまで他のプロセスからは変更前の状態のまま同期できますよ。

              Linux(Unix系)でそうなってないのは、過去の経緯から、いまさら排他をデフォに出来ないってだけでしょう。

              • by Anonymous Coward

                てことは、Windowsのブラウザで「これから送信するファイル」として選択した後も変更可能なのは意図的にそうしているってことだね。

              • by Anonymous Coward

                てことは、Windowsのブラウザで「これから送信するファイル」として選択した後も変更可能なのは意図的にそうしているってことだね。

                意図的というより「これから送信するファイル」は「送信中のファイル」ではないからでしょ。

                土台、「ファイルを選択したタイミング」「送信ボタンを押したタイミング」のどちらが送信されることをユーザーが望んでいるか、正しく認識するなんてことがコンピューターにできるわけないので、どちらに設定したってユーザーの認識との乖離は発生しうるし。

              • by Anonymous Coward

                意図的にやってるというか、選択したときはファイル名だけ保持して、実際に送信する段階でファイル開いてるってだけだろう。

              • by Anonymous Coward

                そりゃわかってるよ。
                変更されたくなければ簡単にできるのにあえてやってないってこと。

              • by Anonymous Coward

                そりゃわかってるよ。
                変更されたくなければ簡単にできるのにあえてやってないってこと。

                ・システム的に変更できないと困る(たとえばログファイルをWebにアップロードしてる間、握り続けられたらログ出力するのに困る。かといってログを書き出す側が握り続けるのも本末転倒)
                ・他アプリで既に開かれているファイルを送りたいだけなのに、ブラウザが握ろうとして落ちるため送信できない

                みたいなタコい事態を防ぐためだろ。

                何でもかんでもロックかけて解決って考え方こそマルチタスクには不向きだよ、ロックの弊害を回避する設計がされてないアプリを使うだけでシングルタスクしかできなくなるんだから。

              • by Anonymous Coward

                だからそういうのがあるから「あえてやってない」と言ってるわけなんだけど…

    • by Anonymous Coward

      送信中に更新するとか、タイミングによっちゃ送信ファイル壊れそう>chrome、firefox

  • by Anonymous Coward on 2019年01月09日 9時19分 (#3545396)

    ブラウザによっては送信後もしばらくの間ロックされてファイルを消したり編集したりできなくなる。
    ちょっと編集してアップロードしてを繰り返す用途で面倒くさいことになる。そのブラウザにしか対応してないサイトとのコンボが痛い。

    ここに返信
    • by Anonymous Coward

      > ちょっと編集してアップロードしてを繰り返す用途で面倒くさいことになる。

      そういう用途ならもうローカルファイルを編集するのはやめてクラウド/オンラインストレージ上のデータを直接いじった方がいいよ。
      作業用フォルダで編集して共有フォルダにコピーを繰り返す形ならそういうロックはかからないだろうから。

      • by Anonymous Coward

        世の中、そういう用途だけではないんだ。
        計画書、報告書、論文の類をアップロードすると様式通りか自動チェックされて、字数が足りないとか余白が足りないとか図の解像度がーとかフォントがー…とかで蹴られるので修正して再アップロードとか。

  • by Anonymous Coward on 2019年01月09日 9時29分 (#3545403)

    「選択、更新、削除、送信すると、更新後のファイルが送信される」が本当なら、どういう処理やってるんだろう?更新できるということは、選択の時点でコピーしたものがそのまま送信されるわけではない。しかしファイルが存在しなくても送信できるのだから、削除の前のどこかで読み出す動作はしていたのか。
    選択後、定期的に読み出しを行なって変更があれば更新するが、削除されていた場合には追随しない、という事なのかな…??

    ここに返信
    • by Anonymous Coward

      FindFirstChangeNotificationみたいなの使えば変更検出できるから変更あったらそれ保存ってことだろね

      • by Anonymous Coward

        素だと保存しないのに更新時だけ保存するってのがおもしろいな。
        選択と更新両方でコピーするように実装したが、巨大ファイルのアップロード前にいちいちコピーすると重いとかで選択時の方のコピー動作だけ消した、とかなんだろうか。
        動画とかコピーされたらテンポラリ容量食いそうだなぁ……つか動画ファイルの書き出し中に選択とか、そもそもファイルサイズが大きい場合の挙動はどうなるんだろう?
        更新回数やロック(排他制御)状況、ファイルサイズなんかにも依存して挙動変わってもおかしくないな。

        こういうの、選択時点でロックかコピー(できればシャドウ)取って更新検知で警告の上ユーザに選択させるのが理想……なんかな?
        HTML5的には選択時点でAJAX送信とか出来てしまうから、警告・選択はともかく選択時点でロックかコピーはしないと不味い気も……

    • by Anonymous Coward

      ファイル削除がゴミ箱に入るだけなら、
      そこまで取りに行ってるのでは。

    • by Anonymous Coward

      IEが共有可能+readonlyのモードでファイルをオープンしているだけですよ.

      あるプロセス(ここではIE)がファイルをオープンして
      ハンドルを保持したまま,別プロセスがファイルを削除すると
      ファイルは消えたように見えますが,
      その中身はOSのファイルシステム上にはまだ存在した状態になります.

      名前が無いファイルになるイメージです

      ファイル削除後でも,IEは名無しのファイルから更新後のデータを読み出せます.

      そしてIEのプロセスがファイルを閉じると,その名無しのファイルは完全に消えます.

  • by Anonymous Coward on 2019年01月09日 10時35分 (#3545441)

    IE,Edge,Safariはともかく、ChromeやFirefoxはどのverをどのOSのどのverでやったのか気になる。

    ここに返信
  • by Anonymous Coward on 2019年01月09日 13時56分 (#3545551)

    「」タグで「type="file"」

    にツッコミなし

    ここに返信
    • by Anonymous Coward

      ソースも覗いてみたけど、そのまま『「」タグで』ってなってましたね。
      どこかの段階でサニタイズ処理かなんかでカギカッコ内のタグ文字列が削除されたのでしょうかね。

      • by Anonymous Coward

        ほんとに見直しもなにもしてないんだなあhylom
        なんでしないんだろ

  • by Anonymous Coward on 2019年01月09日 15時05分 (#3545629)

    lpr でプリントするときは、-s オプションをつけてシンボリックリンクにしろ。ゴミをプリントキューに放置するなって…

    ここに返信
  • by Anonymous Coward on 2019年01月09日 16時57分 (#3545745)

    この場合、全ブラウザ 糞 UI/UX だね。

    ブラウザは手動で操作するのが前提なのだから、こういう場合は確認画面を出すのが正解。

    ファイル指定時とSubmit時のファイルに違いがあったら(ハッシュ値が違うような状況だったら)、確認画面を出してユーザにどうするか尋ねるべき。

    ここに返信
    • Dialog 出す方がクソだと思う。ファイルを排他で開くプログラムは珍しくなく、メールの文面書いている最中に添付ファイルを確認したくなることは比較的よくある。そのたびに Dialog なんか出されたんじゃたまった物じゃない。

      現状は Edge を除くと、十分利用状況を考慮した結果ではないかと考えますね。

    • by Anonymous Coward

      「ファイル指定時」もいろんなことがバックグラウンドで行われてるんだから、ロックしないとどっちみちどっかでレースコンディションになって、ハッシュの計算とかは意味ないよ。

typodupeerror

あと、僕は馬鹿なことをするのは嫌いですよ (わざとやるとき以外は)。-- Larry Wall

読み込み中...