- PR -

ファイルのチェック

投稿者投稿内容
ホーガン
常連さん
会議室デビュー日: 2008/02/18
投稿数: 42
投稿日時: 2008-02-29 19:07
<INPUT type="file"〜>を使用してファイルアップロード
(クライアントからサーバーにCSVファイルをアップロード)
する場合、クライアント側にそのファイルが存在するか
どうかのチェックは、通常どのように行うものなのでしょうか。

ファイル存在チェックで調べてみると以下のサンプルコードが見つかりました。
−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−
<%
Set objFso = Server.CreateObject("Scripting.FileSystemObject")

If objFso.FileExists("c:\a.txt") Then
Response.Write "ファイルが存在します"
End If

Set objFso = Nothing
%>
−−−−−−−−−−−−−−−−−−−−−−−−−−−−
この記述で、クライアント側のPCのファイルチェックが出来るという
ことなのでしょうか。SUBMITされた時にこの処理を起動
する?という感じで可能ですか。
初歩的な質問ですいませんが、ご教示願えませんでしょうか。
くまっち
大ベテラン
会議室デビュー日: 2008/01/18
投稿数: 169
お住まい・勤務地: 茨城県のどこか。
投稿日時: 2008-02-29 20:07
提示コードは、サーバー側でのファイルチェックですね。

ですが、クライアント側でチェックする為の良いサンプルかと。
FileSystemObjectについては下記サイトをごらんください。
MSDN FileSystemObjectの概要

クライアント側でFileSystemObjectを使い、存在確認等すれば良いと思います。
ちゃっぴ
ぬし
会議室デビュー日: 2004/12/10
投稿数: 873
投稿日時: 2008-03-01 00:51
そもそも file の存在確認なんて必要でしょうか?

ぶっちゃけ timing によっては確認したところで失敗する可能性があるわけで、file 操作の基本はその操作を実際にやってみて成功したか否かで判断することです。

それに client script で FSO の利用は security 制限に引っかかって使えなかったかと。

ActiveX 使えば別ですけど。
_________________
くまっち
大ベテラン
会議室デビュー日: 2008/01/18
投稿数: 169
お住まい・勤務地: 茨城県のどこか。
投稿日時: 2008-03-01 03:05
引用:

そもそも file の存在確認なんて必要でしょうか?
ぶっちゃけ timing によっては確認したところで失敗する可能性があるわけで



それを言っちゃ・・・。 Client Validation は必要でしょうか?と言ってる様な気もしますよ。。。
確認せずポストした場合、存在しないファイルを指定していたら
0バイトのファイルとしてポストされますので
仕様によっては事前チェックも必要になるのではないでしょうか。
Clientで判断できることはClientで判断しても良いと思います。
(もちろんサーバ側で、再度チェックはすべきですが)

引用:

file 操作の基本はその操作を実際にやってみて成功したか否かで判断することです。


そうなんですか?
失敗=例外発生という操作もありますよね?
出来る限り、例外発生させないコーディングをすべきなのでは?と思います。
ちゃっぴ
ぬし
会議室デビュー日: 2004/12/10
投稿数: 873
投稿日時: 2008-03-01 05:26
引用:

くまっちさんの書き込み (2008-03-01 03:05) より:
それを言っちゃ・・・。 Client Validation は必要でしょうか?と言ってる様な気もしますよ。。。
確認せずポストした場合、存在しないファイルを指定していたら
0バイトのファイルとしてポストされますので
仕様によっては事前チェックも必要になるのではないでしょうか。
Clientで判断できることはClientで判断しても良いと思います。
(もちろんサーバ側で、再度チェックはすべきですが)



いらないと思ってますよ。結局 server 側で必要であれば 0 Byte ならほにゃららとゆう処理を組み込むのが必須になるわけですから。

事前に判断できる可能性があるという意味でやってもかまいませんけど、今回の場合その処理の作りこみに結構な costs がかかるんじゃないでしょうか?そこまでするべきだとは思いませんけど。

引用:

引用:

file 操作の基本はその操作を実際にやってみて成功したか否かで判断することです。


そうなんですか?



事前に確認しようと timing により失敗する可能性がありますよね?
結局のところ、失敗したときの処理は絶対に組み込まないといけないのです。

確認が確実に意味を持つのは対象が完全に自分の制御下に置かれているものに対して確認を実施するときに限られます。

代表的なものとしては、private memory とかがそれにあたりますね。
Multi thread で動作させていなければ private memory は動作している application が占有するので、確認した結果がその application で行う sequential な処理で変更されていない限り結果が保証されます。

C のような言語では確保した buffer 以上の書き込みを行うと buffer overflow しますから、このような対象に対して絶対に確認を行わないといけませんね。

Multi thread 環境であれば対象の buffer を lock してから確認することになるでしょう。この場合も同様事前に確認したことが変化しないことが保障されます。

ですが、今回の対象は file です。こちらはその対象の application で確認を行ったところで、実際の処理を行うまでに別の application によって対象が変化する可能性を否定できません。

Multi thread 同様、事前に lock してから処理を行えば問題ないんですが、ところがどっこい Windows の API はそういう処理を簡単には行えないようにできているんです。

もっとも今回の場合、存在確認ですね。事前に lock を取得する処理ができるとしても、対象がない可能性があるわけですから結局 lock を取得できるか否かで判断することになります。

ここら辺を誤解していると場合によっては TOCTOU (Time-Of-Check, Time-Of-Use) 脆弱性を作りこむ危険性があるので早いうちから理解しておくべきことだと思います。

