XSplit installer removes directory junctions
-
-
Here's the fun thing:
If you reboot to safe mode, fix the directory junction, then reboot to normal mode and run the installer again, that time it will work with no issues.
-
I have no words....
-
What is the use case of moving C:\Users or C:\Program Files to another drive?
I created a D:\Program Files and install all my programs there, except the ones that don't ask me where to install them (looking at you Adobe Reader). I created a D:\(my username) folder and put it in the Documents library while removing all other folders so any program is free to put shit in C:\Users while I never look there. Same for the Pictures and Videos library, I redirected them to subfolders of this latter folder.
-
Well, obviously... the installer checks,
- Does a folder named
%appdata%\XSplit
exist?- No
- Try to create a folder named
%appdata%\XSplit
- expand to
C:\Users\powerlord\AppData\Roaming\XSplit
- Does
C:\
exist?
- Yes - Is the type of
C:\
a folder?- Yes
- Does
C:\Users
exist?- Yes
- Is the type of
C:\Users
a folder?- No
- Try to create a folder named
C:\Users
* If something namedC:\Users
exists, delete it
* create folderC:\Users
...etc
- expand to
If the folder named
%appdata%\XSplit
existed in the first place, all would be well.
- Does a folder named
-
What if the D: drive was mapped to a shared folder on the C: drive?
If you give Windows Explorer, Windows Update or (for all I know) other parts of the Windows userland access to any part of D: via a mount point somewhere inside the C:\ tree, it will eventually try to move something physically resident on D: so it's physically resident on C: instead, it will try to use an intra-filesystem rename to do that, and you will see stuff not working as a result.
TRWTF is not having transparent copy-delete if nodal rename doesn't work.
They have that. They just don't use it.
-
Interesting read, for sure.
"Although you shouldn't do this, it's actually Okay through pedantry".
-
"Although you shouldn't do this, it's actually Okay through pedantry".
More like "Although you shouldn't do this, it's just fine for us to."
-
I rebooted to Safe Mode and checked inside C:\Users only to find that only my profile directory existed... and the only files in my profile were XSplit's files.
Yeah. It's because Junction Points have been second-class citizens in Windows for... well ever since they were introduced that Cygwin uses specially-formatted files, rather than JPs to implement symlinks. Even MSFT doesn't bother to make all parts of its software work correctly with them!
-
it will eventually try to move something physically resident on D: so it's physically resident on C: instead, it will try to use an intra-filesystem rename to do that, and you will see stuff not working as a result.
I don't see how that will cause problems, unless ... ohhhhh.
Yeah, renaming a file to the same location through a different path will cause problems... first it'll think the destination file needs to be replaced, and if it deletes the destination file, then the move fails because the source file is gone.
-
What is the use case of moving C:\Users or C:\Program Files to another drive?
The same reason one might split /home, /usr, or /opt from / in the *nix world.
-
renaming a file to the same location through a different path will cause problems... first it'll think the destination file needs to be replaced, and if it deletes the destination file, then the move fails because the source file is gone.
It's not so much that.
MoveFile invokes an intra-filesystem rename, which simply moves an existing directory entry to a different spot within the master file table. It doesn't touch the data that the moved directory entry points to, because it doesn't need to.
But if
C:\Users
is actually a junction point that points toD:\Users
rather than a real directory, then a simple directory entry move is just not going to work because it would involve moving a directory entry from one volume (filesystem in Unix parlance) to another, and the new volume does not contain the data that the directory entry would then be trying to point to.Trying to use
MoveFile
to moveC:\Users\flabdablet\Documents\Unwanted-Folder
to some subfolder ofC:\$Recycle.bin
would actually require a recursive folder copy from driveD:
to driveC:
, followed by a recursive folder delete (of the source folder if the copy worked, or the destination folder if it didn't). This is whatMoveFileEx
does when it detects that its source and destination are on different volumes;MoveFile
just returns an error code.I know from personal experience that using a junction to redirect
C:\Documents and Settings
on Windows XP makes it impossible for users to to recycle their files and folders. Shift-Delete to get rid of them directly does work, but the default recycle-on-delete fails with Access Denied errors. I haven't actually set up a box with a junction over the profile root since learning this, so I don't know whether that particular bug has since been fixed. But there are certainly still others caused by the same mechanism, and MS still explicitly documents this configuration as unsupported.
-
This is what MoveFileEx does when it detects that its source and destination are on different volumes; MoveFile just returns an error code.
Yet another reason to keep the smarts in the filesystem handling layer where they belong.
-
particular bug has since been fixed
FWIW, I don't think it has. Apparently there aren't enough squeaky wheels for it.
-
Yet another reason to keep the smarts in the filesystem handling layer where they belong.
Not aware of a system that actually does handle this case at filesystem level. POSIX certainly doesn't: the rename() system call just returns EXDEV if asked to do a cross-filesystem rename. The difference between your typical POSIX system and Windows, in this particular case, is that the POSIX userland is not so paste-eatingly retarded as to assume that two files sharing a common pathname prefix must necessarily be parts of the same filesystem.
-
A filesystem may not even implement
rename()
. Just usemv
programmatically.
-
You meant like subst C:\DFiles d:?
Heh, I remember on an ancient PC that had no harddrive I tried running a piece of software that "required" a harddrive. Something like
subst a:\ c:
thenc:
worked well and tricked it to run. It was only like a 300KB so NFI why it thought it needed a harddrive?
-
A filesystem may not even implement rename().
But filesystems that don't are listed in the dictionary under the entry for “retarded”.
-
As are filesystems that don't make it an atomic operation relative to other concurrent system calls.