
Ubuntu日本語フォーラム

ログインしていません。
7.10のインストールで、
別パーティションにあるFAT32フォーマットの
Windows上のフォルダ・ファイル名が変更される場合があるかもしれません。
私の環境の特殊事例かもしれませんが、報告します。
症例:
別パーティションには、Windows2000がありました。
ubuntu-ja-7.10-desktop-i386.iso を CD に焼いてからインストール。
別パーティションにあるFAT32フォーマット上のフォルダ・ファイルの名前が
000 や 001~ などに変更されたものがあり、削除・名前変更が不能。
例えば、以下のようなフォルダ・ファイルでした(他にもいくつかありました)。
c:\Documents and Settings\All Users\スタート メニュー\プログラム\アクセサリ\ゲーム\ソリティア.lnk
c:\Documents and Settings\All Users\スタート メニュー\プログラム\管理ツール\コンポーネント サービス.lnk
c:\WINNT\サポテック織り.bmp
c:\Program Files\CUSTOM\JUST\ドキュメント\TARO13\F背表紙
2byte目に 0x5C や Ox7C を含む、
いわゆるダメ文字が対象になっているのかと思いましたが、
「ポソ表構十申」などを含むフォルダ・ファイル名が
すべて変更されたわけではありませんでした。
NTFSフォーマットにある同名のフォルダ・ファイルは無事でした。
なお、私の環境の特殊事例かもしれません。
それは、インストールでパーティション構成を指示するところで、
あまりに長く時間がかかったため、
途中でキャンセルボタンを押してから、シャットダウンし、
Windows上で、/ と Swap 用の拡張パーティションを作成したためです。
また、パラレルIDE と シリアルIDE の
2種類の接続のハードディスクを使っていることも特殊かもしれません。
バックアップをとってあるので、損害は全くないのですが、
バグであれば次のバージョンでは修正されたほうが使いやすいことと、
他の人の大事なフォルダ・ファイルが被害にあわないように、報告でした。
オフライン
http://forum.ubuntulinux.jp/viewtopic.php?id=124
で投稿したubuntu-6.10の症状と同じと思われます。
おそらくインストーラ内部で使用している fsck(?) コマンドのバグだと思いますが、
NTFSなら大丈夫なのが判ったので、windowsのパーティションを全部NTFSに変更して対処しました。
また、HDDの構成を変更した時は、ubuntuを先にインストールしてからwindowsをインストールすることで対処しました.
何の解決策にもなっていないような気がしますが、同様の症例が出ているので何とかしてほしいですね。
最後の編集者: m_nagase (2007-11-08 15:58:47)
オフライン
修正するには、現象をまとめて https://bugs.launchpad.net に報告する必要がありますが、
ちょっと私のほうでは、すぐに環境を揃えて検証・報告するのは難しそうです。
この問題を検証し、英語でバグ報告して頂ける方がいれば助かります。
もしおられないならば、次のリリースには間に合うよう報告しておきます。
オフライン
https://bugs.launchpad.net/ubuntu/+source/dosfstools/+bug/49217
と同じことが日本語でも起きているような気がします。
(Ubiquityがインストール時にfsckを呼んでいる可能性大)
オフライン
皆さん情報ありがとうございます。
partitioner か Gparted の問題かと思っていましたが、
fsck が問題である可能性が大きいみたいですね。
早速、fstab を編集しておきます。
いわゆるダメ文字が全て変更されるわけではないところに、
このバグの見つけづらいところがあるようですね。
英語でのバグ報告はとてもできませんが、
再度インストールしてみたところ、再現しましたので、
Windows 環境でのファイル名変更の検出方法の報告です。
(詳しい人には釈迦に説法かもしれません)
スタートボタンを押して、「ファイル名を指定して実行」。
cmd.exe を入力し、コマンドラインに入る。
dir c:\ /A- /S > HOGEHOGE.TXT
この HOGEHOGE.TXT を、秀丸エディタなどの正規表現で検索できるソフトで
「 00[0-9]\n」を検索すれば、
何が変換されたかおおよそ分かります。
同一フォルダ上に10個以上ファイル名が変更がある場合には漏れますが、
検索途中に見れば分かるでしょう。
この方法では、バックアップをとっていないと元のファイル名が分かりません。
また、Windows 上では、ファイル名の変更・削除ができなくなりますが、
Ubuntu でマウントすれば、削除可能です。
こんなに早く情報が得られるとは思っていませんでした。
m_nagase さん、jkbys さん、hito さん、ありがとうございます。
次の LTS までに直るといいですね。
オフライン
OS間でファイル共有しよーとしてるのなら, ウインドーズのファイルシステムじゃなく Linuxのファイルシステム使うって手もあるカモです。
WindowsでLinuxパーティションを読み書きするには
# マウントしなければ勝手に変更されることもないだろうし …
オフライン
RxOrca さん情報ありがとうございます。
> # マウントしなければ勝手に変更されることもないだろうし …
インストールの時に、マウントを設定しなくても”勝手に”変更されるのが困ったところなのです。
しかも、名前の変更されたフォルダ・ファイルは、
Windowsからは、中身を見ることも、さらに消すことも不可能になってしまうのです。
オフライン
あと、KNOPPIX5.1.1 でも、この現象が発生しました。
Ubuntu7.10 と違う点は、
変更される名前が、FSCK0000.REN のようになる点と、
KNOPPIX で変更されたフォルダ・ファイルは、Windows上で名前の変更・削除が可能である点です。
オフライン
一応、同じバグに悩まされた人がこのスレッドをのぞいたときのため:
/etc/fstab
を開いてターミナルからgksu gedit /etc/fstabなどとして開き、
/dev/hda2 /media/hda2 vfat defaults 0 1
などとなっているところの一番最後を0にしましょう。ちなみに/dev/hda2がデバイス名、/media/hda2がマウントポイント、vfatがファイルシステム、defaultsがマウントオプション、0がダンプの有無、1がfsckの有無を表します。
まあntfs-3gも標準になりましたし、windowsもntfs推奨なのでntfsにしとくのがいいと思いますが。
オフライン
H_Sugita による投稿:
> # マウントしなければ勝手に変更されることもないだろうし …
インストールの時に、マウントを設定しなくても”勝手に”変更されるのが困ったところなのです。
m_nagaseさんの投稿をよく読んでなかったです。(^^;
つまり, インストール時にパーティション操作 -- たとえば新規にパーティションを作成する(?) 等 -- すると, 関係ない別のパーティションまでチェックされ, 結果 (ファイル名が無効だと判断されて?) 改名されてしまう …
てことでしょーか?
Knoppixでの動作は, 起動しただけでは発生せず, パーティション操作を行ったら … てことでしょーか?
んで, 条件は FAT32のとき, と。
最後の編集者: RxOrca (2007-11-12 14:38:28)
オフライン
RxOrca による投稿:
つまり, インストール時にパーティション操作 -- たとえば新規にパーティションを作成する(?) 等 -- すると, 関係ない別のパーティションまでチェックされ, 結果 (ファイル名が無効だと判断されて?) 改名されてしまう …
てことでしょーか?
その通りです。
6.10のときは『手動でパーティションテーブルを編集』を選ぶと、
実際にパーティション操作を行わずにキャンセルしても、その時点で既存の全てのパーティションにfsckがかかり、
0x5C や 0x7C を含むファイル名がリネームされていたように思います。
7.04のときはロングファイル名用のディレクトリエントリを壊されました。(直すのにえらい苦労しました)
7.10はLiveCDからのインストールは試みておりません。
いずれもFAT32のパーティションです。
オフライン
皆さん情報ありがとうございます。
何回かインストールを試した中で、とりあえずわかったことを報告します。
現象:
Ubuntu7.10 LiveCD からのインストールで、
FAT32パーティションのフォルダ・ファイルの名前が
000 や 001~ などに変更され、
Windows 上では、フォルダ・ファイル名の変更・削除ができなくなる。
再現手順:
インストールの中頃でのパーティションを選択する場面で、
http://d.hatena.ne.jp/elsal/20071022/1193026419
http://f.hatena.ne.jp/elsal/20071022120014
手動を選択すると(試していないが、ガイドに従っても同じであろう)、
Ubuntu がマウント可能なパーティションは、
デフォルトで全てマウントポイントが設定され、
/etc/fstab には、fsck をするオプションが設定される。
そのため、インストール完了後の再起動の段階で、
http://itpro.nikkeibp.co.jp/article/COLUMN/20061108/253030/?P=6
(バグつきの)fsck が実行され、
FAT32パーティションのフォルダ・ファイルの名前が変更されるものが出てくる。
とりあえずの回避手順:
インストール中、デフォルトで設定されるFAT32パーティションのマウントポイントを、
1つ1つ編集して、削除する。
インストール後、fsck でファイル名を変更されないようにするため、
上の anoirさんの投稿を参考に、/etc/fstab では、
FAT32パーティションに fsck をするオプションをつけない + ついていたら変更。
オフライン
Windows2000でデフォルトにインストールされるファイルのうち、
以下のファイルの名前が変更される時の、/var/log/fsck/checkfs のログ
(このファイルの順序は、下のログにあわせてあります)
c:\WINNT\サポテック織り.bmp
c:\Documents and Settings\All Users\スタート メニュー\プログラム\アクセサリ\ゲーム\ソリティア.lnk
c:\Documents and Settings\All Users\スタート メニュー\プログラム\管理ツール\コンポーネント サービス.lnk
以下、/var/log/fsck/checkfs の該当部分
-------------------------------------------------------
fsck 1.40.2 (12-Jul-2007)
dosfsck 2.11, 12 Mar 2005, FAT32, LFN
Orphaned long file name part ":32r:33T:336:333:32l:7vK:32A.bmp"
Auto-deleting.
/WINNT/:32r:33T:336:333:32l:7vK:32A.bmp
Bad file name.
Auto-renaming it.
Renamed to 000\0000000.\000MP
Orphaned long file name part ":32z:33g:336:32Z:32Y.lnk"
Auto-deleting.
/Documents and Settings/All Users/:32v:32-:33y:338 :33X:33B:33b:33y/:33N:33j:32m:33f:33W/:32Y:32l:32x:32r:33g/:32o:33y:33W/:32z:33g:336:32Z:32Y.lnk
Bad file name.
Auto-renaming it.
Renamed to 000\0000000.\000NK
Orphaned long file name part ":32p:33p:33T:33y:33D:33p:338 :32r:33y:33J:32v.lnk"
Auto-deleting.
/Documents and Settings/All Users/:32v:32-:33y:338 :33X:33B:33b:33y/:33N:33j:32m:33f:33W/:7kX:7G6:334:33y:33h/:32p:33p:33T:33y:33D:33p:338 :32r:33y:33J:32v.lnk
Bad file name.
Auto-renaming it.
Renamed to 000\0000000.\000NK
Performing changes.
/dev/sda3: 43434 files, 1061748/1276677 clusters
fsck died with exit status 1
オフライン
あと、参考に KNOPPIX 5.1.1 DVD での報告。
起動して、シャットダウンしただけでは、
FAT32パーティションのフォルダ・ファイルの名前が変更されることはなかった。
しかし、gparted を実行したところ、
FAT32パーティションは変更しなくとも、
FAT32パーティションのフォルダ・ファイルの名前が
FSCK0000.REN などに変更されるものが発生。
KNOPPIX でのこの動作を参考に、Ubuntuでも気をつけること:
Ubuntu においても、
FAT32パーティションがある場合には、
たとえFAT32パーティションは変更しなくとも、
パーティション操作を行うことは危険な可能性がある(未検証)。
根本的には、fsck のバグ修正が望ましいけれど、
次善の策としては、FAT32 には fsck をしないことを徹底したほうがよいようだ。
# 何年も前に読み書き可能な FAT32 でこの状態なのに、
# NTFS の読み書きは(UTFでの処理とはいえ)大丈夫なのだろうか。
# と、何年も学校で英語を勉強したくせに、
# 英語の読み書きにバグの入りまくりな私が言ってみるテスト。
最後の編集者: H_Sugita (2007-11-14 03:17:34)
オフライン
NTFSの書き込みを複数のマシンでFeistyから使ってますが何も問題が起きたことはありません。
オフライン