XSplit installer removes directory junctions

[Tsaukpaetra]

@powerlord said:

ever run into

I blame custom code to "automagically" create the target directory.

[powerlord]

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.

[Tsaukpaetra]

@powerlord said:

I have no words....

[marczellm]

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.

[anotherusername]

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 named C:\Users exists, delete it
    * create folder C:\Users
    ...etc

If the folder named %appdata%\XSplit existed in the first place, all would be well.

[flabdablet]

@anotherusername said:

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.

@Tsaukpaetra said:

TRWTF is not having transparent copy-delete if nodal rename doesn't work.

They have that. They just don't use it.

[Tsaukpaetra]

Interesting read, for sure.

"Although you shouldn't do this, it's actually Okay through pedantry".

[flabdablet]

@Tsaukpaetra said:

"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."

[bugmenot]

@powerlord said:

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!

[anotherusername]

@flabdablet said:

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.

[bugmenot]

@marczellm said:

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.

[flabdablet]

@anotherusername said:

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 to D:\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 move C:\Users\flabdablet\Documents\Unwanted-Folder to some subfolder of C:\$Recycle.bin would actually require a recursive folder copy from drive D: to drive C:, followed by a recursive folder delete (of the source folder if the copy worked, or the destination folder if it didn't). This is what MoveFileEx 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.

[bugmenot]

@flabdablet said:

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.

[Tsaukpaetra]

@flabdablet said:

particular bug has since been fixed

FWIW, I don't think it has. Apparently there aren't enough squeaky wheels for it.

[flabdablet]

@bugmenot said:

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.

[ben_lubar]

A filesystem may not even implement rename(). Just use mv programmatically.

[Zemm]

@Tsaukpaetra said:

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: then c: worked well and tricked it to run. It was only like a 300KB so NFI why it thought it needed a harddrive?

[dkf]

@ben_lubar said:

A filesystem may not even implement rename().

But filesystems that don't are listed in the dictionary under the entry for “retarded”.

[flabdablet]

As are filesystems that don't make it an atomic operation relative to other concurrent system calls.