Nomen

Ok, I figured it out. Even though I had enabled "simple file sharing" on the XP machine, the problem was with the guest account. Simple file sharing uses the guest account. I had changed the name of the guest account from "guest" to "somethingguest". Now, I don't know if simply changing the guest account name was the problem, or maybe I put a password on the guest account, but to remedy the situation I did 2 things: 1) remove any existing password that the "somethingguest" account might have had by resetting the password (and leaving it with no password) 2) create a new account with the name "guest", with no password, and making it a member of guest users. Then I went back to the Win-7 pc and manually mapped the network drive of the XP machine (//ip/share-name) and immediately the shared folder came up, no prompts for name/password. Now I might go turn off the telephony service on XP and see if that does anything...

I've got a Win-7 SP1 Ultimate 32-bit system that has been able to access a folder on a win-98 system with no problems for a long time. I don't think I have any user-name/password set, or if I do, it happens automatically when I want to read/write files on the 98 system from the win-7 system. I have a the win-98 share mapped to a virtual drive on the win-7 system. Offhand I don't recall what I had to do to get things working that way, but it works. I probably had to manually enter the //server/share as /IP-Address-of-98-system/share-folder because browsing for it turns up nothing. I'm trying to achieve the same thing with an XP-pro system. Share a folder on the XP system, map that folder to a virtual drive on the win-7 system. I've gotten as far as entering the //server/share as //ip/share-folder and it seems to find it but I'm asked for user-name/pw. I enter the admin username and PW but it says the PW is wrong. I have the share on the XP set as everyone full access, I don't see anywhere in any of the folder properties or share properties how to specify a share user-name/pw or de-select those credentials. I have turned off completely the XP firewall (unless there is more than 1 check-box needed to pull that off). Until I did that, I couldn't even ping the XP box. I'm confused about Win-7 support for SMB 1.0/CIFS File Sharing Support. I've come across instructions that I should see "Enable SMB 1.0/CIFS File Sharing Support" in the Windows 7 features add/remove list, but I don't see it. I don't know if SMB-1 is key to this issue or a red herring. I note that up until now, I did not have on the Win-7 system, in this key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters The SMB1 dword value, which I have just added and set to 1. I haven't re-booted the win-7 system yet to test if that makes any difference. Assuming that I did not have SMB1 enabled, then I guess that SMB1 is NOT used when win-7 is accessing a shared folder on a win-98 machine? At another site I have a win-7 PC that can access shared folders on a Win-2k server and Win-NT4 server, so I don't know why I'm having so much trouble today getting this working for XP. In all cases, it's the Win-7 machine that is accessing the shared folder on the other machine, not the other way around. Anyone been here before? Edit: I tend to turn off A LOT of services on the machines I use. In this case I'm not so much worried about the win-7 pc as the XP machine. I did have the "Telephony" service disabled, I have enabled it, I don't know if that helped. I am curious about the Telephony service and is it needed for file-sharing on XP. I can find no satisfactory explanation as to if that services plays any role in file sharing (or in general what the heck needs it anyways?).

I've got a few of those motherboards, I might have 4 still in un-opened condition. I did create an XP installation hard drive, fully updated, validated and ready to go, for when I might want to get a few of them up and running. And yes, I did discover that they're limited to only 2 gb max ram, which does suck. I think I did get win-98 working ok on them, maybe not the sound part. What is "Windows ALL" ?

Yes, this system was built from Windows 7 Ultimate, SP1, 32-bit (on a laptop with only 4 gb ram). The install image was built from SP1 with a carefully selected set of updates/patches rolled in (I think I used Nlite?) back in the fall of 2016, with auto-updating turned of, windows defender turned off. No MS updates installed since then. There was not a lot of trust with MS back then, with their underhanded ways to force migration to win-10 and also the telemetry stuff. On this same system I recently dealt with an issue where in explorer I couldn't right-click on a set of files to bring up the context menu if the selection included a zip file. I posted about that here, and found a solution that included a couple new reg entries.

