アカウント名:
パスワード:
以下のリンクにある例は現在の最新の日本語版samba-2.2.8aでも再現します。 http://www.samba.gr.jp/project/kb/J0/0/49.html [samba.gr.jp]
samba-2.2.5からは新しいオプションを追加すればかなり可能性は減るようです http://www.samba.gr.jp/news-release/2002/20020621-1.html [samba.gr.jp]
今だに8.3形式でファイルを取り扱うアプリはどれくらいあるのでしょう?
それってつまり、Windowsの問題可能性 + Sambaの問題可能性で両方とも使うなってことでOK?
samba 1.9.x の時に8+3 名前変形の問題が気になって手を入れたのですが、 かなり無理があるという結論に達しました(解決方法はまだ残っているかも しれないけど)。
突き当たった問題は samba で共有したディレクトリを NFS やそのホスト 自身のユーザーによってアクセス(作成、削除、名前変更)するのに応じ て、LFN 対 SFN のマッピングも更新しなければ矛盾が生じてしまう事でした。 samba 以外でアクセスしてはダメというルールならば深刻にならずに 済みます。かといって、アクセスの都度 LFN ハッシュの SFN に衝突が 無いか検査しようとすると、ファイル数が多くなればなるほど重くな ります。確かファイル一覧を取ろうとすると N^2 オーダー(N=ファイル数) の処理時間を潰したかな(私の考えが足らないだけかもしれないけ ど)。
結局 FILEA~xx.EXT の x の文字数と種類を増やして、衝突確率を下げる のが精一杯。確率が 1/1300 と言うが「クラスの中で誕生日が同じ人問題」 の様に実感は結構衝突する。
(samba を動かしていた) Solaris に Win32 の FindFirstChangeNotification に似た機能が有ればなぁと思いました。
DOS時代に開発された業務アプリを継続して使用している企業は少なくないと思います。
が、問題は8.3形式でしかファイルを扱えないアプリを使うような環境で、ロングファイルネームを使ってしまう(しかも8.3形式になったときに問題が生じるようなファイル名で)ということにあるのではないでしょうか。8.3形式に収まっているファイル名であれば問題は生じないわけでしょう?
ロングファイルネームを参照できる環境と、参照できない環境とではファイル名の見え方が違うわけで、問題が生じる以前に気づくと思うのですが...
特に数字のみでのファイル名はかなり危険だったような。
これって本当なんですか? 再現性のあるバグだとしたら、sambaの関係者は意図的に隠しているとしか思えないですね。O'ReilyのUsing Sambaにもそんな記述はなかったと思うし。sambaベースのネットワークHDDとかも同種の問題を抱えることになると思いますが、その手の警告はなかったような...
「Samba は同じ長いファイル名は、常に同じ mangle 名に短縮することに留意すること。Windows ではその限りではない」これって、つまりどういうときに障害が発生すると指摘してるの?
↑が条件になりそうなのはわかるけれど。
僕の感性では
ロングファイルネームが短縮されたときにどのように命名されるか理解させるのは骨だから「とにかく8+3でファイル名を決めてください」とレクチャーしませんかね。
#運が悪ければ事故に遭う、というのではなくて、必ず事故るが運が悪くない限り怪我はしない、と言われてるようなものですし...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常
sambaを安心して使えますか? (スコア:3, 興味深い)
たとえば8.3ファイル名を扱うソフトがあった場合にファイルが上書きされてしまう、ファイルのパーミッションがおかしくなるなどでした。
Sambaベースのファイルサーバは結構あちらこちらから出ていますが、この辺の対処ってどうなんっているんでしょう?
契約上「ファイルが消えても責任とりません」と書いてあるのだとは思うのですが、使うソフトによってはかなりの頻度でファイルが消えたりするはずだから、クレームもかなりきているんじゃないのかなと。
May the 4th B w/z U
Re:sambaを安心して使えますか? (スコア:5, 参考になる)
短いファイル名は、長いファイル名の先頭5文字 + ~ + 適当なalnum + 適当なalnum という具合に生成しています。 下2つの alnum は、ファイル名のハッシュ値から生成しており、 また A-Z0-9 の 26 * 26 なので約1/1300という確率でぶつかるわけです。
どうしても短い名前が競合するなら、smb.conf にて mangling method = hash2 などと指定するといいかも知れません。
それでもダメなら、ハッシュ値を求める部分に alnum だけでなく # や $ などの記号も含める patch を書いてください。
Re:sambaを安心して使えますか? (スコア:2, 参考になる)
いつからこうなっていたのかは追いきれていませんが、最近になっての変更ではなく、少なくとも 2.0.x の時代からそうなっていたようです。
すなわち、( 26 + 10 + 7 ) ^ 2 なので、約1/1800の確率で名前が衝突する、ということになります。
また、短い名前(SFN)が動的に生成されるということは、SFNが衝突するだけでなく、長い名前(LFN)を使うアプリケーションAがLFNを変更すると、SFNを使うアプリケーションにもその影響が及ぶ、という問題もあります。
ちなみに 3.0.0beta1 では mangle method = hash2 になっていますが、hash2 の場合、mangling char パラメータが無視されて常に ~ が使われるようです。
Re:sambaを安心して使えますか? (スコア:1)
- A-Z0-9 の 26 * 26 なので約1/1300
+ A-Z0-9 の 36 * 36 なので約1/1300
Re:sambaを安心して使えますか? (スコア:2, 参考になる)
以下のリンクにある例は現在の最新の日本語版samba-2.2.8aでも再現します。
http://www.samba.gr.jp/project/kb/J0/0/49.html [samba.gr.jp]
samba-2.2.5からは新しいオプションを追加すればかなり可能性は減るようです
http://www.samba.gr.jp/news-release/2002/20020621-1.html [samba.gr.jp]
今だに8.3形式でファイルを取り扱うアプリはどれくらいあるのでしょう?
Re:sambaを安心して使えますか? (スコア:2, 参考になる)
Windowsでプログラミングしていると、突然8.3形式のファイルを扱うことになって驚くことがあります。
例えば、ファイルをドラッグ&ドロップすると、ドロップされたアプリが受け取るファイル名は8.3形式で、ロングファイル名が必要な場合は自分で変換しなくてはいけません。
sambaでファイルサーバを作成した場合、ドラッグ&ドロップでファイルをやり取りするなんてのは日常的に行われる作業になるでしょうが、そのときは危険な8.3形式で扱われている可能性が高いです。
私は、例え1%以下でも回復不能な事故が起こる可能性があるものは使うに値しないと考えるので、このバグ(仕様?)がどうにか回避可能になるまでsambaを使うことは無いでしょう。
#間違ってるかもしれないのでAC
Re:sambaを安心して使えますか? (スコア:1, おもしろおかしい)
ならWindowsは使うに値しないと思われ・・・
Re:sambaを安心して使えますか? (スコア:0)
>ならWindowsは使うに値しないと思われ・・・
それってつまり、Windowsの問題可能性 + Sambaの問題可能性で両方とも使うなってことでOK?
Re:sambaを安心して使えますか? (スコア:1)
下のほーにあるこの問題の可能性を下げるパッチを作ったのは私なんですが、公開しても意外に反響がなくてびっくりしました。
多分、この問題を認識していない人がたくさんいるのかなと。雑誌の特集とかもこの話をみたことはないし、ドキュメントをよく読めば書いてあるんですが、D&Dで発生する可能性があるはいま初めて分かったし。
ファイル共有はWebDAVとかにうつっていくんでしょうか?今の所、普通にWindowsで使えるWebDAVサーバってあります?
May the 4th B w/z U
Re:sambaを安心して使えますか? (スコア:0)
> このバグ(仕様?)がどうにか回避可能になるまでsambaを使うことは無いでしょう。
たまに回復不能な事故がおきる Windows を日々
Re:sambaを安心して使えますか? (スコア:1)
Re:sambaを安心して使えますか? (スコア:0)
隠しファイルかなんかでファイル名の対応表を持たせれば解決する気もするんですが、そんなに単純な問題じゃないんでしょうか。
Re:sambaを安心して使えますか? (スコア:1, 興味深い)
samba 1.9.x の時に8+3 名前変形の問題が気になって手を入れたのですが、 かなり無理があるという結論に達しました(解決方法はまだ残っているかも しれないけど)。
突き当たった問題は samba で共有したディレクトリを NFS やそのホスト 自身のユーザーによってアクセス(作成、削除、名前変更)するのに応じ て、LFN 対 SFN のマッピングも更新しなければ矛盾が生じてしまう事でした。 samba 以外でアクセスしてはダメというルールならば深刻にならずに 済みます。かといって、アクセスの都度 LFN ハッシュの SFN に衝突が 無いか検査しようとすると、ファイル数が多くなればなるほど重くな ります。確かファイル一覧を取ろうとすると N^2 オーダー(N=ファイル数) の処理時間を潰したかな(私の考えが足らないだけかもしれないけ ど)。
結局 FILEA~xx.EXT の x の文字数と種類を増やして、衝突確率を下げる のが精一杯。確率が 1/1300 と言うが「クラスの中で誕生日が同じ人問題」 の様に実感は結構衝突する。
(samba を動かしていた) Solaris に Win32 の FindFirstChangeNotification に似た機能が有ればなぁと思いました。
Re:sambaを安心して使えますか? (スコア:0)
今回のケースと同列に扱うのは技術者らしいとはいえないなぁ。
もちろんWindowsにもはっきり判っている(Microsoftも認知している)問題点があるし、それが回避できないなら、ふつうにWindows捨ててるでしょ?
Windowsを安心して使えますか? (スコア:4, 参考になる)
8.3なアプリを運用しているPureMSなシステムでも運用制限は必要です。
ではMS版消えるファイルの手順を、とりあえずWin98SEで
1. エクスプローラで、カラのディレクトリ\temp1\testを作成
2. 同じく\temp1\test\aaaaaaaaa.txtと\temp1\aaaaaa~1.txt,\temp1\aaaaaa~2.txtを作成
※このときaaaaaaaaa.txtとaaaaaa~1.txtの8.3はaaaaaa~1.txt、aaaaaa~2.txtはaaaaaa~2.txtとなること
3. エクスプローラで、\temp1\aaaaaa~1.txtを\temp1\test\へ
※このときaaaaaaaaa.txtの8.3はaaaaaa~1.txt、aaaaaa~1.txtはaaaaaa~2.txtはとなる
4. DOS窓からcd \temp1\test
5. DOS窓からcopy ..\aaaaaa~2.txt .
※ここで上書きするか聞いてくるのでy
6. あれ・・・・aaaaaa~1.txtしかない
見事にaaaaaaaaa.txtとaaaaaa~2.txtが消える(w
Re:Windowsを安心して使えますか? (スコア:0)
# ちなみにMEでもできた
# 1ファイルで2つも消すなんてsambaに勝ち目はありませんわ
Re:Windowsを安心して使えますか? (スコア:0)
そんなファイル名を付ける方がどうかと思う。
実際にはそんなファイル名は私は付けないから、sambaよりは
安全だと感じたがどうだろう。
Re:sambaを安心して使えますか? (スコア:0)
何も使えないな。それじゃ。
#ある意味、すごいと思う。
#どんな生活をしているのか是非教えてもらいたい。
Re:sambaを安心して使えますか? (スコア:0)
何杯ものめば,アルコールビールを1杯以上のんだのと同じ。
1%以下といってもいろいろあるわな。
Re:100回に1回ってものすごく多いよ (スコア:0)
100回に1回事故が起こるような電車を使って通勤するようなものかな?
自分が乗っている電車では事故がおきないことを祈りつつ。
Re:100回に1回ってものすごく多いよ (スコア:0)
Re:100回に1回ってものすごく多いよ (スコア:0)
JR中央線の事故はもう少し頻度が高いみたいですよ。
Re:100回に1回ってものすごく多いよ (スコア:0)
1-(99/100)^100は、1に満たないよ。
Re:sambaを安心して使えますか? (スコア:0)
1回あたりの確率は1/1300でも、事象としては必ず起きるんだからね。
Re:sambaを安心して使えますか? (スコア:1, 参考になる)
DOS時代に開発された業務アプリを継続して使用している企業は少なくないと思います。
が、問題は8.3形式でしかファイルを扱えないアプリを使うような環境で、ロングファイルネームを使ってしまう(しかも8.3形式になったときに問題が生じるようなファイル名で)ということにあるのではないでしょうか。8.3形式に収まっているファイル名であれば問題は生じないわけでしょう?
ロングファイルネームを参照できる環境と、参照できない環境とではファイル名の見え方が違うわけで、問題が生じる以前に気づくと思うのですが...
Re:sambaを安心して使えますか? (スコア:1, 参考になる)
特に数字のみでのファイル名はかなり危険だったような。
11111111.dat
111111111.dat みたいなファイルは上書きされた気がします。
Re:sambaを安心して使えますか? (スコア:1)
数字部分が違うだけのファイル名に対する SFN が衝突する確率は 1/20 に上がるようです。ちなみに通常は 1/1300 だそうです。
Re:sambaを安心して使えますか? (スコア:0)
なんてのはかなりヤバイと。
testcase[連番].dat
なんてのも利用頻度高いしなぁ。
Re:sambaを安心して使えますか? (スコア:0)
直されているのでは?
私は、ファイルが消えてこまったことはないですね。
エクスプローラ以外から触ったことないし。
# ソフトに直接触らせるのは怖い
Re:sambaを安心して使えますか? (スコア:0)
これって本当なんですか? 再現性のあるバグだとしたら、sambaの関係者は意図的に隠しているとしか思えないですね。O'ReilyのUsing Sambaにもそんな記述はなかったと思うし。sambaベースのネットワークHDDとかも同種の問題を抱えることになると思いますが、その手の警告はなかったような...
Re:sambaを安心して使えますか? (スコア:5, 参考になる)
5.4 ファイル名の短縮 (Name Mangling) と大文字小文字 [samba.gr.jp]から引用
--
この規則により、Windows for Workgroups 経由でネットワークにアクセスしないといけない不幸な人も、二つのファイルを区別することが可能になる。Samba は同じ長いファイル名は、常に同じ mangle 名に短縮することに留意すること。Windows ではその限りではない。この方式では、ファイル名の重複の可能性は皆無ではない。しかしその可能性は激減している。
--
Re:sambaを安心して使えますか? (スコア:0)
「Samba は同じ長いファイル名は、常に同じ mangle 名に短縮することに留意すること。Windows ではその限りではない」これって、つまりどういうときに障害が発生すると指摘してるの?
↑が条件になりそうなのはわかるけれど。
僕の感性では
Re:sambaを安心して使えますか? (スコア:0)
という姿勢ではトラブルはなくならないかと。
骨でもちゃんと道理を説きましょう。
Re:sambaを安心して使えますか? (スコア:0)
かなりメジャーな類のバグではないかと…
http://www.samba.gr.jp/project/kb/
このあたりにも書いてあるのでは?
Re:sambaを安心して使えますか? (スコア:0)
Re:sambaを安心して使えますか? (スコア:1)
May the 4th B w/z U
Re:sambaを安心して使えますか? (スコア:0)
#運が悪ければ事故に遭う、というのではなくて、必ず事故るが運が悪くない限り怪我はしない、と言われてるようなものですし...
Re:sambaを安心して使えますか? (スコア:1, おもしろおかしい)
#Samba も Windows も運用で逃げつつ業務に使っているのでAC
Re:sambaを安心して使えますか? (スコア:1, おもしろおかしい)
せっかくなので #334908 に対してのコメントを希望。