引用:

失敗=例外発生という操作もありますよね?
出来る限り、例外発生させないコーディングをすべきなのでは?と思います。



例外を発生させない cording を実施すべきというのは performance を意識した結果の発想ですよね。

確認結果が確実に保障されるのであれば、事前に確認するべきだと私も思います。
ただ、今回の場合絶対に保障はされないわけです。

そのような場合、事前に確認することが performance tuning として有効であるか?
もちろん処理の内容およびその処理を呼び出す回数にもよるでしょうが、今回の場合さほど有効であるとは思いません。

大量の file を扱う場合には多少の効果がある場合もあるでしょうが、そこまで支払うべき costs ですか?逆に複雑になって、bug を作りこむ可能性もあります。

個人的には simple に成功したか失敗したかだけで条件分岐することにとどめ、どうしても performance tuning が必要な場合のみ改めて検討するというのが最適だと思っています。多くの場合、検討すること自体まず発生しないと思いますが。

文書推敲
_________________
ちゃっぴ@わんくま同盟
ちゃっぴの監禁部屋

[ メッセージ編集済み 編集者: ちゃっぴ 編集日時 2008-03-01 05:43 ]
くまっち
大ベテラン
会議室デビュー日: 2008/01/18
投稿数: 169
お住まい・勤務地: 茨城県のどこか。
投稿日時: 2008-03-01 08:01
質問者のファイルチェックうんぬんに関して言えば
1.ファイルがない場合
2.ファイルはあるが0バイトの場合
3.ファイルがあり1バイト以上の場合
というケースがありますよね。
そこでサーバー側だけで、0バイトかどうかで判断したら
1と2の区別が出来なくなるので、一概に存在確認は無駄だというのは
如何なものでしょう?と思ったわけです。ここは仕様次第ですよね。
存在有無だけなら、さほどコストは掛からないでしょう。数行程度で済むと思います。
ここにファイルのロックを組み込むとなれば、相当なコストだと思いますけど。


ファイル操作に関して言えば、ちゃっぴさんの言いたいことは理解できます。
(blog記事も読ませていただきました。)

でもこれって「こうすべきである」(基本)というレベルではなく
「私ならこうします」(提案)というレベルですよね。

私が「例外発生させないコーディングをすべきでは?と思います。」と申したのは
私の考えを述べたまでで「例外発生させないコーディングをすべき」と言いたいわけではないです。
「すべきではないのかぁ〜?って思うんだけど・・・」というニュアンスです。

私は出来る限り例外に頼らない(本当に例外的な場合を捕らえる)ようにコーディングをしたほうが
出来るだけ多くの人がコードを理解しやすいのではないかな?って思っているので。


ちゃっぴさんの意見が間違っているとは思いません。
自分の意見が間違っているとも思いません。

結局は、それぞれのコーディングスタイルではないでしょうか。

「普通、確認はしない。結果で判断するのが基本。だから不要」と
上から決め付けたような意見に受け取れたので、レスつけた次第です。
indigo-x
大ベテラン
会議室デビュー日: 2008/02/21
投稿数: 207
お住まい・勤務地: 太陽の塔近く
投稿日時: 2008-03-01 08:38
クライアント数が少ない場合はActiveXを作るのも問題ないと思いますが、
規模が大きい場合、運用でエライ事になるとおもいます(IEのセキュリティ設定で)

 ・少なければActiveX
 ・多ければサーバーのみでチェック
でどうでしょうか?

あと、あくまでも参考ですが
 ファイルの有無と0Byteファイルの違いは先頭にヘッダーを入れて0Byteはありえない
 仕様にするのはどうでしょう?
ホーガン
常連さん
会議室デビュー日: 2008/02/18
投稿数: 42
投稿日時: 2008-03-01 09:32
ちゃっぴさん、くまっちさん、indigo-xさん、回答ありがとうございました。
すごく参考になりました。
そもそも、サーバー側だけで、0バイトかどうかで判断できること
は思っていませんでした。(お恥ずかしい)クライアント側で参照ボタンを
押下して指定したファイルのデータをサーバーに送信するので
サーバーに行く前に何らかのエラーがシステム例外として発生してしまう
のかと思っていました。ファイルがあろうがなかろうが、読めようが読めまいが
サーバーに要求が行き、サーバー側で0バイトかどうかでチェックできる
のであれば、それで今回の要件は満たされると思います。

indigo-xさん
引用−−−−−−−−−−−−−−−−−−−−−−−−−
クライアント数が少ない場合はActiveXを作るのも問題ないと思いますが、
規模が大きい場合、運用でエライ事になるとおもいます(IEのセキュリティ設定で)
引用−−−−−−−−−−−−−−−−−−−−−−−−−

クライアント数は、70クライアントなのですが、
「規模が大きい場合、運用でエライ事になるとおもいます」というのは
 IEの設定でActiveXを使用可能にするという設定が、大変だという意味でしょうか。
 今回は、導入時にクライアントPCを新規に導入します。
 そのタイミングで、IEの設定(ActiveXを使用可)をするだけで
 ActiveXを使用した時でも問題ないのかなと思っています。
 ActiveXを使用した場合に、もっと違う懸念点があればご教示願えません
 でしょいうか。
 ActiveXは、スクリプトを埋め込んでクライアント側で動作させるので
 大抵の事は可能だが、その分セキュリティ上問題があるぐらいで
 理解しているのですが、甘いでしょうか。 



スキルアップ/キャリアアップ(JOB@IT)