I currently have 5 spreadsheets open, but they are all based on the same "instance" of excel. I've created them by going file, new, worksheet. They show up on the taskbar as 5 individual, accessible worksheets. And as I've said, I can't seem to drag anything to them, or a new worksheet, without the mouse turning into a red circle. Now, if from the taskbar I right-click on the top / main excel icon, and select "Microsoft Excel", a new excel window opens, perhaps this is a new instance of excel, and I *can* drag files to this new instance and the contents get dumped into the sheet as expected. On the taskbar, this seems to be just another sheet, tacked onto the end of the other sheets. I think that because I've saved the contents of the other sheets to their own xls file, that even by selecting "file, new, worksheet" that it doesn't qualify as a new / un-named sheet and it won't allow dragging a file into it. But it's wierd - I *can* drag a file from Everything to an existing worksheet, and it gets dumped into a excel as a new worksheet. But I can't do this from exporer unless it's a new instance of excel.

I do this a lot on my win-98 systems but don't use excel a lot in this particular win-7 PC. I have Office 2000 installed on this PC (I don't think the Excel version matters, but anyways...) and I've just tried to drag a log file over to an open Excel spreadsheet and the minute the mouse is over the sheet area the icon turns into a red circle with a line through it, indicating it doesn't like being there I guess. If I drag the file to the Excel title bar area it doesn't turn into a red circle, it turns into a little plus (+) symbol but releasing the mouse there does nothing - excel doesn't open the file. Now if I use a program like the file-finding program "Everything", if I drag the same file from the Everything window over to excel, the file opens into the spreadsheet as expected. Does anyone have an explanation for this? Or a solution?

My understanding of this certificate mechanism is fuzzy. Does a browser (any browser?) running under Win-7 (or any Win version) query a Microsoft certificate database each/every time the browser is pointed to a site to get an answer back if the site/domain is trusted? Or, is this a static update of some sort? Something that gets downloaded only once and does not mean your computer/browser is always in contact with MS with regard to these certs?

I tried the following, on a win-7 system and also a win-10 system that were both showing this behavior: internet properties / security tab / local intranet / sites - uncheck "automatically detect intranet network" local intranet / custom level / miscellaneous section - drag and drop or copy and paste files (enable) - launching programs and unsafe files (enable) The above did not change anything. I then found this: https://www.thewindowsclub.com/these-files-cant-be-opened-in-windows Which had the following reg edits (done from an administrative command prompt): reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Associations" /v "DefaultFileTypeRisk" /t REG_DWORD /d "1808" /f reg add "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Attachments" /v "SaveZoneInformation" /t REG_DWORD /d "1" /f And that DID fix the issue. On both systems. A reboot was not required. It's really confusing why right-clicking on a zip file on a network share comes back with a security message warning of "opening" the file. I'm not trying to open the file when I right-click on it to bring up the context options. Why is that such a big security issue? (on both systems, I think that winrar was the default handler for zip files, would that make a difference here?)

I've got a Win-7 computer that can access shared folders on other PC's on the local lan. If I navigate to a shared folder and view files, then right-click on pretty much any file I get the usual context menu (copy, cut, properties, etc). But if I right-click on a zip file, a Windows Security box opens, with a message saying - Opening these files might be harmful to your computer - Your internet security settings blocked one or more files from being opened And I'm pretty much stopped from doing anything with the files I've selected or high-lighted. If I open the "internet properties" window, I can set the properties for - Internet - local intranet - trusted sites - restricted sites, I assumed I am dealing with the local intranet. Its security setting was set to medium low. I changed it to Low. This did not change anything. There are times when want to highlight and copy collections of files from a shared network folder, but if the selection includes a single .zip file, I'm stopped dead in my tracks when I want to right-click and select Copy. Instead I get the stupid security warning. How do I change this behavior of windows blocking the context menu from coming up when I highlight a single file or group of files on a network share that includes zip files?

What is that 3.1 version then? Version - of what?

There are times when you might want to attach hard drives from say win-2k / xp / 7 systems to a win-10 box to perform some sort of operation (like bulk file copy or diagnostic or malware scan or clone) but win-10 will mess up these attached drives and render them un-bootable when returned to their original hardware. There is mention of a registry key (NtfsDisableLfsUpgrade) for use in Windows 8 that is supposed to prevent that, I was wondering if it works in Win-10, and I'm also wondering if there's a utility or method built into win-10, or perhaps third-party software, that can undo this LFS "upgrade" to restore an older NTFS volume to its original state.

Does this exchange here from 2015: https://answers.microsoft.com/en-us/insider/forum/all/windows-10-649860-windows-7-617601-dirty-flag/1520f41d-eb80-490b-b8be-7acd9d53c031?page=1 mirror what I'm seeing? Except it deals with Win-10 corrupting win-7 volumes?

