Linux-NTFS βリリース 88
ストーリー by GetSet
求む、人柱 部門より
求む、人柱 部門より
掲載が遅れたが、fatよさらば曰く、"本家記事によると、Linux-NTFS projectはLinuxにおいてNTFS(32bit、little-endian)の読み書きをサポートするドライバのベータ版を公開したとのこと(Linux-NTFS-devのMLアーカイブ：ベータ版ソースtgzへのリンクあり)。
tarに入っていたREADMEによると、暗号化されたファイルへのアクセス、圧縮されたファイルの書き込み、ファイルの所有者とアクセス権限の変更は出来ない。これは、Knoppix 3.4が採用した Captive NTFSとは異なり、ntfs.sys等を利用しないもの。Knoppix 5.0で採用されたNTFS読み書きドライバがこれでしょうか?（ITProの記事、5.0.1日本語版公開時の/.Jストーリー）。"
とりあえず入れてみました。 (スコア:5, 参考になる)
それにntfs-3g-20070714-BATA.tgz(日付が変?)をmake installして、あっさりNTFSをマウントできました。
特に指定もせずNTFSをmountすると、こんな感じです。
# ntfs-3g /dev/hda1 /mnt/ntfs
# mount
/dev/fuse on /mnt/ntfs type fuse (rw,nosuid,nodev,noatime,default_permissions,allow_other)
このときのログが
ntfs-3g[17321]: Version 2006-07-14-BETA
ntfs-3g[17321]: Mounted /dev/hda1 (Read-Write, label "", NTFS 3.1)
環境はPlamo-4.2 + kernel-2.6.17。
一応ファイルの新規作成と書き込みはできてますが、vfat並に気軽に使えるのかどうかは、WinとLinuxをひっきりなしに切り替えないと分らないだろうな(beta版だし)。
Re:とりあえず入れてみました。 (スコア:1)
俺も人柱になりたいけど、やっぱ怖いよなぁ。
良く理解してないんだけど、ユーザーモードって事はブートは出来ないんかな？
/bootだけext3にすれば動くとか？
もしOKなら、マルチブート環境で相互のドライブにアクセスできるし、幸せになれる人も多いでしょうね。
#Linuxでデフラグってのは微妙だけどね。
今に満足をしているってのは、上を目指さない理由にはならない。
まだ少しでも探求心が残っているなら今すぐubuntuを試してみよう。
Re:とりあえず入れてみました。 (スコア:4, 参考になる)
次に、ルートパーティションがNTFS上にあるのだとすればinitrdにLinux-NTFSを動かすために必要な全てのものを詰め込む必要があるでしょう。こちらも理論的には不可能ではないと思います。
しかし、それでもおそらくNTFS上でLinuxは茨の道です。
まず、スペシャルファイル（デバイス、パイプ、ソケットなど）を置けるかどうか非常にギモンです。さらに、パーミッション設定ができないと用心深いソフトウェアはうまく動いてくれないことがあります。
個人的にはNTFSを使ったデュアルブート環境での共有は部分的な（ホームディレクトリ等）ディレクトリに限って使うのがよいかと思います。
質問 (スコア:2, 興味深い)
FUSE 上のファイルシステムを LILO で使えるとは想像し憎いのですが、実際に試されました？
# 出来たなら出来たで素晴らしい事です。
Re:質問 (スコア:3, 参考になる)
LILOのインストーラ／設定プログラムがあらかじめファイルシステムを解析してファイルのセクタ位置を求めてブートローダと一緒に書き込んでおいて、LILOブートローダは単にセクタから読み込むだけです。
したがってFUSE上のファイルシステムであろうと、例えばinitrdでfuseのuserland側のプログラムが起動するようにしておけば、（kernelとinitrdは物理セクタ指定で読み込めるので）理論上は利用できるはずです。
とはいえ、そのためには前述のようにインストーラがファイルシステムを解する必要があるので、NTFSに対応している必要がありますが。
Re:質問 (スコア:2, 参考になる)
バイトストリームであって，かつ，セクタの中身を並べる
とそのバイトストリームが再生できる場合に限られる
たとえばreiser fsでもtail packing使ってると
ブートできない
Re:質問 (スコア:1, 参考になる)
Re:質問 (スコア:1)
今時、ほとんどのファイルシステムで「中身が連続して配置されない可能性」はあると思います。
てな話を書いてて、MS-DOS を思い出しました。
・MS-DOS のファイルシステム(FAT)は、データを不連続に配置することは可能
・起動時に最初に読み込む IO.SYS だけは、クラスタの先頭から連続して配置されていないといけない
・SYS コマンドを使うと、システムファイルをちゃんと先頭から連続した配置になるようにコピーしてくれる
(単にファイルをコピーしただけでは、ブートローダが認識しない可能性がある)
といった感じ
MS-DOS 6.0 あたり(うろ覚え。もしかしたらPC-DOS 7.0 かも)で、IO.SYS が連続じゃなくても良いようになってすごく感動したものです…
Re:質問 (スコア:2, 参考になる)
この場合重要なのはFUSEかどうか、ではなくNTFSはローカルのディスク上にある、ということなんです。sshfsやらHTTP-FUSEみたいな類は同じFUSEでも無理でしょう。
FUSEを通してブートすることなどできません。そもそもブートローダーとはカーネルのファイルシステムの仕組を使うものではありません。GRUBなどは独自のファイルシステムドライバを内包しています。
で、LILOにはファイルシステムドライバが無く、そもそもファイルシステム無視でディスク上のポジションの情報をもとにカーネルをロードするので、カーネルの置かれたパーティションがどんなファイルシステムでフォーマットされていようと（圧縮とか暗号化とかファイルの中身自体が変化するものはNG）その位置さえわかればロードできる作りになっています。そう、LILOはext2/3でさえ理解していないのです。LILOはファイルシステムの無いカーネルのベタ書きされたディスクからカーネルをロードすることすらできます（フロッピーブート等ではありがちな手段)。
ユーザ空間のツールの方がNTFS上のカーネルの位置を認識できない可能性はありますが（LILOのコマンドがどういった方法で位置を取得してるかまでは知りません...)、仮にそれがうまくいかなくても、てきとうな場所にカーネルを置いてLILOを設定したあと、NTFSのディスクイメージからカーネルをサルベージして位置を調べ、MBRなりLBRなりファイルなりに入ったLILOの位置情報をこっそり書き換える、といったことは可能です（こちらもフロッピーブートの常套手段）。
Re:とりあえず入れてみました。 (スコア:1)
徹夜開けとはいえ、パーミッションの事をすっかり忘れてました。（汗
つー事は、Windows上から物理ext3をsmbmountできるようなソフトを作ればもーかるかもしれませんな。
あれ？そんなソフトがあったような・・・。
今に満足をしているってのは、上を目指さない理由にはならない。
まだ少しでも探求心が残っているなら今すぐubuntuを試してみよう。
Re:とりあえず入れてみました。 (スコア:1, 参考になる)
NTFSにスペシャルファイル (スコア:1)
というのは、Windows Services for Unix (Interix) で実際にやってるからで、フォーマットがわかれば相互互換も可能でしょう。
そういえば昔々UMSDOSファイルシステムでは、無理やりFAT上でスペシャルファイルとか作ってましたよねえ。
今まであったのと何が違う？ (スコア:4, 参考になる)
暗号化や圧縮、所有者・アクセス権等にはまだ対応してない＝NTFSのメリットはあまり活かせてませんが、読み書きできるだけでも大きな大きな進展だと思います。
WindowsのDLLを流用する形でNTFSに対応するものとは違うので、他のコメントで出てるような「パクリ」とは違うと思いますし、この方がライセンス的にもいいと思います。
Microsoft側が仕様を公開してくれれば一番いい話ではありますがね。
Re:今まであったのと何が違う？ (スコア:1)
果たしてその状況はアクセス管理できてるといえるのでしょうか？
Re:今まであったのと何が違う？ (スコア:3, すばらしい洞察)
いやなら暗号化してください。
暗号化していないNTFSを、運用しているWindowsとは別のwindowsでマウントするとアクセス権限関係なくファイル読めることは知っていますか?
Re:今まであったのと何が違う？ (スコア:3, 参考になる)
それなのに、回復コンソールからだとインストールフォルダ意外は権限がないって怒られるんだよなぁ。
あれはショックだった・・・。
#事前にレジストリいじっておけば大丈夫らしいですが、その制限を事前に教えとけって。
今に満足をしているってのは、上を目指さない理由にはならない。
まだ少しでも探求心が残っているなら今すぐubuntuを試してみよう。
Re:今まであったのと何が違う？ (スコア:2, 参考になる)
要するに、アクセス管理をきちんとしたいのなら、別の OS へのマウントを許している時点でダメダメということでしょう。
Re:誤記になるのかな（おふとぴ (スコア:1, おもしろおかしい)
Re:誤記になるのかな（おふとぴ (スコア:1, すばらしい洞察)
＞「暗号」を「復号」すると「平文」に戻ります。
「平文」を「暗号化」すると「暗号文」になり、
「暗号文」を「復号」すると「平文」に戻ります。
の間違いではないですか？
「復号」か「復号化」か、「暗号」か「暗号文」か、
どちらも、どうでもいいことだとは思いますけどね。
Re:誤記になるのかな（おふとぴ (スコア:1)
Windowsからならアクセスできるので、意味が無くは無い。
>圧縮されたファイルの書き込みが出来ないということは、全て展開されて保存されるということでしょうか？？？
「圧縮されたファイル」というのを、zipとかlzhの事だと勘違いしている？
そういう圧縮ファイルとは別物の事ですよ。
Re:誤記になるのかな（おふとぴ (スコア:3, すばらしい洞察)
特にこのようなコメントならまだしも、トップ記事(垂れ込みは)注意してもらいたいですね。わけのわからない日本語ならば、原文の英語の方がまだわかります。
とにかく、目くじらを立てるという意味では、お互い様だと思いまので、あまり攻撃的にならないように。
内容以前に文体で腹が立つことも多いと思います。攻撃性という意味では、私には、#979600 のコメントの方が強く感じます。#979590 の方が文章が強いですけど、ニュートラルに思えます。
Re:誤記になるのかな（おふとぴ (スコア:3, 参考になる)
ただ、ZIP ファイルのような「元々から圧縮・暗号化されているファイル」と紛らわしいから、あるいは、NTFS ファイルシステムの機能を熟知していない人にも解るように、きちんと「圧縮属性の付いたファイル」「暗号化属性の付いたファイル」と書けと元ACの方は言いたかったんじゃないですか。細かい表現にこだわりすぎるときりがないというのは私も同意しますが。
Re:誤記になるのかな（おふとぴ (スコア:2, すばらしい洞察)
基本的にLinux上からNTFSを扱いたい人でしょうし、
それなりに人柱なモノを扱うのになれていると思うので
NTFSの機能では比較的表に出て来やすい圧縮や暗号化、
ユーザ管理あたりを知らない可能性はかなり低いのではないかと…
たしかに、単に"圧縮されたファイル"だと複数の候補があるから
もう少し詳しく書いた方が親切ではあると思いますが、
実際に使う前に自力で件の内容がどちらを示すか確認しないようでは
もっとこなれるまでは使うのはおすすめできないような。
#説明書を読もう、例え電話帳みたいな代物であっても必要だから厚いのだ
#状況はいつも最悪、でもそれが当たり前
Re:誤記になるのかな（おふとぴ (スコア:2)
Re:誤記になるのかな（おふとぴ (スコア:1, おもしろおかしい)
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:3, すばらしい洞察)
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:5, 興味深い)
公開した上で、みんなに解読に挑戦してもらって納得してもらうのが一般的です。
ってか、確かNTFSも方式は公開してたと思います。
因みにログインパスワードは関係ないと思います。
NTFSは暗号化したユーザーとAdministratorの両者が復号できるように証明書でなかなかナイスな処理をしていて、
Linuxから参照する際に証明書の所在を知る事ができないから、
暗号化ファイルは「おあずけ」なだけじゃないかなぁ。
そのうちオプションで証明書を指定すれば読めるようになるとか。
今に満足をしているってのは、上を目指さない理由にはならない。
まだ少しでも探求心が残っているなら今すぐubuntuを試してみよう。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:4, 参考になる)
「解読されてもいいじゃないか。
解読されたら更なる高度な暗号化技術を考えればいいんだし。」
ってのが基本的な考え方なんですよ。
暗号化にしてもハッシュにしても、そうやって進歩しているんです。
今どきの暗号化技術はソースを見ただけで解読にながるヒントを簡単に得る事はできません。
そして、その程度のものはリバースしても見れます。
#そりゃrot13レベルのようなものであれば見られると困るでしょうけど（笑
だからそこ、てっとり早くソースで
「簡単には解読できんぞ、試してみろ」とうったえるんです。
で、色々試して「こりゃ総当たりじゃないと無理だな」と・・・。
大体、MS等の大企業が社内だけで検証した暗号化技術を使うって事がなかなかありえない事だと思いますよ。
もちろん、あなたの言う通り、
軍事利用等クローズドで利用する場合は公開なんてしないでしょうけど。
#ちなみにXPのNTFSはラインダールのようですね。
今に満足をしているってのは、上を目指さない理由にはならない。
まだ少しでも探求心が残っているなら今すぐubuntuを試してみよう。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:3, 参考になる)
暗号に関しては FIPS140 認定を受けているので、少なくとも一度はソースレベルで外部監査をくぐってますよ。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:3, 興味深い)
もしMSが独自に暗号化技術を考えればそうじゃないかもしれないですね。
でも少なくともXPのNTFSで採用されている暗号化技術は一般的に利用されている技術(ラインダール)です。
なぜそのような技術を採用したか分かりますか？
あなたの言う通り、万が一アルゴリズムに欠点（穴）があり、キー無しで復号化されると困るから、
一般的で世界中の人が解読の挑戦ができる技術を使っているんです。
そして見付かった欠点を補っていき、少しずつ強固な暗号化技術になっていくんです。
DESやMD5が生まれた頃は、きっと絶賛されてたんでしょう。
でも今では技術と処理速度の向上により、危険なものとされ、消えていく存在ですが、
その欠点はAESやSHA1となって克服された訳ですよ。
#欠点がないのにわざわざ進歩する訳ないでしょ。
>仮に公開して、解読できちゃいました、穴がありましたじゃシャレになりませんよ。
穴があれば、そりゃ大変だけど、総当たりの復号化ぐらい別にどうって事ないでしょ？
ってか、となると、ものすごく普及しまくっているSSLは全然シャレになってないですね！
#もう嫌だ・・・。どろどろは好きくないっす。
今に満足をしているってのは、上を目指さない理由にはならない。
まだ少しでも探求心が残っているなら今すぐubuntuを試してみよう。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:1)
Windows2000、初期WindowsXPが、DESX
WindowsXP SP1以降、WindowsServer2003が、AES
のようですね。
#DESXってなんじゃ？初耳。
今に満足をしているってのは、上を目指さない理由にはならない。
まだ少しでも探求心が残っているなら今すぐubuntuを試してみよう。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:2, すばらしい洞察)
ファイルの暗号解読が容易になることは
必ずしもイコールじゃないと思いますよ。
セキュリティを仕様の隠蔽に頼るという考え方はすごく全時代的ですし。
だってその考え方だと、一旦アルゴリズムが解析されたら
その日から全世界のNTFSが読み放題になってしまいませんか？
アルゴリズムがわかったとしても、それとは無関係に
鍵さえばれなければ解読不可能ってのが普通の方法論じゃないでしょうかね。
現に今ある暗号化アルゴリズムは大体公開されてますし。
仕様が公開されないのはセキュリティのためじゃなくて
まぁいつもの単なる「嫌がらせ」だと思いますよ。
#NTFSが本当はどうなってるのか知りませんケド。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:1, 興味深い)
>> セキュリティを仕様の隠蔽に頼るという考え方はすごく全時代的ですし。
>> だってその考え方だと、一旦アルゴリズムが解析されたら
>>その日から全世界のNTFSが読み放題になってしまいませんか？
>>
>> アルゴリズムがわかったとしても、それとは無関係に
>> 鍵さえばれなければ解読不可能ってのが普通の方法論じゃないでしょうかね。
というような主張をする人がいますが，セキュリティ全般に関して，この理屈を盲目的に信じて思考停止するのもどうかと思います．
というのは，上記の比較の前提としては「非公開＝公開すると破られちゃうようなヘボいアルゴリズムを使っている」と想定しているわけですが，「仮に公開しても大丈夫なはずだが，それをさらに非公開にしている」というケースについて考慮していないですよね．もちろん，公開されてないんだから，実態がどちらなのかはわかりませんけど．
で，少なくとも，
>> 一旦アルゴリズムが解析されたらその日から全世界のNTFSが読み放題になってしまいませんか？
のような「一度破る方法が見つかってしまったら，もはや世界の終わり」という問題は，仕様が公開されていようが非公開だろうが全く変わりません．
では，仕様公開のメリットは何かというと，つきつめて言えば「バックドアが無いことをチェックできる」以外には「多くの人がreviewしているので，安心感が得られる」という単純な話になります．しかしながら，もしも頭脳明晰な人（天才？）が１人いれば，その天才１人の考えには「多くの人のreview」はかなわないという事実もあります．例えば，（仕様公開されていたケースでの話になってしまいますが）DESにおいてNSAが行った仕様変更は安全性を高めるためのものでしたが，20年にわたって謎とされており，「バックドアに違いない」などと噂されていましたね．
つまり，仕様が公開されていることで漠然とした安心感は得られるかもしれませんが，本質的には，「仕様を公開している方が安全だ」という理屈は成立しませんし，「仕様非公開がダメだ」と一元的に言い切る理由にもなりません．そもそも「仕様が公開されていて，現時点で破られていない」暗号化手法だって，将来的には，いつかは破られるでしょう．でも，その暗号化手法の仕様が非公開であれば「謎の仕様」という壁が１つ増えるわけです．
ちなみに，本題のNTFSのセキュリティについてですが，暗号化機能に関してはEFSってキーワードでググってみましょう．例えばここ [cybernetic-survival.net]が詳しいです．
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:1)
まためもるネタになっちゃうと嫌なので、あくまで私見ですが、
>そもそも「仕様が公開されていて，現時点で破られていない」暗号化手法だって，将来的には，いつかは破られるでしょう．
だからこそ公開する方が良いと僕は思います。
>でも，その暗号化手法の仕様が非公開であれば「謎の仕様」という壁が１つ増えるわけです．
本当に「謎」ならそうでしょうけど、
ものすごいシェアを誇るOSのストレージの暗号化技術が「謎」を維持できるかどうかですよね。
ってか、このコメントを読んでどっちでも良いような気がしてきました（笑
とりあえず技術者の方々がんばって下さい。
今に満足をしているってのは、上を目指さない理由にはならない。
まだ少しでも探求心が残っているなら今すぐubuntuを試してみよう。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:1, すばらしい洞察)
> しかしながら，もしも頭脳明晰な人（天才？）が１人いれば，その天才１人の考えには「多くの人のreview」はかなわないという事実もあります．
「天才を交えた多くの人のreview」には「天才１人の考え」はかなわないという考えから、DES後継のAESは公開公募されました。
暗号化手法の仕様を非公開にすることで、どれほど暗号が強力になるかは定量的に判断できないわけです。
誰かが同じものを思いつくかもしれませんし、リバースエンジニアリングという直接的な手段もあります。
判断も予測もできないものに安全を任せるのは非常に危険です。
念のため書き添えておきますが、暗号実装に関わる全てを公開するべきという意味ではないです。
非公開にすることでしか秘密を守れない分野もたしかに存在します。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:1)
ひょっとして僕の事いってるんかな？
ACばっかで誰がどれかわからんくなってるから、
俺も誰に対して言ったらいいんかわからんけど、
なんか勘違いしてるんでない？
ってか、もういいけどさ。
今に満足をしているってのは、上を目指さない理由にはならない。
まだ少しでも探求心が残っているなら今すぐubuntuを試してみよう。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:1, 興味深い)
大筋で同意します。仕様を公開しているから安全なわけではありませんし、非公開にすることで守られる秘密もごく限られた場合のみです。
リバースエンジニアリングにどの程度時間を必要とするかを勘案するのは難しいのですが、一般的に数日～数週間といったところでしょうか。難読化を施しても数ヶ月もてばいい方でしょう。
「数日で解かれているかもしれませんし、ひょっとして数年かかるかもしれません」ということをもって公開のAより非公開のBがより強力であるとするのは些か乱暴な結論と考えます。
この場合は同等と扱うのが適当でしょう。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:2, すばらしい洞察)
こういった試みは、代替が全くないからパクってるのではなく
Windows向けのファイルシステムやアプリも簡単に使えるようにしておけば
運用時にもっと便利になりそうだからと作られたわけで、
Windows側がLinux等に合わせない以上
他のOSの方から合わせるしか手はないと思うのですが…
それに、Microsoftも最近の例で
OfficeをOOoとの互換性を確保する為に対策を講じるとか
色々やっていますしねぇ
#個人的にはWin9xがNTFSを読めない事も痛い
#状況はいつも最悪、でもそれが当たり前
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:3, 参考になる)
読み込み専用版はフリーウェアです。
シェアウェア版は書き込みもできるらしいのですが、うーむ(どこで買えるのやらｗ)。
ちなみに、このソフトはWin2k/XPのDLLとかが必要みたいです。
読み込み専用でも起動できない状態からバックアップをとることくらいはできますし、選択肢としてはありかなと。
ちなみに、DOS用のNTFSDOS Professionalなんてもんもあるようです。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:1, 参考になる)
# 釣りってやつかなぁ?
元からオープンソースなのが ext2/ext3, reiserfs, ufs
もともと商用だけどオープンソースになったのが xfs, jfs
ほかにもいろいろ……
# フレームの元なのでAC
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:3, すばらしい洞察)
マイクロソフトがこの13年間にやったこと・なしたことは、コンピューティングの発展の阻害要因でしかなかったという受け止め方がフツウ (ex. http://itpro.nikkeibp.co.jp/a/it/alacarte/interview0615/alan_1.shtml )なんだろうと思っていたので、 元AC氏の言い分は「(奇妙で) 興味深い」と感じました。
こういった「売れている(とされている)ものが普遍的な善」とでもいった思考習慣って、どんな連中を有利にするんでしょうね?
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:1, すばらしい洞察)
競合製品への妨害工作の数々も顧客と利用者が求めていたとでも?
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:1)
＃ 実際 KNOPPIX を使って NTFS 読み込みをやったので ID
マラソンで二位を抜いたら何位？
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:2, すばらしい洞察)
が一般的な復旧方法だと思います。
CDブートして修復コンソール（回復コンソール）でもいいですが、こっちはファイルアクセスの制限がきつい模様。
Re:オープンソースはどこまでもマイクロソフトのパクリ (スコア:1, すばらしい洞察)
つか保証期間内にそんなことになるようなマシンは早いとこ売り飛ばしたほうが良いです。
ソフトウェア的問題でそのような事象になったのなら、そんな腐ったソフトを使うのを止めましょう。
他に選択肢が無いということはありえません。あなたが書けば良いのですから。
個人の力に限界を感じるならオープンソースにして世界中の人にハックしてもらえばいいでしょう。
Windowsフォルダを消された？なぜそんな人にAdministrator権限を明け渡しているのですか？
そういう人にはguestで十分です。
Re:MS-DOSは (スコア:1, 興味深い)
CP/Mのパチモンです。
#その後の発展はそれなりに評価するけどね。
Re:Knoppiｘ… (スコア:5, 参考になる)
このドライバを使えばlinuxでもNTFSは読み書きできます．
今回のタレコミで紹介されているのは，ドライバではなくて，ユーザ空間で動作するアプリケーションです．
具体的には FUSE(Filesystem in Userspace)という機能を使って実装されています．
アプリケーションなので
- クラッシュしてもOSは影響を全く受けない
- 機能が豊富
という利点があります．
欠点としては，
- ドライバよりはパフォーマンスが落ちる
ぐらいでしょうか．
Re:Knoppiｘ… (スコア:5, 参考になる)
一応NTFS Writeってオプションありますけど、新規ファイルは作れないし、ファイルサイズが変わる変更も書き込めません。
なのでfuseでもNTFSドライバがまともに使えるというのは大きなニュースと言えるでしょう。
Re:Knoppiｘ… (スコア:3, 参考になる)
最近のバージョン（カーネル2.6.15以降）ではファイルサイズ変更はOKになってますよ [srad.jp]。
新規作成は不可だけど。
Re:Knoppiｘ… (スコア:3, 参考になる)
> だからライセンス的に問題があるでしょう
リバースエンジニアリングという行為自体は合法です [wikipedia.org]。
日本では不正競争防止法の観点でも合法とされており、逆アセンブル等を行わない限りは著作権にも触れないでしょう。
但し、NTFS自体に特許権があれば、それを侵害することにはなるでしょう。