I have no idea how to use scripts and it won't let me open the file outside of the client. When I choose the file to log to, it appears in that window, with a file size that suggests it's logging successfully, but when I right click it and try to open it, Windows tells me it can't find the file. When I go to the logs folder, it isn't there. I even tried going into safe mode, but the files still don't appear there, even though that's where I saved them. It doesn't make much sense that they're being successfully written to, but I can't open them. Can anyone tell me exactly what to do to try and open them in the client itself? Or maybe why the hell it's not appearing in the folder in Windows explorer? Every new log file I make has this problem.
Opening log files on Windows 7.
Posted by NodmiTheSellout on Thu 05 Nov 2009 04:54 AM — 18 posts, 88,118 views.
NodmiTheSellout said:
... but when I right click it and try to open it, Windows tells me it can't find the file. When I go to the logs folder, it isn't there.
... but when I right click it and try to open it, Windows tells me it can't find the file. When I go to the logs folder, it isn't there.
I don't have Windows 7 yet, but I don't quite get this bit. You see the file in Windows Explorer? And you right-click to open it? But then Windows says it isn't there? Normally you just double-click a file to open it, so what exactly are you right-clicking? Is this something to do with permissions maybe?
Where do you choose to put the log file? Maybe it should go in My Documents, and not wherever MUSHclient got installed.
No no, when I open the folder itself, it isn't there. Maybe taking screen shots would be more clear. . .
This is what it looks like when I open the folder:
http://muserae.com/images/mushlogfolder.PNG
This is what it looks like in the client:
http://muserae.com/images/mushlogclient.PNG
It does seem to be an issue of permissions (what else would the lock mean?), but the files still don't show up in safe mode, and nothing looks amiss on the permissions (I show up as the owner/creator, and I even set every thing I possibly could to "allow"). I also have this client on another computer running XP, and I made a log in the exact same way there without problems. Windows search doesn't even turn up the file; the only time I see it is when I choose a log file in MUSHclient, and the file size is bigger every time I look at it, so it's obviously being written to.
This is what it looks like when I open the folder:
http://muserae.com/images/mushlogfolder.PNG
This is what it looks like in the client:
http://muserae.com/images/mushlogclient.PNG
It does seem to be an issue of permissions (what else would the lock mean?), but the files still don't show up in safe mode, and nothing looks amiss on the permissions (I show up as the owner/creator, and I even set every thing I possibly could to "allow"). I also have this client on another computer running XP, and I made a log in the exact same way there without problems. Windows search doesn't even turn up the file; the only time I see it is when I choose a log file in MUSHclient, and the file size is bigger every time I look at it, so it's obviously being written to.
I have a suspicion Windows is being clever here, and redirecting the log file to a writeable directory (basically for legacy support).
I would try clicking on the downwards arrow next to the word "logs" in the browse dialog, and see where it is really going. Or, RH-click on one of the existing log files, and selecting Properties.
Or try this: Make sure that you have "/" as the scripting prefix in the Scripting configuration, and then type this into the command window (once a log file is open):
That should print the pathname of the log file. This might give a clue as to where it really is.
I would try clicking on the downwards arrow next to the word "logs" in the browse dialog, and see where it is really going. Or, RH-click on one of the existing log files, and selecting Properties.
Or try this: Make sure that you have "/" as the scripting prefix in the Scripting configuration, and then type this into the command window (once a log file is open):
/print (GetInfo (51))
That should print the pathname of the log file. This might give a clue as to where it really is.
It's still showing up as in that folder. Every file I make with MUSHclient does this (I learned this when trying to use scripting).
How to fix it.... Press CTRL+ALT+G to bring up global preferences, and select the logging tab. Change the default directory to something that's not under C:\Program Files.
Why it's happening: Microsoft has been recommending for years that applications don't write to program files on a regular basis. (In the unix world, the conecept is that executable binaries go in /bin, logs in /var/log, general configuration files in /etc). With Vista and I.E. 8 there's a mode that IE can run in for least privileged execution that sandboxes disk writes. With Win7, this sandboxing has made it into the operating system in general. It would be bad for MS to break your legacy apps, so they just quietly force old or intentionally miscoded apps into the sandbox. The log files are actually written to disk under C:\Users\<Profile>\AppData\Local\VirtualStore\......
This feature can be shut off in the security policy of the machine. I expect that like UAC (User account control), this is going to be a Win7/Vista feature that MS introduced to quell some of the "Windoze is insecure" crowd, but will annoy users to the degree that they shut it off and choose to leave the security holes open.
Why it's happening: Microsoft has been recommending for years that applications don't write to program files on a regular basis. (In the unix world, the conecept is that executable binaries go in /bin, logs in /var/log, general configuration files in /etc). With Vista and I.E. 8 there's a mode that IE can run in for least privileged execution that sandboxes disk writes. With Win7, this sandboxing has made it into the operating system in general. It would be bad for MS to break your legacy apps, so they just quietly force old or intentionally miscoded apps into the sandbox. The log files are actually written to disk under C:\Users\<Profile>\AppData\Local\VirtualStore\......
This feature can be shut off in the security policy of the machine. I expect that like UAC (User account control), this is going to be a Win7/Vista feature that MS introduced to quell some of the "Windoze is insecure" crowd, but will annoy users to the degree that they shut it off and choose to leave the security holes open.
The fix seems good, thanks. I still can't seem to find the files to open, though (no AppData folder). Maybe it's hidden somehow? I guess I'll do without the old logs if I need to, but it's kind of frustrating.
You don't need to do without logs. Just change the log directory to a writable one, like somewhere in My Documents.
Yes, I did that part and it's working out, but I still can't open and view the old ones.
The AppData folder is hidden. Open explorer, Hit alt, choose Tools, Options, View Tab, and change the radio button for "Show hidden files, folders and drives".
Or just type in the directory in the address bar.
Or just type in the directory in the address bar.
See.. That is the thing that is going to cause people to shut the feature off, the idiotically stupid decision to place files written into program directories, which might be documents/user editable settings, some place that is "hidden" by default, instead of say, some place in the document path.
WillFa said:
The AppData folder is hidden. Open explorer, Hit alt, choose Tools, Options, View Tab, and change the radio button for "Show hidden files, folders and drives".
Or just type in the directory in the address bar.
The AppData folder is hidden. Open explorer, Hit alt, choose Tools, Options, View Tab, and change the radio button for "Show hidden files, folders and drives".
Or just type in the directory in the address bar.
Thank you! Sorry you had to explain that to me. Everything's good now. New logs are saving into a normal folder, and I can open the old ones.
Shadowfyr said:
... the idiotically stupid decision to place files written into program directories, which might be documents/user editable settings, some place that is "hidden" by default, instead of say, some place in the document path.
... the idiotically stupid decision to place files written into program directories, which might be documents/user editable settings, some place that is "hidden" by default, instead of say, some place in the document path.
Well to be fair to the person that did that (that would be me, I think), in the early days of Windows the Program Files directory was writable (somewhat to my surprise), so it just kept everything neatly together. Everything was installed in one directory, and if you wanted to get rid of it, you just deleted that directory.
In fact, in the early days (Windows 3.1 was when MUSHclient first came out I think), there wasn't even a My Documents folder anyway.
This is the annoying thing about Windows, they keep changing things. People say to you "you crazy guy, you aren't doing things the way you were supposed to *last year* are you? they changed everything since then".
Under Linux, for instance, it is perfectly normal (eg. when installing Smaug) for the source, the executable, the data files, the configuration files, the player files, all to be under the *same* directory in the user's home area (in subdirectories of course, like MUSHclient does).
Now the installer file used to install MUSHclient (mushclient.nsi) is publicly available, and the NSIS installer is a free download, so anyone that wants to can improve the installer.
Nick Gammon said:
This is the annoying thing about Windows, they keep changing things. People say to you "you crazy guy, you aren't doing things the way you were supposed to *last year* are you? they changed everything since then".
Under Linux, for instance, it is perfectly normal (eg. when installing Smaug) for the source, the executable, the data files, the configuration files, the player files, all to be under the *same* directory in the user's home area (in subdirectories of course, like MUSHclient does).
This is the annoying thing about Windows, they keep changing things. People say to you "you crazy guy, you aren't doing things the way you were supposed to *last year* are you? they changed everything since then".
Under Linux, for instance, it is perfectly normal (eg. when installing Smaug) for the source, the executable, the data files, the configuration files, the player files, all to be under the *same* directory in the user's home area (in subdirectories of course, like MUSHclient does).
Nick, you crazy guy, you aren't doing things the way you were supposed to 14 years ago, when windows 95 introduced "program files" and "documents and settings". ;)
I'm not sure Windows is that annoying in this matter. It gave you 10 years of "you can do that, but you shouldn't" before going "you've had enough time to adapt. Can't do that anymore."
Documents and Settings :: ~/ user's home area
Program Files :: /bin, /sbin
Comparing a "per user" installation on Linux to an "all users" installation on Windows isn't exactly fair.
That is just it though. Even some of their own things "bury" stuff in hidden files *under* the documents and settings. Apparently, you are not allowed to look at settings directly either, according to MS. All in all, its quite a mess they created.
Another way to see those files:
In your Windows Explorer screenshot, see that button marked "Compatibility Files" below the address bar between "Share with" and "New Folder"? Click that. :)
---
All in all, I think it would be a good move if we start moving most of the data files to per user accounts, or else %ProgramData%, which is the equivalent global store. The global store makes more sense for scripts and plugins, but its only writable without UAC escalation by administrators (not by unprivileged users). Most people run as administrators on Windows, though. %APPDATA% is probably the best call.
The officially sanctioned way to do this seems to be SHGetKnownFolderPath (http://msdn.microsoft.com/en-us/library/bb762188(VS.85).aspx) with a KNOWNFOLDERID that's one of these: http://msdn.microsoft.com/en-us/library/dd378457(VS.85).aspx
What's necessary is a small patch to MUSHClient to look for its worlds, logs, spelling stuff, prefs sqlite db,and MUSHClient.ini data in FOLDERID_RoamingAppData (%APPDATA%). Plugins should be moved so it's no longer under the worlds directory. Is there anything else that should be moved?
The other problematic bit is that there needs to be a bit of code in the installer that will perform a migration if necessary. I can probably do this patch if everyone considers it desirable, since I don't need to touch the Windows GUI stuff for it. =P
In your Windows Explorer screenshot, see that button marked "Compatibility Files" below the address bar between "Share with" and "New Folder"? Click that. :)
---
All in all, I think it would be a good move if we start moving most of the data files to per user accounts, or else %ProgramData%, which is the equivalent global store. The global store makes more sense for scripts and plugins, but its only writable without UAC escalation by administrators (not by unprivileged users). Most people run as administrators on Windows, though. %APPDATA% is probably the best call.
The officially sanctioned way to do this seems to be SHGetKnownFolderPath (http://msdn.microsoft.com/en-us/library/bb762188(VS.85).aspx) with a KNOWNFOLDERID that's one of these: http://msdn.microsoft.com/en-us/library/dd378457(VS.85).aspx
What's necessary is a small patch to MUSHClient to look for its worlds, logs, spelling stuff, prefs sqlite db,and MUSHClient.ini data in FOLDERID_RoamingAppData (%APPDATA%). Plugins should be moved so it's no longer under the worlds directory. Is there anything else that should be moved?
The other problematic bit is that there needs to be a bit of code in the installer that will perform a migration if necessary. I can probably do this patch if everyone considers it desirable, since I don't need to touch the Windows GUI stuff for it. =P
There was a post by Nick about re-ordering the file structure somewhere, too. I agree and I think it should be done fairly soon, if possible. I've never dealt with the relevant functions though, and I'm still fairly new to the source, or I'd try a patch of my own.
It's an installer thing, I think. Already the program has various variables for where to look for things like logs, and you can change those locations in the GUI.