またまた1つの記事サイズ20GB超で分割数29000以上というバカげた記事が投稿されたので「不足パーツの文字列を作るのに時間がかかっている説」を検証するために様子を見てたら、この説が否定されてしまいました(T_T)
この説が正しいとすると、最初のうちがものすごく時間がかかって、だんだん短くなっていくことになりますが、逆にダウンロードしたパーツ数が増えるに従って遅くなってました。
ということは、毎回揃っているパーツを確認するとかして遅くなっているのかなあという感じですね。結局解決できないけど……

ちなみにGiganews+NewsbinProの組み合わせではダウンロードもデコードもできるのに、NewshostingのReaderでは記事の表示すらされないし、検索もできないという結果になっているので、Newshostingも万能ではないということがわかりました。

もう、投稿者側の問題ですな。どうしようもない。
29000って、HNRが作られた時のFATシステムの1ディレクトリ内のファイル＆ディレクトリ総数超えてますがな。処理方法にもよりますが、ディレクトリ内のファイル取得でFAT前提の一括取得APIを使っていたら、落ちなくてもスワップしまくり。
私が使ったAPIは、先頭ファイルを取得し、その後次のエントリを取得するやつで、C（C++ではない）の基本関数つかっていたんですが、これなら処理しながら一時ファイルに出力しながら処理出来る。一時ファイルがシーケンシャルorランダムであろうと。
話は変わって、またparファイルのリカバリブロックサイズが、分割ファイルサイズとおなじやつに出くわして、1分割ファイルが少しでも少しでも不完全だと、multiparでも消失ファイル扱いになってしまうパターンが出ました。おなじ投稿者の他の記事は正常なものもあったのに

最近HNRの動きが極端に遅いと思ったら、1つの記事サイズ915MB、分割数18244という記事が原因だったようです。
分割単位は50KB程度なので1つ分のダウンロードはすぐ終わるのに、その50KBを保存するのに数十秒はかかるので、この記事をダウンロードしようとしてものすごい時間を浪費していました。
多分HNRの分割ファイルハンドリングの問題(例えば10000個目の分割単位を保存するときには、どこかで10000回ループするみたいな)があるんじゃないかと想像しますが、原因は定かではありません。
しょうがないのでHNRからは削除してNewshostingのNewsreaderでダウンロードしたら10分もかかりませんでした。

Newsreaderも適材適所っていうことですね。

