I just switched my Win 10 Pro x64 OS drive from a SATA2 Intel SSD to a SATA3 mSATA SSD yesterday via a Paragon Image restore using a GPT layout. I finally got hold of a desktop motherboard that has a mSATA connector on it. Anyways, everything went fine, but then I got to noticing a strange thing that I've never noticed before, using the old Intel SSD. I can create a new .txt file in the root (or any other folder) of my new C mSATA drive, no problem. However, when I go to edit that .txt file, and try to save, I get the message of "Access to C:\{whatever}.txt was denied." I find that perplexing. I have no problems creating a new .txt file, or deleting the file, I just cannot edit, then save, to the created file. I tried to create the .txt file on another drive, then copied that file over to C:\, then tried to edit, but with the same result. I have no problems using my PIM and saving the edited changes on C:\, and all of my programs are functioning just fine, and they make changes to the C:\ drive also. I am the only user, logged in as Admin with a MS account, so I'm wondering why I have permission problems with those .txt files?? I even tried creating a new folder, then creating a new .txt file, then using the context tool "Take Ownership", but even that did not work. Any ideas as to what is going on??
Try launching Notepad in admin mode before editing. It has to do with the permissions of the root in the system drive.
Thanks for the idea, but I use another text editing program that I find more flexible than Notepad. Anyways, I did try that method earlier this morning. I changed the compatibility mode to 'Run as Administrator', but the OS didn't like that idea at ALL. It crashed my text editor, and threw a big error message at me. I'm also of the opinion that it has to do with root permissions, and I just do not know how to change those permissions. I can change permissions on any other folder that is on the C:\ drive, but when I do something in the root, it doesn't like it... I'll try to Google it again, see what I can find....
Well, from what I find, this is normal behavior for the root of C:\ drive. It's set up to where I can create a text file, and delete a text file, I just cannot modify a text file (go figure that one out, MS strikes again), no matter what the permissions are set to. Alright then, no problem. I can live with that, as long as I know it's a normal situation, and not something wrong with my OS setup.
You've migrated your windows install using a third party software package but ms is the culprit again after doing this? Try Takeownership of the txt file.
Yes, actually, I did. It worked just fine. And there was no migration involved. Same mobo, same cpu, same memory. No migration. Only a simple cloning of one drive to another within the same environment. Have you never restored a backup image file, or cloned a drive? It doesn't need to be a MS product for the process to be a success. You have a problem with third party software? Or, do you only use MS approved and authored software? What's that, I didn't hear you?? Try reading the original post. Then if you have anything enlightening to add to this thread, try again.
Error is between user and keyboard I can make, edit, delete, and move text files without a problem. I don't know what you're on about regarding text files on drive C:\ root. I don't usually save things there and I wouldn't recommended you do anyways because do you really want to have something in your root directory of windows?! This is what mine looks like. There were some user agreement text documents, but I deleted those (who really needs those? ). If all else fails I would format and start over. Perhaps maybe get a good anti-virus program if you're really are worried about unknown files and do not know what you are doing (suspect you do not).
The mSATA I got is SATA 3 rated. I double checked using Speccy, and indeed, it's reported as SATA 3. The mobo I got has only 2 'proper' SATA 3 ports, and 3 SATA 2 ports. Those are full, and so I thought to get a mSATA drive, and use the onboard slot for it. Why have it sitting there, not being used, when the Intel SSD I was using was only rated SATA 2? So, I found a really great deal on a 128Gb mSATA that was rated for SATA 3, the result being that I gained 9GBs of SSD space, and also got much better read/write speeds. It works very well for boot, and OS purposes. I don't see why I would not use it for boot. There are no issues at all, with the exception of the .txt annoyance in my OP. I understand that back when mSATA first hit the market, they were only used for cache, but that was a few years back, and things have improved all 'round. Having a regular SSD running the OS really defeats the purpose of needing a cache drive anyway, don't you think? So, taking that into account, I just used the available mSATA slot on my mobo to full advantage, rather than buying a newer SSD that is rated at SATA 3. I bought my Intel X25 SSD years ago, when SSDs first hit the market. We all know that SSDs have a limited lifespan, and mine is well past due to crap out, so purchasing another SSD was a prudent choice for me. Bottom line is that the OS still operates just fine in all respects, with the exception that I cannot edit .txt files in the root of C. Maybe it's been that way all along with the Intel SSD also, and I just never noticed before. I randomly created a .txt file last night, and found that I could not edit it. As I said, in the end, no biggie really. I'll do a winsat here in a bit, and post a result for ya. Thanks!
to edit files in system root dir, one needs to takeownership of those files. it's always been that way. try this, create a new folder in system root, copy or move any files there, try to edit those without taking ownership and see what happens
Yes, the mSATA is a SATA3, as reported by Speccy. However, it is currently in the onboard slot, which is a SATA2. I did not mean to infer that it was running, at the present time, at SATA 3 speeds. I suppose I did not make that clear. Speccy reports drives with two listings... Max. Transfer Mode and Used Transfer Mode. Max. Transfer Mode is SATA3, Used Transfer Mode is SATA2. I don't know about the scores and such, I'm uneducated in those matters. I just did as you requested, and posted the result. And yes, they were run from the mSATA drive, the only SSD I currently have installed in the system. I know that the ssd controller affects speeds in general, and so, perhaps the on-board controller of this mSATA that I got is not up to snuff? Again, bottom line, for $20 I'm not going to complain. I fully realize that if I spent much more $ and got a leading-edge SSD I would realize much faster speeds. That is not in dispute. For me, an old school guy, this mSATA is running just fine. When I start an application, it almost instantly starts, even Photoshop. Large webpages load almost instantly, due in part to my net connection and my SSD speed. How much faster than that could I ever want? I believe I got off track, somehow. The issue is not about the speed of my mSATA SSD, it's about being able to edit and save a .txt file in the root of C:\. I am coming to believe that I just should not attempt to do such a thing. I was thinking of putting a small text file in the root as a note-to-self. But I can put that elsewhere, and still sleep well at night...
No worries! I always enjoy learning new things about computers, and you showed me a way to measure my drive rating. For that, I thank you! Yes, even the worst SSD is better than the best HDD, I do believe.. ( as long as the worst SSD functions in all respects )
Is this a Windows 10 thing? Using Win-7, 64-Bit, I've always been able to edit .txt files or for that matter any file in the Root Directory, no matter the extension. Never had any problems with Win-7 or any prior version of Windows, and never had to take ownership either. Can't remember how many times I've edited Autoexe.bat and Config.sys. Files=20 Buffers=40. What am I missing here?
On my Windows 10 64-bit system, I have to use Run as Admin with Notepad++ in order to edit a text file in root of C which is expected due to permissions. Nothing to see here, nothing new. Although I could not imagine the need for text file editing in the root of C partition.