アカウント名:
パスワード:
IEは場合によってはアリかもしれない。ChromeとFirefoxが一番無難で納得できる挙動でしょう。
自分はあえて評価したくないな「そもそもそういう不安定なファイル送ろうとするのやめて。動作保証外です」と言いたくなる
本当にそれで頻繁に問題が起きるようならOSレベルで「通常オープンは排他制御、共有アクセスはオプション」扱いにしているよ。過去のプログラムとの互換性やパフォーマンスへの影響も大きいから「必要ならプログラムで個別に対処してくれ」で済ませている程度の問題でしかないってことだ。
マルチタスクだからこそ他が何するかわからない部分は仕様の決めようがないだろ。「想定外」を無くすなら、先に未来永劫も含めて同じOSで動作するアプリケーションの仕様を知っておく必要があるけど、そんなのできる?というか、何でもかんでもロックかけりゃいいってモノでもないし。
# それとも「ブライト博士の禁止リスト」ならぬ「ブラウザ使用時の禁止リスト」でも作る?
他が何をするかわからないからこそ「他のプログラムがオープン中は少なくとも書き込み/削除禁止」を通常オープンにして、それ以外の状態でオープンしたいなら個別にオプション指定するだけでも随分ましになるぞ。だが現状は「標準オープンは他のプログラムも読み書きOK」で、そこそこ無難そうな「俺が使用中だから他のプログラムは書き込み禁止」ですらオプション扱いだ。
> 何でもかんでもロックかけりゃいいってモノでもないし。
必要ならそれなりにモード指定してオープンすればいい。「標準だとロック」は「必ずロック」とはまるで違うぞ。OSの既定のファイルオープンモードが「なんでもあり」な理由を合理的に説明してくれよ。
Windows では排他状態を指定しない時に「他のプログラムがオープン中は少なくとも書き込み/削除禁止」ですよ。共有で開くときに明示する必要がありますので、現状の認識がズレてます。NTFS ならトランザクションはったうえで、ファイル操作すれば、コミットするまで他のプロセスからは変更前の状態のまま同期できますよ。
Linux(Unix系)でそうなってないのは、過去の経緯から、いまさら排他をデフォに出来ないってだけでしょう。
てことは、Windowsのブラウザで「これから送信するファイル」として選択した後も変更可能なのは意図的にそうしているってことだね。
意図的というより「これから送信するファイル」は「送信中のファイル」ではないからでしょ。
土台、「ファイルを選択したタイミング」「送信ボタンを押したタイミング」のどちらが送信されることをユーザーが望んでいるか、正しく認識するなんてことがコンピューターにできるわけないので、どちらに設定したってユーザーの認識との乖離は発生しうるし。
意図的にやってるというか、選択したときはファイル名だけ保持して、実際に送信する段階でファイル開いてるってだけだろう。
そりゃわかってるよ。変更されたくなければ簡単にできるのにあえてやってないってこと。
・システム的に変更できないと困る(たとえばログファイルをWebにアップロードしてる間、握り続けられたらログ出力するのに困る。かといってログを書き出す側が握り続けるのも本末転倒)・他アプリで既に開かれているファイルを送りたいだけなのに、ブラウザが握ろうとして落ちるため送信できない
みたいなタコい事態を防ぐためだろ。
何でもかんでもロックかけて解決って考え方こそマルチタスクには不向きだよ、ロックの弊害を回避する設計がされてないアプリを使うだけでシングルタスクしかできなくなるんだから。
だからそういうのがあるから「あえてやってない」と言ってるわけなんだけど…
送信中に更新するとか、タイミングによっちゃ送信ファイル壊れそう>chrome、firefox
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
EdgeとSafariがダメかな。 (スコア:0)
IEは場合によってはアリかもしれない。
ChromeとFirefoxが一番無難で納得できる挙動でしょう。
Re:EdgeとSafariがダメかな。 (スコア:1)
自分はあえて評価したくないな
「そもそもそういう不安定なファイル送ろうとするのやめて。動作保証外です」と言いたくなる
Re: (スコア:0)
安定した仕様を決めて動作を保証しろよ。
君はファイルをロックするなどの排他制御をしてもいいし、競合を検出したときに何らかのエラー処理を書いてもいい。
というかプログラマの仕事なんて過半数がそういう通常は通らない例外処理だろうに。
#もしくはシングルタスクOSだけでコード書いてください。
Re: (スコア:0)
本当にそれで頻繁に問題が起きるようならOSレベルで「通常オープンは排他制御、共有アクセスはオプション」扱いにしているよ。
過去のプログラムとの互換性やパフォーマンスへの影響も大きいから「必要ならプログラムで個別に対処してくれ」で済ませている程度の問題でしかないってことだ。
Re: (スコア:0)
マルチタスクだからこそ他が何するかわからない部分は仕様の決めようがないだろ。「想定外」を無くすなら、先に未来永劫も含めて同じOSで動作するアプリケーションの仕様を知っておく必要があるけど、そんなのできる?
というか、何でもかんでもロックかけりゃいいってモノでもないし。
# それとも「ブライト博士の禁止リスト」ならぬ「ブラウザ使用時の禁止リスト」でも作る?
Re: (スコア:0)
他が何をするかわからないからこそ「他のプログラムがオープン中は少なくとも書き込み/削除禁止」を通常オープンにして、それ以外の状態でオープンしたいなら個別にオプション指定するだけでも随分ましになるぞ。
だが現状は「標準オープンは他のプログラムも読み書きOK」で、そこそこ無難そうな「俺が使用中だから他のプログラムは書き込み禁止」ですらオプション扱いだ。
> 何でもかんでもロックかけりゃいいってモノでもないし。
必要ならそれなりにモード指定してオープンすればいい。「標準だとロック」は「必ずロック」とはまるで違うぞ。
OSの既定のファイルオープンモードが「なんでもあり」な理由を合理的に説明してくれよ。
Re: (スコア:0)
Windows では排他状態を指定しない時に「他のプログラムがオープン中は少なくとも書き込み/削除禁止」ですよ。
共有で開くときに明示する必要がありますので、現状の認識がズレてます。
NTFS ならトランザクションはったうえで、ファイル操作すれば、コミットするまで他のプロセスからは変更前の状態のまま同期できますよ。
Linux(Unix系)でそうなってないのは、過去の経緯から、いまさら排他をデフォに出来ないってだけでしょう。
Re: (スコア:0)
てことは、Windowsのブラウザで「これから送信するファイル」として選択した後も変更可能なのは意図的にそうしているってことだね。
Re: (スコア:0)
てことは、Windowsのブラウザで「これから送信するファイル」として選択した後も変更可能なのは意図的にそうしているってことだね。
意図的というより「これから送信するファイル」は「送信中のファイル」ではないからでしょ。
土台、「ファイルを選択したタイミング」「送信ボタンを押したタイミング」のどちらが送信されることをユーザーが望んでいるか、正しく認識するなんてことがコンピューターにできるわけないので、どちらに設定したってユーザーの認識との乖離は発生しうるし。
Re: (スコア:0)
意図的にやってるというか、選択したときはファイル名だけ保持して、実際に送信する段階でファイル開いてるってだけだろう。
Re: (スコア:0)
そりゃわかってるよ。
変更されたくなければ簡単にできるのにあえてやってないってこと。
Re: (スコア:0)
そりゃわかってるよ。
変更されたくなければ簡単にできるのにあえてやってないってこと。
・システム的に変更できないと困る(たとえばログファイルをWebにアップロードしてる間、握り続けられたらログ出力するのに困る。かといってログを書き出す側が握り続けるのも本末転倒)
・他アプリで既に開かれているファイルを送りたいだけなのに、ブラウザが握ろうとして落ちるため送信できない
みたいなタコい事態を防ぐためだろ。
何でもかんでもロックかけて解決って考え方こそマルチタスクには不向きだよ、ロックの弊害を回避する設計がされてないアプリを使うだけでシングルタスクしかできなくなるんだから。
Re: (スコア:0)
だからそういうのがあるから「あえてやってない」と言ってるわけなんだけど…
Re: (スコア:0)
送信中に更新するとか、タイミングによっちゃ送信ファイル壊れそう>chrome、firefox