10
7
I have 3 Drives, Boot(C:), Data(D:) and Restore(E:) My C: , which has 116 GB is full, and most of it is in my Appdata\Local (50GB) My D: has 377GB Free Space and I wanted to Know if it is safe to move the AppDta folder to it.
I did this with the Appdata\roaming yesterday and it did not work but after a restart it was back to normal and this time I searched for it on google and made a User\username\AppData folder in my D: drive and went to the properties of Local and manually moved it to the new folder like the search told me and after opening the Local\ElevatedDiagnostics Folder which had admin rights it was possible for me and it is copying everything right now
Will this work? and if not, will it be easy to return back to the previous state like with the roaming folder?
Works for the whole user directory too. – Chema – 2018-05-24T23:10:32.210
@Chema it does, but you have to be very careful to not change any of the folder permissions, otherwise a user won't be able to load their profile anymore. – LPChip – 2018-05-25T07:28:58.027
A bit late (I always hold on updates for a few weeks, to prevent stuff like this), but Windows 10 October's update nuked many Documents folders using this trick. If it happens to you, I hope you've got a fresh backup! (if not, stop using that PC until you get a copy of Recuva).
– Chema – 2018-11-09T20:19:27.967https://blogs.windows.com/windowsexperience/2018/10/09/updated-version-of-windows-10-october-2018-update-released-to-windows-insiders/ «We have fully investigated all reports of data loss, identified and fixed all known issues in the update, and conducted internal validation.» Chea rite!
@Chema it will only happen if you also use OneDrive. The bug here is that if you use OneDrive, but not updated to the latest version before upgrading, only then will you lose your files. If you don't use OneDrive or you have the latest version, then there's not a problem. That said, Microsoft has pulled the update quite a while ago, so upgrading at this point is not even possible. – LPChip – 2018-11-09T20:23:17.030
Two issues are related to OneDrive, but not the first one listed: «Using KFR the user redirected a known folder to a different drive.» KFR is the "official" way to move Documents. I thought I was using symlinks, but now I suspect I ran into problems symlinking the user directory and probably used KFR instead... I'm no longer sure... never are, with Winbugs Updates! – Chema – 2018-11-09T20:44:25.783
I managed to "redirect" the whole {user} folder to d: which is great. But ran into problem where the Start button doesn't work (blank when I click on it). FRIENDLY reminder to set the SECURITY of the new folder to allow the user to access it!! – Joseph Lee – 2019-07-21T07:41:03.923
FYI, a junction is a mount point, not a symlink. The I/O manager implements junctions as hard name graftings. When parsing a path in an open/create context, a junction's security is evaluated, and a relative symlink that traverses it as an ancestor via ".." components handles it as a regular directory. OTOH, in an open/create context, the system does not evaluate the security of a symlink, and a relative symlink will traverse the target of an ancestor symlink rather than the symlink itself.
mklink /d
creates a symlink.mklink /j
creates a junction. – Eryk Sun – 2019-08-29T16:11:37.120@ErykSun I'm a bit confused. So, in short, should I do
mklink /d
ormklink /j
in this case? – Henrik – 2019-12-30T16:21:57.7501@Henrik, I'd use a junction, which basically acts like what's called a "bind" mount point in Unix. The practical difference is when they're traversed while reparsing relative symlinks that have ".." components. A junction mount point behaves more like a cross-filesystem hardlink in that case, so its ".." parent directory is always the literal parent from the path as parsed, whereas a symlink resolves to the target in this case, so its ".." parent directory will be different from the parent in the parsed path. So overall a "Local" junction behaves more like a regular directory. – Eryk Sun – 2019-12-30T22:14:04.860