WindowsのPath取得

🌸桜花🌸 @rofi

@overthestardust @haxe やっぱりエラーになるんですね　　じゃあ少なくとも出力にMAX_PATH以上のバッファが確保されてれば変な挙動される心配はないんですね

はぇ～ @haxe

@rofi @overthestardust あーあー、出力先バッファも呼び出し側が用意するバージョンなのね。

Yosuke HASEGAWA @hasegawayosuke

@rofi @a4lg Shell Lightweight 系のAPI、なぜかMAX_PATH制限あるのが多いです。これはAPIの制限であってファイルシステムとしてはもっと長い。http://t.co/cthewEGmWG

UNAGI𝕏 @unagix

MAX_PATH は Ansi 用だ。Unicode なおまえらには特殊表現用意したから 3 万文字使えるぜ！どうだ嬉しいだろ HAHAHA!。Ansi API に渡るにゃどうするかって？8.3 形式にでもすれば？シランケド。まで読んだ。

Yosuke HASEGAWA @hasegawayosuke

厳密には各要素の長さは255だっけ。https://t.co/S7llgjWw1O

🌸桜花🌸 @rofi

@hasegawayosuke @a4lg Windowsってファイルパスの制約が多いので自分で組むよりかはシステムが提供してくれてる関数使った方が安全かなとか思ってShell Lightweight系のAPIを使おうとしてたのです　　うーん・・・

星くず彼方に @overthestardust

@rofi そのはずです。たぶん。もちろんエラーチェックはちゃんとする必要はありますが。　PAthCch系がもっと早くVistaで実装されてればよかったのになぁ…

Tsukasa #01 @a4lg

@rofi 少なくとも shell 系の API は制限キツすぎワロタ的なモノが結構あるので場合によってはオススメしづらいです。

🌸桜花🌸 @rofi

http://t.co/CcRsaSYpK8 　完全な命名規則書いてあるけど…これ全部読んで自力で実装するのもなぁ・・・ふぇぇ

🌸桜花🌸 @rofi

@overthestardust ですよねー、どうして今のいままで放置されてたのか…　＞PathCch系

🌸桜花🌸 @rofi

@a4lg うぅぅ・・・でも代替関数がないんですよねー　　やっぱり仕様読んで実装するのが一番なのですかねぇ。。。

Tsukasa #01 @a4lg

@rofi ただシェル系の API は副作用というかなんというか、MAX_PATH 長の文字列にすべて制限する関係上、シェル API でちゃんと扱えてるならだいたい Windows エクスプローラから扱えるファイルができるので、まぁ……時と場合により。

Tsukasa #01 @a4lg

oO( Win32 API で扱えているファイルが Windows エクスプローラでちゃんと扱える保証は、残念ながらない。というか、長い (エクスプローラから削除できない) フォルダ名を普通に Windows システムが作ってくる。シェル制限は結構厳しい。 )

Yosuke HASEGAWA @hasegawayosuke

@rofi @a4lg 引数を \ で分解して要素ごとに Shell Lightweight APIに渡す。

Tsukasa #01 @a4lg

@hasegawayosuke なるほどその手があったか(ぇ

Yosuke HASEGAWA @hasegawayosuke

@a4lg PathMatchSpec とか自分で実装したくないので、それ実際にやってます。

UNAGI𝕏 @unagix

MAX_PATH でパス長切ってくるバックアップシステムとかコケたりする闇とかある。

🌸桜花🌸 @rofi

結論：やっぱりWinのファイルパスは面倒（

🌸桜花🌸 @rofi

CONCON問題もあるしなー　　でもうまいことやればCONってファイルも作れるしほげほげ・・・