これ、HNRのTMP関連フォルダの処理の複雑さもあるけど、それよりHNRが開発されたときはFATシステム前提(32bitもある）でしたよね。で、デコードする際に一旦テキスト(html）に結合してデコードしてますよね。tmp等フォルダを監視すると判る。このテキストファイルが実ファイルより大きくなるんですが、分割数が多くなるとその差が無視できなくなります。
多分、その為デコード前の結合されたテキストファイルのサイズがFATシステムファイルで問題になる2G あたりになって処理が滞っているかswapしまくりじゃないかと。ちなみに32bitアプリのデータエリアの上限は2GBですから、これも影響してるかも。
Newshostingは今のNTFSシステム前提だから問題が起きないとおもいます。また、デコードをオンメモリじゃ無く11ファイルずつデコード＆別ファイルに逐一書き込みながら処理すればメモリの問題が避けられるかも。
同じ事が以前日付がおかしい記事についてあげましたが、quickpar.exe(32bit)の内部エリアの領域不足で落ちましたね。
あくまでも推測です。

この結合はdivフォルダから持ってきて1つの記事にする時です。それと分割数18244ですがこれも個別ファイルをtmpフォルダにもって来る際にファイル数制限があります。仕様上6万個ですが、大文字小文字で実質2万。これはあくまでもファイルシステムの問題でNTFSなら解消できますが、プログラム側で対応できるメモリを確保して入る前提。メモリが足りない場合ファイルを介していれば処理が出来ても遅くなるかと。

追加で、処理が遅くなる可能性
エクスプローラでサムネイル表示onにしてませんか？「僕んちのTV別館」というサイトで6000弱のjpegファイルを一つのフォルダに入れ、フォルダを開いたら延々サムネイル作成行い、最後にHDDが壊れたそうです。この動作はバックグラウンドでも行われる可能性があります。
私もjpeg等が入ったcd-romを開いたら延々cdドライブがシーク続け極端にPCの動作が重くなりました。以後、エクスプローラのサムネイルオプションは滅多なことではonにしません。

No.1235 の記事ですが、tmpフォルダじゃなくdivフォルダですね。1フォルダに18244個のファイルを生成しますから。
あと、開発に使っている関数の仕様もありますね。vc6はNT系でも動かす前提ならヘッダーファイルの一部変更が必要とききました。それだと関数で扱える数値範囲が増えると。ただ、そこまでやって大量のデータを処理するよりも送受信形態を変えた方が・・・
デコードじゃなくdivフォルダへの保存に時間がかかっているのでしょうか。となると、HNRで分割情報を管理するメモリを大きく採っていたり、1記事保存の際に同一idの記事があるかどうかチェックしているので時間がかかるのかと。

実は遅い理由には思いあたる節があって、「文字列連結を素直にやっている」ことではないかと。

分割ファイル1個はNH_Divの中に個別フォルダが作られて、各パーツが入れられていくわけですが、このとき同じフォルダ内にある_PartsIndex.txtに各パーツの情報がテキストで追加されていきます。この文字列追加のときに、素直にA=A & Bみたいな書き方をしていると、文字列を連結しようとするたびに文字列領域の再確保が必要で、かつ、文字列が長くなればなるほど再確保に時間がかかるということになるらしいです。
つまり分割数が多くなればなるほど_PartsIndex.txtの領域確保に時間がかかるようになるので、50KBのファイルを保存するのに時間がかかるのではなく、_PartsIndex.txtを更新するのに時間がかかっているのではないかと思います。以前自作ソフトでこの罠にはまって、改善したら5.5倍高速になったという実績があります。

改善するには、最初から大きな文字列領域を確保しておいて、そこにデータを追加していくようにすればいいのですが、もうそれは望めないので諦めるしかないですね。
(T_T)

_PartsIndex.txt ファイル作成に時間がかかっているのですか。

_PartsIndex.txt　の中身見る限りソートして無く追加書き込みしてるようだから、私は、openモードを"a"のアペンドで追加しているだけだと思ってました。これ、そんなに処理かからないのよね。
異常終了したと良く巡回中に異常終了する時ありますよね。これはNH_AList内の最新の記事リストファイルが壊れている事がありますよね。これには二つの壊れ方があって
　1．全部壊れてる。新規で作ってる時に落ちた
　2．ファイルの最後の方だけ壊れている。正常なファイルにリストを追加した場合。

こんな状況をみたのでHNRのアスキーファイルの扱いはfopenあたりの関数を使っていると思ってました。FDベースで同じようにどんどん追加するプログラムを作っても遅くならなかったので。

「巡回中・・」あたりの文章おかしいですね。ごめんなさい。異常終了じゃなく停電など強制pcダウンの時ですね。
確かにダウンの後、PartsIndex.txtの中身\00ばかりだから、実際に文字列結合してるようだと思いますが、後半部分￥00で埋められたりと。

実際のところどうなんだろう？

No.1238を書いていて自分でも釈然としなかったのが「どんなに長い文字列だったとしても、1回の文字列結合で何十秒もかかることになるだろうか？」ということでした。
そこで、文字列結合のループ回数が分割数に比例する部分はないだろうかということを考えまして、それが、分割ファイル結合マネージャの、分割ファイル不足パーツの番号表示の部分ではないかと思い当たりました。

分割ファイル結合マネージャで全てのパーツが揃っていないファイルを選択すると、不足しているパーツの番号が表示されます。5分割されたファイルで、1個目だけが揃った状態では"2 3 4 5"と表示されますが、これは1つの文字列だと思われるので"2"と"3"と"4"と"5"を文字列結合しているはずです。この場合、4回の文字列結合が必要で、パーツが揃うたびに文字列結合が発生します。(結合回数は、1回ずつ減っていく)

分割数が少ない場合は素直に結合しても時間はかかりませんが、分割数18244となると、最初のパーツをダウンロードしたときに18243回の結合が必要で、その後18242回、18241回と減っていきますが、半分のパーツが揃った時点でも9000回以上の結合が必要になります。これをNo.1238で書いた「素直な文字列結合」で実行しているとすると、1つのパーツをダウンロードするのに長時間かかる理由として納得がいきました。

これが正解かどうかは、ソースを見てみないとわかんないですけどね。

酢こんぶさん程じゃないのですが、最近divフォルダへ保存する時間が少し長い記事セットがありまして、条件が記事のサイズが小さく、コネクション数が多い場合でした。
ダウンロードウィンドウでは記事が一度に沢山100%ダウンロードされていて、ここからが長いんです。よく考えていたらdivフォルダへの保存は1記事づつなんで、ここで交通渋滞おこしているんじゃないんでしょうか? いくら処理を簡単にしても、二重書き込みはまずいですから。
他のニュースリーダーはファイルセット内で一個ごとにダウンロード＆保存しているから渋滞起きないかと。
よく考えたら、giganewsのコース変更してから起きてますね。変更前に同じ物をダウンロードしたときはこれほどじゃ無かったですで。変更後、コネクションを増やし、さらにハイパーサーバーもありますからね。

HNRはパーツごとにテキストファイルでストレージに保存してるから遅いですよね。最近のニュースリーダは、各パーツをある程度メモリに蓄積しといて一気に書き出すでしょうから速いのだと思います。
HNRが最初に作られた頃は、空きメモリが数GBなんてことはあり得なかったから、1記事100MBを超えるようなものを想定すると、HDDに逐次保存する仕様にせざるをえなかったのでしょう。

上記原因だとすると、コネクション数が増えたことで、100%なのに保存が終わらない記事が目立つようになっただけで、全体の保存時間は変わらないんじゃないかと思います。

とりあえず解決策は、divフォルダをSSD上に置くくらいしか思いつきませんねえ。

分割記事の認識は結構前からあがっていますが、新たなパターンが出ました。
知られているパターンは[]()の並びですが、ここ最近出たパターンはタイトルにあるファイルサイズです。ファイルサイズに . が入るとファイル名と認識されて分割記事の判断条件に引っかかります。
(1/19)123MB ○
(1/19)123.5MB ×
これが連続で投稿されていると、分割認識されるものと、されない物が出てきます。で、気づいたときにはまともにダウンロード出来ていない。これを手動結合させていたんですが、限界にきまして、対象のタイトルを一括削除しました。

こういうのって、もう改善される望みもないから諦めるしかないですよねえ。

最近、メインで使っているGiganewsの記事抜けが妙に多いので、NEWSHOSTINGを
ひと月だけ契約してみました。
すると記事抜けが少ないのに加えて専用Newsreaderの使い勝手がものすごく
いいです。
いちいち記事一覧を取得しなくてもダウンロードが始められるのが便利すぎる。

HNRはもちろん使い続けますが、HNRで正しく結合できない記事に関しては、
別のNewsreaderを使うというのがストレスたまらなくていいかも。

一応、タイトルチェッカーの不要属性に　- yenc ) . で弾いてます。その記事はランダム文字列のパスワード保護がかかってるので大きい影響無いんです。
それに、Giganewsだけは契約の一時お休みが出来るので、助かるんだよねぇ。それに時々コースプランの料金が下がる時がある。ほっとくと前の料金が適用されたままなので、同じコースに変更し直したほうがいいです。
正式サーバーから消えた news-europe.giganews.com　無茶苦茶古い記事のヘッダーが残ってます。記事本体は無いですけど。これと他のサーバと組み合わせると古い記事が再取得出来るかも。

実はつい最近Giganewsのコースプランを変更しまして、その結果、料金は1/3でコネクション数は5倍ということになったので、定期的なプラン見直しの必要性を痛感してます。
このままGiganewsの記事漏れが改善されないようなら、NEWSHOSTINGに乗り換えるかもですけど。

ついに訳の判らない記事にぶち当たりました。分割情報が全くついていません。
10年以上前から動画＆画像系各ngで投稿規則やF&Qがアップされて、nfoファイルなんか助かっていたんですが。で、その記事のヘッダー。今回は投稿者のミスです。ミスがあったときは投稿者の依頼でごっそり記事削除され（記事抜け）、再アップされているんですが・・・

463449000 4a47c1d4d27145adb9fdb9f32e2c7fcf .TuS1A1Z@ngPost.com 06 Jan 2020 12:59:14 GMT <4a47c1d4d27145adb9fdb9f32e2c7fcf@ngPost> 740009 5690 Xref: number.nntp.giganews.com alt.binaries.bloaf:10264866200 alt.binaries.tatu:562806403 alt.binaries.anime:463449000 alt.binaries.misc:5875279791

分割情報一切ありません。これでどうやって結合するんだ。次のファイルらしきタイトルは違うランダム文字列。一応、デコードしてみたんですが、ドラゴンボール超のヨーロッパ版らしい。
根本的疑問はどの投稿ソフトで投稿すればこうなるのだ？

Giganewsの新しい料金プランですが、従来のdiamondに相当すると思うのだが、コース変更の際の downgrade ってどういうこと？

ダウンロードして記事表示してみたら、
=ybegin part=54 total=147 line=128 size=104857600 name=Dragon.Ball.Super.S02.1080p.Bluray.THD5.1.x264-KaiDubs.part069.rar
という文字列があるので、一応"part069(54/147)"ってことなんですかね。
全部ダウンロードして順番にデコードすればなんとかなりそうですが、そこまでの気力はありません……
ちなみにNewshostingのreaderで確認したら、記事自体が表示されませんでした。
まともにデコードできないファイルとか、修復不可能なファイルは表示されない仕様なのかもしれません。

あと、Giganewsの"downgrade"は、私もすごく違和感がありました。
とりあえずdowngradeしましたが(^_^;

久しぶりにアクセスしたngで、去年あたりの記事でファイルの修復の際にquickparが異常終了する物がありました。multiparならいける。
よく見るとリカバリファイルのブロックサイズが、修復対象ファイルと同じで、物によっては100MB超えます。それで、quickparが落ちる。
ところがここのサイズが問題で、分割記事が1個でも無いとリカバリブロックが無いと「消失ファイル」と見なされるんです。結局、quickparでも復元できない事がありました。

MultiParで修復できるなら、とりあえずそれでいいのではないでしょうか。
MultiParの作者は日本人なので、改善要求とか取り入れてもらえたりして助かります。
壊れたファイルからもリカバリブロックをできるだけ抽出してくれるし、修復完了時にアプリを終了する設定にもできるので、連続実行時に便利ですよね。

問題がリカバリファイルのブロックサイズが修復対象と同じなんです。分割記事が一個欠けて結合しても、そのファイル全体が無いことになる。multiparでもリカバリできない。つまり、リカバリ時、完全なファイルしか使えない。
400個程度のファイルセットで10個程度不完全なファイルあっても復元できない。5個ぐらいの破損ならなんとかなる程度。
普通のブロックサイズなら破損ファイルが50個あっても正常なブロックが結構あるので復元できる。

最近変な投稿があるんですけど。a.b.dvd.anime等に日付や拡張子がない記事がアップされています。
AListの内容を見ると日付の年が下二桁しかない。分割記事が不完全とか。どんな投稿ソフトでアップしてるのやら？拡張子が無いのはmacかなと思うけど、年が二桁表示のファイルシステム見たこと無い。

確認してみたんですが、そういう記事が見当たりません。
削除されてしまったんですかね。それともGiganewsにはないのかな。

具体的な日付やSubjectがわかれば再確認してみます。

これですが、拡張子はついてますが、日付が？？？普通のはGMTですがUTCになってます。HNRが認識できない。さらに年が20としか書かれてないのもありました。見つけたらアップしますね。
これに拡張子が無いのもあります。ちょうど境目なんで比較するとよくわかります。
これは、usenetの規約に外れてない？

196856857 [wkVy0] b9e77f34a7911b68e4b3ee44eedbfee8b531b9d4ac0f447 [1/1] - "Stefan Ahnhem - Fabian Risk 04 - 10 Stunden tot.rar" yEnc (09/10) CpA8AZ0LGp <R6HKuVZ@XTwVG6qb.xdy> Sat, 10 Aug 19 12:28:24 UTC <1565440103.58927.9@PRiVATE> 793173 6097 Xref: number.nntp.giganews.com alt.binaries.dvd.anime:196856857
196856858 bd9d06fb5b93ae9bd3c252493970da04 - "bd9d06fb5b93ae9bd3c252493970da04.par2" yEnc (1/1) JBinUp.com <JBinUp@JBinUp.local> Sat, 12 Oct 2019 11:12:51 GMT <i2Fjr9Ian6ieTfNT0X6Z_1o20@JBinUp.local> 12582 92 Xref: number.nntp.giganews.com alt.binaries.multimedia.erotica.anime:22958721 alt.binaries.dvd.anime:196856858 alt.binaries.anime:458675866

よく見ると、年号おかしいですね。上は下二桁、下は四桁。
投稿ソフトのソース段階で大間違いして、ユーザーが気づかないとか。
text記事なんか本体消えてても、相当過去のヘッダー残ってるから、上を投稿したソフトでは記事の年はどう表示される？

a.b.m.e.animeとかに投稿されている、パスワード付きの巨大サイズのファイルって何なのか知っている人いますか？
フィルターではじくことが難しいので予約されてたら問答無用で消してますが、何か有用なデータなんですかねえ…
それとも嫌がらせ？

あれ、多分アニメや映画です。一時期、ランダム文字列ファイル名でパスワードなしのブルーレイリッピングファイルがアップされてました。1年ほど前から著作権問題で著作権を持つ国から削除依頼問題が出ましたよね。多分、それ回避です。
さらにサーバー比較サイトの中で噂レベルで、変な正義心をかざしてファイルを大量に削除したサーバー会社の社員が出たそうな。
予約回避はfromで判断ある程度はじけます。

パスワードのヒントとかあれば有用なデータかもしれないのに、それがないとただの嫌がらせにしかならないですよねえ。

ついにHyperNRがダウンロードできなくなってるみたい。
話は変わってUSB3.0とUSB2.0のA端子雄の金属部分の長さがケーブルやメモリで微妙に違うのありますね。雌側の奥の長さも違うし。
USB3.0関係で現在2件発生しています。奥まで差し込むと認識しなかったり、接触不良起こしてます。仕方なく1-2mm程少し引き抜いてます。HDDレコーダーで1日費やした。

HNRダウンロード不可の件、残念ですねえ。再配布とかしちゃっていいのかどうかわかんないし…

uni-codeファイル名で投稿され、ネット中継でタイトルが文字化けした
記事をよく見ますが、最新のウィルスバスタークラウド10とmultipar
と併用すると問題が起きます。

具体的には、multiparで修復してファイル名を本来のuni-codeファイル名
に変換するさいに、ウィルスバスターが「不正変更」と誤検出します。

一応、ご報告

追加です。
multipar 1.2.8.7のセットアップタイプをインストール
する際にウィルスバスタークラウド10が「システム変更ウィルス」
（表示名忘れた）と警告出します。あくまでも警告であって、
セットアップを中断してもファイルは削除されないし、
セットアップを続けてもセットアップできます。

HNRの一時フォルダをRAMDISKに移動する方法です。

概要
○シンボリックリンクを使ってHNRのフォルダとRAMDISKのフォルダをリンクする。
　これを実行すると、HNRが自分のフォルダ内のNH_tmpにアクセスしようとした時に
　実際にはリンク先のNH_tmpにアクセスするという動作をします。

具体的な手順
(1)RAMDISKを作る。(酢こんぶはとりあえず500MB確保しました)
(2)RAMDISK内に、NH_tmp,NH_tmpM,NH_tmpRの3つのフォルダを作る。
(3)HNRフォルダ内にある、(2)の3つのフォルダを削除する。
　(これをしないと(5)でエラーが起きます)
(4)cmd.exeを管理者権限で立ち上げる。
(5)cmd.exe内で(2)の3つのフォルダに対して次のコマンドを実行する。
mklink /d [元のフォルダ] [リンク先のフォルダ]

NH_tmpフォルダのパス：C:\Program Files\HNR\NH_tmp
RAMDISKのパス：Z:\NH_tmp
の場合は、
mklink /d "C:\Program Files\HNR\NH_tmp" "Z:\NH_tmp"
これをNH_tmpM,NH_tmpRについても実行する。
(5)HNRを立ち上げて動作確認する。

こんにちわ、

NH_tmpRは、ramディスクにしない方がいいみたい。
分割情報をHNRがうまく認識できないとき、TEXT形式で
ダウンロードして、終わったら手動結合で予約しますよね。

この処理がタコで、すべてのデコードしたファイルをHN_tmpR
に書き込んで、完了後Downloadフォルダに転送します。
ですから、すぐramディスクがフルになって処理エラー。
オプション設定によっては元のtextデータが削除され、
再ダウンロードの羽目に。気をつけましょう。

ああ、なるほど。「NH_tmpRって何に使ってるんだろう？」って思ってたんですが、
そういうことでしたか。
折を見てFAQに入れておきます。情報ありがとうございました。

実は今はRAM-DISKを使ってません(-_-;
1記事で1GB近い添付ファイルが付いてるっていう投稿に何回か出くわして、その都度
止まっちゃうのが面倒で…

いっそのこと最新マザボに32GBのメモリ載せて、
4GB以上のRAMディスクをつくるとか。(^_^)

つい最近、メインをPentiumDマシンから、初代Core i7の中古ノートに変えました。
最新マザボとか、欲しくないわけじゃないんですけど、あまり必要性を感じないんですよ。
唯一、エンコード作業の時には最新マシンがいいとは思うものの、現環境でも前環境に
比べたら爆速だよなあ、とも思ったりw

あら、corei7のノートですか。
別スレッドでHNRが遅くなると、書かれていますが、もしかすると発熱による
CPUの強制パワー低下かも。ノートは放熱悪いから。
coreiシリーズはメモリークロックやcpuクロックがコロコロ変わるから。
グラボはCPU内蔵のものですか？それだと画像処理が
重くなると、輪をかけて遅くなる。一度、OpenHardwareMonitorなどで現状を
調査して、ダスト掃除やグリスの塗り直し必要になるかも。(グリス塗り直しは
きついかも)

うちは、core2 quadでグラボをGT100 -> GT630 -> GT750Tiに変えたら、
グラフィックのスコアが上限近くまでにアップ。
HDDは遅いですけど(^_^)

最近、HNRの動作が遅くなる現象が発生していて、どうにも原因がわからなくて困っています。
何かご存じの方がいらっしゃいましたらご教示いただきたく、お願い致します。

現時点で確認されている現象
(1)HNRのウィンドウをアクティブにしようとすると、必ず5秒以上待たされる。
(2)HNR内でアクティブウィンドウを変更する場合も同様。
(3)別のアプリがアクティブになっていると、HNRの動作が異常に遅くなる。
(4)予約中の記事をすべて削除すると現象が消える。
(5)予約中の記事を減らすと、現象が緩和される。(少し速くなる)
(6)予約記事が多い時は現象が出ず、少なくなってから出る場合がある。
(7)現象が出ている状態で予約記事が追加されると、現象が消える場合がある。
　(ソートはしてないので新しい記事は後ろに追加される)
(8)HNRを再起動しても現象は消えない。

環境：
OS:Win7Pro 64bit(Win7Pro 32bitでは発生したことがない)
メモリ:8GB(1GBをRAMDISKとして使用。HNRの一時フォルダを置いてある)
HDD:SATA 2TBをUSB3.0で接続(残り容量200GB程度)　システムは160GBのSSD。

予約記事の表示に何か問題があるのかと思ったのですが、(6)とか(7)の現象を
見るとそうでもない気もするし、わけがわからないという状態です。
また、現象はHNRのみで発生するので、システム全体の問題ではないようです。

この件、原因はわかっていませんが、
「予約ダウンロードウィンドウを表示しない」
という方法で現象が出なくなるので、とりあえずこれで様子を見ます。

原因はわからないものの、上記の件から、予約ダウンロードウィンドウの表示関連に
問題がありそうだということがわかります。
予約ダウンロードウィンドウに記事を表示する場合は、処理を速くするために
全記事の中からウィンドウ内に表示する部分だけを切り取って表示しているはずで、
この辺のライブラリとかアルゴリズムに、64bit Win7と相性の悪い部分があるの
かなあ…とか考えています。
もう対症療法以外に対策が存在しないのが悲しい…

私も昨日から変です。遅くはなっていませんが。
予約リストが40万を超えたあたりで強制終了して、
予約リストが消えたり。
今日は自動巡回中にHNRが強制終了します。なんでしょう？

酢こんぶさん、もしかしてHNRのホルダのセキュリティ設定
修正し忘れていません？
HNRはProgramFiles(x86)以下において、フォルダのプロパティで
セキュリティ設定で usersのアクセス権をフルアクセス可能にし
てください。そうしないとwin7以降はユーザー名\appdata\roaming
辺りにホルダなどを作ります。
で、アクセスするパス名が長くなり、アクセスが遅くなる。
マルチユーザー運用を考慮した結果と思いますが。
私もwin7pro 64bitに移行した際にバックアップファイルを
復元してHNRを運用してたら、NHRフォルダ内の更新がおかしいことに
気づいて修正しました。

古いソフトをProgramaFilesなどに手作業でインストールする際は、
必ずアクセス権を修正してください。セーブファイルが
見つからなくなります(^_^)

追加です。
フォルダのアクセス権の問題はvista以降＆64bit
で発生します。
普通にコピーするとプログラムからの書き込み
権限がありません。すると、osはusersディレクトリに
フォルダを作ります。
古いゲームなどはアクセス権を変更し忘れて、
フォルダ内のセーブデータをバックアップしても
実際は更新されていないことになります。

>酢こんぶさん、もしかしてHNRのホルダのセキュリティ設定
>修正し忘れていません？

HNRはシステムドライブ以外に置いてあって、ログインしてるのは
アドミニ権限持ちのユーザ、さらにUACはうっとおしいので最低レベル
という状態なので大丈夫です(^_^;
セーブデータも確認して問題ありませんでした。

お気遣いありがとうございます。

やはり権限は関係ないようですね。
少し試してみました。一時的にさらのHNRをEドライブに於いて
管理者権限で実行したのですが、やはりフルアクセス権限もって
いませんね。アドミニ権限は万能ではありません。真のアドミニ
権限はadministoratorでログインしたときだけです。
カーネルに関わるソフトをアドミニ権限ユーザーでインストール
するときに、旧ドライバを削除＞再起動＞インストール　するタイプで
無限再起動を繰り返すことがあります。
XPの時代はadministoratorアカウントが有効だったので問題は
起きなかったのですが。

それより、気になるのはHNRのログなどの保存管理です。大量に
ダウンロード履歴や、予約履歴ファイル等が残っていませんか？
HNRがファイルを削除する基準が変更時刻ではなく、作成日時
で行っているようで、HNRフォルダを復元した時が作成日時に
なります。
ですから、バックアップ＆復元を繰り返すといつまでたっても
削除されません。私のところでも再インストールの繰り返しで、
ログなどのファイルが一時期、一ヶ月分近くたまってました(^_^)