[ 初めての方へ | 一覧(最新更新順) | 全文検索 | 過去ログ ]
『AppData配下に作ったファイルにエクスプローラで辿り着けない』（中途B）
新しいPCで業務用のファイルを使用する為の準備をしていて不可解な事態に陥ってしまいました。 自分にとっては初めてのWin10(しかも64bit)という事もあり、 基礎的な知識が足りないというのもあって、混乱しています。
当初やっていた作業は、 C:\Users\自分\AppData\Roaming\ の中にひとつフォルダを作成し、 その中に幾つかのフォルダ・ファイルをサーバーからコピってくる という以前から使用していたマクロの実行だったのですが、 結果確認の為 エクスプローラでC:\Users\自分\AppData\Roaming\を表示しても作ったはずのフォルダが見当たらないのです。 (フォルダオプションで[隠しファイル]は表示させてます)
実行中にエラーは生じなかったので、おかしいな?と思い、 Excelの[ファイルを開く]ダイアログからRoamingフォルダまで辿って行ったところ、 こちらではちゃんと表示されており、実際コピってきたファイルも開くことができます。 しかし、 Roaming内に作成したフォルダを同じく[ファイルを開く]ダイアログの中で右クリックして [新しいウインドウで開く(E)]をクリックしてみると
「場所が利用できません C:\Users\自分\AppData\Roaming\xxx は利用できません。 この PC 上の場所を指している場合は、デバイスやドライブが接続されているか、 またはディスクが挿入されているかを確認してから、やり直してください。 ネットワーク上の場所を指している場合は、 ネットワークやインターネットに接続しているかどうかを確認してから、やり直してください。 それでもその場所が見つからない場合は、その場所が移動または削除されている可能性があります。」
とメッセージが表示され、出て来たエクスプローラは閉じられてしまいました。
試しに エクスプローラでRoamingフォルダを表示し、そこに手動で[test]フォルダを作ってみたところ、 Excelの[ファイルを開く]ダイアログでも[test]フォルダは表示されています。 しかし、逆に Excelの[ファイルを開く]ダイアログの中でRoamingフォルダ内に手動で[test2]フォルダを作った場合、 エクスプローラでRoamingフォルダを表示しても[test2]フォルダは見えません。
では、 この状態で、エクスプローラで表示したRoamingフォルダ内に、同じく[test2]を作ったら・・・ 普通に作れます。(フォルダ名の競合起こらず) これをExcelの[ファイルを開く]ダイアログで表示すると・・・ [test2]はひとつだけ。
その[test2]の中にExcel側からBook1.xlsxを1つ保存。 エクスプローラから[test2]を見てみると保存したブックは見当たらず。 エクスプローラから[test2]内に右クリック→新規作成でExcelファイルを1つ作成し、 ファイル名をBook1.xlsxにしても、やはりファイル名の競合起こらず、 そのままダブルクリックで開くと、 内容はExcel側から保存したものと同じ内容でした。
[ドキュメント]や[デスクトップ]で同じ事をやってみても、こんな不可解な現象は起こらず、 C:\Users\自分\AppData\以外の場所では発生しないのかな? と思っています。
この症状について検索してみたところ「UACの仮想化」機能に関する記事が引っ掛かるのですが、 %AppData%配下が仮想化されるなんて話は出てきませんでした。 念の為C:\Users\自分\AppData\Local\VirtualStoreの中を エクスプローラとExcelの[ファイルを開く]ダイアログの両方から覗いてみましたが、 どちらで見ても中は空っぽでした。
プロファイルが壊れてるのかと思って、別のアカウントを作成して同じ事をやってみたのですが やはり同じ現象でした。
OS側の問題なのかExcelの側の問題なのかもよく判らず、 ひょっとしたら場違いな質問なのかも知れませんが、 何か糸口となる情報でもございましたら、ご紹介願います。
＜ 使用 Excel：Excel2016、使用 OS：Windows10 ＞
次に、PCのログインは、ドメインサーバ下のユーザーでしょうか。それとも、ワークグループ下のローカルユーザーでしょうか？ いずれの場合でも、ユーザー情報で管理者権限があるか確認してみてください。ドメインの管理者権限は持っていなくて当然ですが、自分のPCへの管理者権限が必要です。具体的には、以下のようにして、情報を見てください。
・WIN+X から、「コンピュータの管理」を起動。
・「ローカルユーザーとグループ」の「グループ」をクリック後、右側の「Administrators」をダブルクリック。
・「所属するメンバ」に、今ログインしている名前があるか確認。（ドメイン利用ならば、「ドメイン名\ユーザー名」のようになってます）
・見当たらないようならば、追加。
ちなみに、手作業だとコピーできるけど、マクロだと駄目なのだとしたら、また別の問題です。 Windows10はセキュリティが厳しくなったため、Excel（というかアプリ全般）を普通に起動すると、管理者権限なしになるので、いろいろ制限されてしまうのです。 こちらへの対応が必要な場合、デスクトップにでもExcel.exeへのショートカットを作成。 Excel.exe の後ろに開きたいブックのフルパスを指定。「詳細設定」から「管理者として実行」にチェックしてください。
（???） 2018/09/11(火) 16:42
mougの方でも似た話がありましたね http://www.moug.net/faq/viewtopic.php?t=77362
・・・解決はしていませんが （2u） 2018/09/11(火) 23:36
ちなみに、ウチでは1803への更新はストップがかかっています。
（???） 2018/09/12(水) 09:52
AppData\Local\Packagesについて調べるとストアアプリが格納されるフォルダみたいです。
Excelには何種類かインストール方法があるので、それによってもしかしたら違うのかも知れません。
（名無し） 2018/09/12(水) 10:28
外出の為まだ確認作業が出来てませんが、
リンク先拝見したかぎりでは「それっぽい」です。
また報告させて頂きます。
取り急ぎお礼まで。
（中途B） 2018/09/12(水) 11:28
MS、「Office」アプリを「Microsoftストア」で提供開始
https://japan.cnet.com/article/35113678/
Microsoft ストア版 Office 2016形式で提供されているのは、
最近のプレインストール (PIPC) 版の一部と、Windows 10 S が搭載された Surface Laptop のいずれか
「Office」アプリだからストアアプリ用のフォルダにパスが変換される、ってことでしょうか？
さらにこの記事の本題のDLL読み込み時の検索パスの変更で、
DLLが読み込めないって質問が来ても不思議じゃないような・・・
（2u） 2018/09/12(水) 19:26
解決しました!! ・・・というか何というか...^^;
ストアアプリ版Officeが入っていた様です。 セットアップした担当さんに確認してみたら、 「そういや、Outlookの設定画面がいつもの奴じゃなかったな～」と^^;
で、一旦Officeをアンインストールして、本来入れるつもりだったデスクトップアプリ版をインストールしたら 例のマクロは所定の場所にちゃんとファイルを持ってきてくれました。(Excelも通常起動モードで)
ホントはいろいろと確認してみたい事があったのですが、 該当機を使用する予定だった別拠点を、これ以上お待たせする訳にもいかず、 既に手元から離れてしまいました。
一応、ご紹介いただいたリンク先と同じ状態だったのかだけは確認しようと思い、 C:\Users\<ユーザー名>\AppData\Local\Packages\Microsoft.Office.Desktop_8wekyb3d8bbwe\LocalCache\Roaming\ をエクスプローラで辿っていくと、やはりそこに目的のファイル達が残ってました。
Windows10バージョンは1803でした。 ストアアプリ版をアンインストールする前に、管理者として実行したExcelで例のマクロを実行してみたのですが、 やはりファイル達はAppData\Local\Packages内にコピーされてしまいました。
また、コピー先の指定をEnviron("APPDATA")で指定していたのですが、
Environ("LOCALAPPDATA")ならどうよ?
と試してみましたが、やはりAppData\Local\Packages内されました。(同じAppData配下ですから当然でしょうか)
素直に他の場所で試すだけの時間が無くて心残りです。 以下もストアアプリ版の内に確認したかったけど、結局出来なかったことですが、
例のマクロは
1.コピー先フォルダの存在確認にFileSystemObjectのFolderExistsを使い、
2.なければMakeSureDirectoryPathExistsで作成
3.Shell.ApplicationのCopyHereでサーバーからファイルをコピーしてくる
4.コピーしたファイルの内、CABファイルに関してはCreateObject("Wscript.Shell").Runでexpandする
という流れだったのですが、 AppData\Local\Packages内に残ってたファイルで、CABファイルをexpandした中身(txtファイル)だけはありませんでした。 多分expandの引数をフルパスで指定していたので「ファイルが無いよ」で終わっていたのだろうと予想されますが、 仮に所定の場所にCABがあったのなら、ちゃんとexpandしてくれたのだろうか? という点が確認できなかったのがちょっと心残りです。 (余談:RainmeterでWMI実行するvbsを呼び出すのに"runas"付ろだの何だの悩んだ覚えがあったので...)
とりあえずこのマクロ内でDeclareしてたのは MakeSureDirectoryPathExists Lib "imagehlp.dll" GetPrivateProfileString Lib "KERNEL32.dll" SetActiveWindow Lib "user32.dll" WNetAddConnection3 Lib "mpr.dll" WNetCancelConnection2 Lib "mpr.dll" です。 「サーバーからファイル取ってくる」という動作自体は実際に出来ていた訳ですから、 少なくともこの子達はちゃんとストアアプリ版でも仕事をしてくれていたんですね。
それと、 このマクロはいわゆる[環境設定]用のもので、 コピーしてきたファイル達の、業務で使用する場面での使われ方は ADODBでMicrosoft Text Driver使ってテキストファイルに接続し、SQL(SELECT文)で必要なデータを取り出す というものでして、 元々確認する予定だった「OSは64bitだけどOfficeが32bit版なら大丈夫よね?」に関しては、 デスクトップアプリ版にした後で確認が取れたので良いのですが、 ストアアプリ版でもちゃんと動いてくれたのかが確認出来ずでした。 (FileSystemObjectとかは動いてたので、多分こっちは大丈夫だったろうなと思ってはいます)
以上です。
他の部署をお待たせしている状況だったので、ホントに助かりました。 ありがとうございました。
（中途B） 2018/09/12(水) 22:57
[ 一覧(最新更新順) ]
YukiWiki 1.6.7 Copyright (C) 2000,2001 by Hiroshi Yuki.
Modified by kazu.