12/01/25 12:35:58.73 ihKxYg5r0
>>949 >>951
君は読解力 0 だな
953:名無しさん＠お腹いっぱい。
12/01/25 13:49:55.28 G/+MF3zh0
>>951
必要な人がいることを想定して利用する設定を用意しておくのと
そもそも全く使えないのじゃ全然違う話だろう
954:名無しさん＠お腹いっぱい。
12/01/25 13:56:10.20 YKHhdL3d0
>>953
そんなこと主張してないけど…
最初に「必要じゃないですか？」っていうから「必要じゃないです」って根拠を示して言っただけだよ？
実際今まであふへの要望もなかったみたいだし
955:名無しさん＠お腹いっぱい。
12/01/25 13:57:58.96 6kRoL1LH0
作成日時を使う使わないはともかく、あって悪いことはないわな。表示はon/offできる前提。
見た目に邪魔でなく操作も違和感ないなら、俺も活用するようになる可能性は否定しない。
今のところはHuman68k同様、タイムスタンプは1種類でいいと思ってるけどね。
(作成日時を把握する必要がある場合はファイル名なり別の方法を取ってる)
ただ、「このシステム上でファイルを新規作成した日時」と
「別のシステムで作られたファイルをこのシステムに持ってきた日時」が
同じ扱いってのは違和感あるんだよな。アーカイブの展開もしかり。
rarにはNTFSとしての情報を含めるオプションがあるようだけど
まだまだzipで9時間ずれた～とか言ってるのが現実だしなあ。
956:名無しさん＠お腹いっぱい。
12/01/25 14:03:27.70 6kRoL1LH0
もしかして、アーカイブ内の作成日時を持たないファイルを展開したときに
「更新日時より作成日時のほうが新しい(現在)状態のまま」にせず
「作成日時(何もしなければ現在)を更新日時と同じにする」という仕様の
アーカイバやファイラもあるのかな。当然ありそうだな。そのほうがいいな。
957:名無しさん＠お腹いっぱい。
12/01/25 15:24:03.69 G/+MF3zh0
>>954
実際必要としてる人がいるからエクスプローラは設定で作成日時使えるようになってるんだろ
958:名無しさん＠お腹いっぱい。
12/01/25 15:28:13.87 uV1yOhVS0
俺は作成日時が欲しい。要らない人は要らないだろう。
俺は欲しい。要らない人は元から要らないんだから理解してくれないだろう。
959:名無しさん＠お腹いっぱい。
12/01/25 22:50:07.65 HOyRy7zS0
>>957
必要な人は必要だけど、ニーズは少ないからデフォルトで表示されてないって話だろ？
960:名無しさん＠お腹いっぱい。
12/01/25 23:08:44.31 8sDISfmX0
作成日時を「データの保存を開始した時刻」って考えると、それは成り立ってない話だから
表示もソートも要らんだろって思うかも知れんけど、
「ファイルシステム上にエントリを作成した時刻」って考えると、それを利用したい（場合も出てくる）
ってのは、特にあふのようなハードコア向けのファイラにならあってもいいんじゃないの。
961:名無しさん＠お腹いっぱい。
12/01/25 23:17:30.56 mwVEV/Nt0
オールドタイプなんでフォルダの作成日時で管理してることがあった
(Mintのころから)
NTFSになってから、フォルダの更新日時が
内部のエントリーの書き換えで更新されるようになったので
フォルダ更新日時で管理できなくなってしまった
フォルダ作成日時は変化しないので出来ればフォルダだけ作成日時でソートしたりしたい
・フォルダのソートは作成日時を使う
などというオプションがあれば、ぜひ使いたい
が、内部の状態が変化したフォルダーを把握したいって言う場合もあるだろうから
更新日時と作成日時のどちらかを使うか簡単に切り替えられるとうれしい
あまりに需要がニッチすぎるので、実装されそうに無いけど
962:名無しさん＠お腹いっぱい。
12/01/25 23:34:55.08 77ssC2m/0
最近あふを使い始めたのですが、壁紙をメッセージ窓には表示できないのでしょうか？
あと、二画面連結した壁紙にしているのですが、スクロールしたときに半分だけ壁紙も一緒にスクロールしてしまいます。
壁紙をスクロールしないようにはできないのでしょうか。
設定方法があったら教えてください。
963:名無しさん＠お腹いっぱい。
12/01/26 00:09:12.08 /ElTmefY0
某所（>>945） bit.ly/wyolFm メインメモリが 16～32MB の頃に作ったルーチンなので追加メモリ確保一切無しで処理＝単純総当たりな訳で。 確かに今の時代には合ってないかも。 …ってな箇所は山ほどあったり。（＾＾； #あふｗ
某所（>>946） bit.ly/zAKRmQ うちの環境だと１万１千ファイル存在するフォルダへの変更が初回（＝キャッシュに載ってない）で 0.2秒くらい。 ２回目以降は瞬間で測定不能な感じ。 #あふｗ
@afxw Core i7 2720QM + 外付け USB 3.0 7200rpm 2TB HDD にて。 「かなり待たされる」の「かなり」は具体的に何秒くらいなんかしら？ #あふｗ
某所（>>919） bit.ly/wcKoig これは前向きに検討中も、現在はビジネスがビジー過ぎて手付かず。(時間的問題よりも精神的問題で… (T_T)) 昨年の某要望も積んだままやし。 すみませぬ～。 ＞ 某氏 szo #あふｗ
###転載###
964:名無しさん＠お腹いっぱい。
12/01/26 00:52:47.72 9ZufinIT0
なんでそんなに速いの
うちだと、14000ファイルのフォルダへの変更で70秒
そりゃ2回目は一瞬だけど
外付けですらなくてSATA内蔵なのに
965:名無しさん＠お腹いっぱい。
12/01/26 01:44:37.48 /oysO8nQ0
FAT32だとかindex作ってないとかじゃないだろうな
966:名無しさん＠お腹いっぱい。
12/01/26 02:02:08.77 L2R40UUa0
フォルダ移動が遅いのは
ファイル情報を書き込む領域を
ある程度のファイル数が増えるごとに拡張していくので
HDD上で断片化が起きるから
あふと関係ないのでどうにもならない
ラムディスクに数万のエントリを作っても一瞬だけど
HDD上の録画フォルダなんかだと1000ファイルほどなのに2～3秒かかる
ファイル情報の散らばり方が大きいのでHDDのシークに時間がかかってる
ファイル情報領域を確保したあと、数ギガ録画して、ファイル情報領域を追加確保して、数ギガ録画して
ってなってるのでHDDのシークが激しい
でも一度キャッシュに乗れば一瞬だ
デフラグしない派なんだけど
ディレクトリエントリもつめて並べなおしてくれるのかな？
もしそうなら、デフラグかけるとフォルダ移動も速くなると思われ
と、思ってるのだけど、正しい知識なのかな？
FATだとそうだけど、NTFSだとどうなんだろう
967:名無しさん＠お腹いっぱい。
12/01/26 02:03:58.02 xgACehyY0
遅いのはウイルス対策ソフトウェアがスキャンしてるからでしょ。
exeが混じってると遅いよ。
968:名無しさん＠お腹いっぱい。
12/01/26 10:38:26.05 Df4MQfPM0
フォルダの作成日時のソート、是非ほしいです。要望いたします。
フォルダにあるファイルを更新する度にフォルダも更新されるので、
フォルダのタイムスタンプをいちいち書き換えています。
フォルダを作成日時でソートできれば、タイムスタンプを書き換える
手間がなくなります。
969:名無しさん＠お腹いっぱい。
12/01/26 13:51:56.21 xgACehyY0
本当に実現してほしい要望は直接メールしましょう。
970:名無しさん＠お腹いっぱい。
12/01/26 17:55:57.92 GdeIQKYg0
>>968
それもたしかにありますね。
更新したフォルダがいちいち上に上がってくるなよ
って思ってしまう時ありますね。
更新とか作成とかありますが日付順がやっぱり基本だと思っているので
気になってしまいますね。
971:名無しさん＠お腹いっぱい。
12/01/26 20:19:22.80 cklgJbO30
現状（そもそもないし）要らん気はするけどあればあるでなんか使い出はあるのかも知らんね
972:名無しさん＠お腹いっぱい。
12/01/27 01:48:02.10 tuZNFvCm0
フォルダを作成日時でソートしたい場合もあるし、更新日時でソートしたい
場合もあります。
ソート時に作成日時と更新日時を選択設定できるようになればいいのですけど。
973:名無しさん＠お腹いっぱい。
12/01/27 04:19:01.37 pfqncVhR0
NTFSのインデックスって検索が早くなるだけの無駄機能かと思ってたけど
フォルダ開くときにも有効だったの？
974:名無しさん＠お腹いっぱい。
12/01/27 12:18:05.20 lzRSNZu/0
フォルダを開くときに有効かは知らないが
ファイルを開くときに有効なのは確実
975:名無しさん＠お腹いっぱい。
12/01/27 16:04:50.30 0FxlVwEo0
試しにファイルを10000個作って開いてみたけど、3秒くらいで済む
でも、同じドライブの別のフォルダだと長い時間かかる
違いは、長期間かけて溜まったファイルであることと、総容量が大きいこと
エントリだけの問題じゃなくて、ファイルの実体を見に行ってるのかな
976:名無しさん＠お腹いっぱい。
12/01/28 00:40:23.30 y2j5qTNT0
NTFSは小さいファイルだと、MFT(マスターファイルテーブル)に直接格納してしまう
普通のファイルは、ディスク上に場所を確保して、その位置をMFTに記録する
フォルダはその内部のファイルのMFTでの位置をディレクトリエントリに記録していく
ちなみに単純なリストではなくてB+ツリーというデータベースっぽい感じで記録しているので
ディレクトリエントリが断片化していても通常のファイルアクセスは(読み出し開始までは)速い
が、ファイル一覧を取得する作業では断片化がもろに影響する
0～数バイトのファイルを大量に作った場合
ディレクトリエントリは断片化することなく連続した領域に確保されると思われる
通常の長時間かけてファイルが増えたフォルダの場合は
ディレクトリエントリが断片化してると思われる
(NTFSに詳しい人、もし間違ってたら訂正よろしく)
977:名無しさん＠お腹いっぱい。
12/01/28 00:54:11.53 y2j5qTNT0
750b以下ほどのファイルならMFT内に格納されるそうなので
実験するなら一つのファイルが1ｋb以上～
通常のHDDだとアロケーションユニットサイズは4kbくらいだろうから
3kbくらいのファイルを大量に作ってみるのはどうだろう
もしも、ボリューム内にファイルを作りすぎてMFTが足りなくなると
MFTが追加確保されてMFTが断片化した状態になり
HDDのパフォーマンスが落ちるらしいので
私自身はそんな実験はしたくないな
新品のHDDで実験して、本番使用前に再フォーマットするならいいだろうけど
ちなみに、MFTはフォーマット時にボリューム容量の12.5%が確保されるそうです
978:名無しさん＠お腹いっぱい。
12/01/28 00:59:55.70 uR0BUBGo0
試した時は、64kBを超えるくらいのファイルサイズにした
デフラグしてMFTの細分化は無い
どっちにしろ、ファイル一覧の情報を得る為にエントリを取得するだけなら、
一瞬で済む筈なんだよな
でも、あふ関係なくエクスプローラでやっても、やっぱり時間かかる
979:名無しさん＠お腹いっぱい。
12/01/28 07:46:48.84 dId8c2lk0
新スレです
おい！あふを語ろうぜ！ Ver.37
ｽﾚﾘﾝｸ(software板)
980:名無しさん＠お腹いっぱい。
12/01/28 08:27:36.73 MBprUytb0
大昔の記憶なので今は違う可能性が高いが
XP辺りまでのDiskeeperOEMの付属デフラグは、
MFTの最適化は行わず、ディレクトリエントリの縮小もしないという話を聞いた。
ただ、7付属版がどうなってるのかは全然知らないし
ディレクトリエントリは、たとえ縮小されていなくても
連続になっていればそれほど読み込み時間に差が出るわけないので
影響はほとんどないはず。
それにしても数秒から数十秒単位の遅延というのは、大きい気がする。
UTF-8のsamba上に日本語ファイル名のファイルをたくさん置いたときに
数秒待たされたような記憶はあるけれど。
981:名無しさん＠お腹いっぱい。
12/01/28 09:42:46.54 MXcljNDN0
作成日時もりあがってるな
自分はmint時代から、DOSもwindowsもunixも、
作成日時管理したいものは、
作成日時をファイルネーム、ディレクトリネームに入れて管理してるな
982:名無しさん＠お腹いっぱい。
12/01/29 02:42:58.17 U0p3vqtE0
ファイル一覧はディレクトリエントリをすべてたどる必要があるので
ディレクトリエントリ断片化の影響を受けるはず
NTFSでは個々のファイルアクセスの時には
ディレクトリエントリ断片化の影響はうけにくい
ディレクトリエントリがB+ツリーデータベースになってるので
最小限のディスクアクセスでファイルを見つけられる
FATのようにディレクトリエントリを端から端まで探さなくてもよい
FATの場合だとファイルアクセスするだけでも
ディレクトリエントリを端から端まで順番に探すので
もしも後ろのほうにあったらディレクトリエントリ断片化の影響をうける
が、ディレクトリエントリの一覧を取得するならFATでもNTFSでも
ディレクトリエントリを全部読み込む必要がある
当然、断片化していれば影響を受ける
MFTの断片化とは違うよ
MFT自体は普通の使い方だと断片化はしないんじゃないかな
ただ、MFT内で個々のファイルが散らばってると
全部のファイル属性を読むのに時間がかかるかもしれない
とは、思う
昔FAT32のボリュームが論理的にクラッシュしたのをサルベージしたときに
FATの構造を必死で調べた(それ以前からある程度のFATの知識はあった)
NTFSは表層的なことしか知らないので、いまいち、自信がない
983:名無しさん＠お腹いっぱい。
12/01/29 12:01:38.99 rsdq3gSO0
MFT内での断片化(分散?)の影響を受けるということは、
結局B+木も大したことないということかな
984:名無しさん＠お腹いっぱい。
12/01/29 16:55:33.03 NWuDhS4Y0
自分も仰山ファイルの入ったディレクトリ試してみたら
72833ファイルあって2分50秒くらいだった。
2005年製ノートPCなうえ2.5HDDで遅いしこんなもんや（´・ω・｀）
985:名無しさん＠お腹いっぱい。
12/01/29 17:16:45.29 rsdq3gSO0
長い期間かけて溜まっていったファイルは情報がMFTの中で分散しているので、
それらに対してランダムアクセスを繰り返すことになって遅いんだろうな
シーケンシャルにMFTを全部読むだけならすぐに終わるのに
986:名無しさん＠お腹いっぱい。
12/01/29 23:06:12.56 Po8Q7nr+0
あふｗ 1.53b3
URLﾘﾝｸ(www.h5.dion.ne.jp)
・タイトル表示で先頭テキスト系のモノは 128bytes 未満だと認識されないものがあったのを修正。
・インクリメンタルサーチは、カーソル位置がマッチしない場合は必ず先頭から検索していたのを、まずカーソル位置から下を調べてマッチするモノが無かった場合に先頭から検索するよう変更した。
（INCHEAD=1 で従来動作 【あちゃｗ扱い予定】）
・7z.DLL を用いた展開のパスワード入力ダイアログにて、ALT+Ｍキーでマスクの ON/OFF を切り替えられるようにした。
987:名無しさん＠お腹いっぱい。
12/01/30 08:17:24.98 M6kLdXn50
あっふでーとしました
988:名無しさん＠お腹いっぱい。
12/01/31 04:54:14.93 VVHkCvzp0
してください
989:名無しさん＠お腹いっぱい。
12/01/31 17:21:11.68 47LdclrE0
Listary
URLﾘﾝｸ(www.forest.impress.co.jp)
エクスプローラ上でいきなり文字をタイプしてファイルを絞り込み検索
990:名無しさん＠お腹いっぱい。
12/01/31 17:56:19.37 ScChzUA/0
フォルダ作成で間違って
\\servername\saredname\folder1\folder2
\servername\saredname\folder1\folder2
とか指定すると指定フォルダの下に
servername\saredname\folder1\folder2
を作成してくれるんですが、これは仕様？
991:名無しさん＠お腹いっぱい。
12/01/31 18:03:17.13 b4idYQOg0
何をしようとして、どう間違えたのかがよくわからない
992:名無しさん＠お腹いっぱい。
12/01/31 19:36:35.80 Vj/7cfzL0
>>990
上は通常のフォルダジャンプ
下は自動でフォルダ掘ってくれてファイル振分とかに使える機能
993:名無しさん＠お腹いっぱい。
12/02/01 06:39:12.09 xXN0Wqr20
zzzzz
994:名無しさん＠お腹いっぱい。
12/02/01 07:39:57.50 1NYmESKq0
あふwアップデートってβ版は取得してこない仕様だったっけ？
995:名無しさん＠お腹いっぱい。
12/02/01 07:44:16.17 1NYmESKq0
あふｗ 1.53b3を取得させるつもりであふwアップデートを実行したんだけど1.52しか取得できなかった。
996:名無しさん＠お腹いっぱい。
12/02/01 07:57:35.76 L+9qqQtJ0
「1.52を取得しますか？」で「いいえ」を選ぶ
997:名無しさん＠お腹いっぱい。
12/02/01 14:38:49.90 aUu8bKL+0
>>989
おお、これ凄そう。fenrirを捨てる日がくるか？！
998:名無しさん＠お腹いっぱい。
12/02/01 18:27:58.54 Zw7jOwMw0
everythingみたいな奴じゃねーの
999:名無しさん＠お腹いっぱい。
12/02/01 20:47:34.50 9MhBehJe0
UME
1000:名無しさん＠お腹いっぱい。
12/02/01 20:47:50.43 9MhBehJe0
UME
1001:１００１
Over 1000 Thread
このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。