アカウント名:
パスワード:
作成または開く対象のオブジェクトの名前を保持している、NULL で終わる文字列へのポインタを指定します。 Windows NT/2000：この関数の ANSI 版では、名前は最大 MAX_PATH 文字に制限されています。この制限をほぼ 32,000 ワイド文字へ拡張するには、この関数の Unicode 版を呼び出し、パスの前に "\\?\" という接頭辞を追加してください。詳細については、MSDN ライブラリの「」（ファイル名の規則）を参照してください。 Windows 95/98：文字列の長さは、最大 MAX_PATH 文字です。
Windows 95: 有効なディレクトリまたはパスおよびファイル名を表す、NULL で終わる文字列へのポインタを指定します。この文字列には、ワイルドカード文字（* と ?）を含めることができます。この文字列の文字数は、MAX_PATH の値以下にしてください。 Windows NT/2000: 有効なディレクトリまたはパスおよびファイル名を表す、NULL で終わる文字列へのポインタを指定します。この文字列にはワイルドカード文字（* と ?）を指定することができます。 既定のパス文字列の最大長は、MAX_PATH に指定された文字数です。この制限は、FindFirstFileEx 関数がパスを解析する方法と関係あります。この制限を超えて MAX_PATH に指定された文字数より長いパスを送信するには、パスの前に "\\?\" を付加して FindFirstFileEx 関数のワイド（W）バージョンを呼び出します。"\\?\" を付加すると、関数はパスを解析しないため、FindFirstFileEx 関数で MAX_PATH より長いパスを使うことができます。ただし、パスに含まれる各構成要素は、MAX_PATH の文字数を超えないようにしてください。この方法は、UNC 名にも適用できます。"\\?\" はパスの一部として無視されます。たとえば、"\\?\C:\myworld\private" は "C:\myworld\private" と解釈されます。また、"\\?\UNC\bill_g_1\hotstuff\coolapps" は、"\\bill_g_1\hotstuff\coolapps" と解釈されます
linuxだとVFSで255バイトまでに制限されていますね。
パスとファイル名全体で256バイトを越えるとクライアントPCから
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
あつくて寝られない時はhackしろ! 386BSD(98)はそうやってつくられましたよ? -- あるハッカー
階層が深くなったりファイル名が長くなると (スコア:4, 参考になる)
Windows Serverのためかどうか分からないのですが、「日付」＋「件名」等で管理している時に、件名が長くなったり、階層が深くなって、パスとファイル名全体で256バイトを越えるとクライアントPCからはファイルを開けないことが多々あります(ありました)。その都度、一旦、PCのデスクトップにファイルをコピーして開くという間抜けなことをする羽目に。
ファイル名に意味を持たせるというのが不味いのかなと。
Re:階層が深くなったりファイル名が長くなると (スコア:5, 参考になる)
MSDNのCreateFile関数より [microsoft.com] MSDNのFindFirstFile関数 [microsoft.com]より つまり対応させる為には9xとNTで処理を書き分けるか、9xを切り捨てるかをしないとだめっす。
ちなみにマイナーなフリーソフトを作っていて、あるバージョンからめんどくさくなって9xを切り捨てましたけど苦情は一切きませんでした。
そもそも感想も一切きてませんけど(´･ω･｀)
Re:階層が深くなったりファイル名が長くなると (スコア:4, すばらしい洞察)
確かに。
ドキュメント作成日時、更新日時はファイル自身が知っている情報を使ったほうが便利ですね。
頻繁に使っている情報は、エクスプローラーで更新日時順で並び替えれば解るけど、
ファイル名の日付で管理して意味があるのは、いつ更新しようとドキュメントの内容と日付に意味がある場合、
議事録とか稟議書とか、個人では日記とかそういう場合に限っては便利だと思います。
メールなんかも、到着日付順で新しいメールが上に来るようにしてる人結構いますよね。
とくに受信トレイの場合、どうせ用があるのは新着なのだからスクロールの手間は不要だから。
秘書さんとか上級のプロマネとか、蓄積される仕事の整理自体が仕事の人は別として、
殆どの場合、右から来た文書に記入して、左へ受け流すスピードが重要だったりします。
それで、手元のものは仕掛中のものは適当にフォルダに分けて管理しても、一旦区切りがついたものを後で引っ張り出す時は、
Googleデスクトップなどを使えばいいやと割り切ってOKいいんじゃないかなと思います。
一度決めたルールを頭に入れて作業しなければ意味がなくなるような管理方法に縛られる、
一度決めたルールに縛られて無意味な制約がストレスになる必要が無いのが、電子ファイル化するメリットだったはず。
わざわざ電子化して、人間に負担をかけて得られるメリットは自己満足だけでは本末転倒でしょう。
整理に躍起になったドキュメントほど、誰も読まない学級新聞化してしまうという法則もある。
Re:階層が深くなったりファイル名が長くなると (スコア:3, 興味深い)
linuxだとVFSで255バイトまでに制限されていますね。
Re:階層が深くなったりファイル名が長くなると (スコア:5, 参考になる)
こっちは c:¥longlongdirname¥....¥longlongfilename.doc の合計文字数の上限。（サーバ上だと？）
こっちはディレクトリ名 longlongdirname やファイル名 longlongfilename.doc の個々の文字数の上限。パス名全体ではありません。
だと思うので、制限のきつさが全然違いますね。
Re:階層が深くなったりファイル名が長くなると (スコア:1, 参考になる)
# なんか安易すぎといつも思う。
Re:階層が深くなったりファイル名が長くなると (スコア:2, おもしろおかしい)
ってDBは問題なかったんだろうか…？
Re:階層が深くなったりファイル名が長くなると (スコア:2, 興味深い)
フォルダ構造を維持して焼きたいのにそれができない。
かといって、tarで固めてしまうと、ディスクを覗いただけでは中身が分からなくなるという。
Re:階層が深くなったりファイル名が長くなると (スコア:1)
回避方法というとrarで固めてコメント書くとかツリー構造を
テキストファイルに書きだしておくくらいしかないかなぁ
お客さんの所に持って行くだけのときは大抵リムーバブルHDDか
USBメモリに入れて持って行くのですが、メディア納品の時は
結構悩みます。
まぁ、そういう状況はトラブったHDDのバックアップの納品と
言うのが大半なんですが。
SUBSTコマンド (スコア:2, 参考になる)
SUBSTコマンドで長いパスにドライブ名を割り当てて、割り当てた
ドライブで255文字以内に収まるようにするとアクセスできるようです。
（割り当てたドライブのルート（つまりどこかのパス）に
Recycledフォルダとか勝手に作る場合があったり、
ネットワークドライブにSUBSTすると何のオプションも
つけないSUBSTコマンド（ドライブ割り当ての一覧表示）
がこけるとかの問題もあるのですが）
『月面兎兵器ミーナ』2007年1月13日から放送開始
とってもオフトピ(スコア：-x,どうでもいいことだが) (スコア:1)
・・・それってまだ放送してますか？
# どのみち放送されていないど田舎なので本当にどうでもいいが。
Re:とってもオフトピ(スコア：-x,どうでもいいことだが) (スコア:1)
すみません時代遅れな署名で orz
そろそろ署名変えようかな……
DVDも出てますが、「どんなものかちょっと見てみたい」程度なら
フジテレビのインターネット配信 [fujitv.co.jp]がお手ごろかもしれません。
>どのみち放送されていないど田舎
ちなみにミーナはフジテレビのみで放送されたので
ど田舎でなくても見られないところが多かったらしいです。
（1ヶ月遅れでBSフジでも放送が始まった）
『月面兎兵器ミーナ』2007年1月13日から放送開始
Re:階層が深くなったりファイル名が長くなると (スコア:1)
そこでWinFSの出番だったはずなんですが・・・
Vistaぽしゃったせいで当分日の目を見ないんだろうなぁ・
Re: (スコア:0)
\\SERVER
\\SHARE
等といういい加減だが短い名前に