--------------------- Type “fsutil fsinfo ntfsinfo <the drive letter of your volume”; example: fsutil fsinfo ntfsinfo C: You should see output similar to the below. -If you see the entry “LFS Version” as 2.0, than your volume has been upgraded to the high performance Logfile structure only compatible with Windows 8. -If you see the entry “LFS Version” as 1.1, than your volume is using a Logfile structure compatible with previous versions of Windows. ---------------------- I'm running Win-7 Ultimate SP1 32-bit and I'm seeing version 3.1 when I run that fsutil command. Last I checked, 3.1 is numerically higher than 2.0, while 7 is less than 8. Curious. Regarding the registry value NtfsDisableLfsUpgrade, for one thing I don't see it on this Windows 7 PC I'm using to type this, but if creating that entry and setting it to 1 means don't upgrade mounted NTFS from 1 to 2 then what does it mean when the OS drive is already at 3.1? Will that result in an immediate downgrade of the running hard drive? Or does it mean don't change the version when mounting any NTFS volume? ------------- Close the Registry Editor and perform a system Restart (not Shutdown) to downgrade all mounted NTFS volumes to a log file structure and version number compatible with prior versions of Windows. Upon the next boot of Windows 8, NTFS will no longer upgrade the log file structure and version number to 2.0 if the above key was set to a non-zero value. -------------- That seems unworkable. You want your existing OS drive to maintain what-ever NTFS version level it currently has, AND you don't want any new mounted NTFS drive to be messed with. Is there a registry entry (for win-10) for that?

The 2 NT4 servers I have running are both SP6. Their initial creation was circa 1998 probably, and through cloning over time have migrated to larger drives. A few months ago I had used Ghost 3 (?) on floppy to clone one of them from an 80 gb drive to a 128 gb sata SSD, worked fine, booted fine, etc. Today I took a number of old backup drives and tried them in a couple different motherboards while booting an actual original NT 4 server installation CD. Upon booting I selected r (for recovery or repair) and every time I'm told that no NT4 installation can be found. The repair thing also asks if you have an emergency recovery disk (which I never made). All of these old backup drives can actually boot NT4. They were 6, 40 and 80 gb size drives, all IDE. The motherboards were circa 1998 to 2000, P2 or P3 (in a socket card). When the NT4 CD boots up, it loads a bunch of drivers, then at one point it detects mass storage devices and it does detect the ATAPI / CD / IDE interface and on one board it detected the SCSI (yes SCSI, not sata) hardware interface that was on this board (it was a Gigabyte BX440 board). For all drives except the 6 GB drive it threw up a warning/message screen about drives with more than 1000 cylinders (I think it was cylinders) as possibly being an incompatible geometry. For a while today I was thinking I needed to give the NT cd a floppy with an appropriate IDE storage driver on it when it asks for additional drivers, and I looked through a lot of different motherboard driver CD's I have that are dated 1996 - 2004 and I looked on the web and I can find NO hint that there is such an animal. The boot partition or volume on the 6 gb drive I had was 2 gb, so no possibility there of incompatible size. So why the NT4 installation CD totally rejects these drives as having working installations of NT4, who knows. It is likely that at one point or many points in the past these drives were connected to XP boxes to have defragging and virus scanning done to them. The 80 gb drive that started this problem has 2 partitions or volumes, both NTFS, the first is 12 gb, the second is the rest of the drive (64 gb I think). But it doesn't matter, if the installation CD can't find an NT4 installation on 2 gb partition on a 6 gb drive then wtf. I also tried the Repair option from a bootable XP-SP3 CD - this time XP does see the NT installation but it asks for the admin password, which I know what it is and I gave it, but XP said wrong password. Go figure. I'm going to get this box up and running from an old(er) backup drive and then copy the current files that were in use from this pooched drive over. Has anyone ever had any luck restoring boot-ability to an old NT drive using utilities like Kaspersky, Hirens, etc?

Yea there's a lot of good info there, primarily if you are setting up a new NT4 install from scratch, and some info about connecting newer version OS drives to NT4 and NTFS tool compatibility. But nothing really about what happens when an NT4 NTFS drive is attached to a newer running system (XP, 7, 10, etc) - something you might want to do for file transfer, file system checking / repair, backup or cloning reasons. This incident happened yesterday, I'll be back at it today at some point.