Using network home auto-mounts under OS X, and having to move users from one server to another after creation?
This works for most programs, but some are poorly written.
Here is why:
Preference files often get written with the full server path in them...
Chrome hides this in the Preferences file: ~/Library/Application Support/Google/Chrome/Default/Preferences "last_directory": "/Network/Servers/server.com/Users/username/Desktop" But Microsoft Office is even worse.... It keeps the server the application was registered on in a preference file: ~/Library/Preferences/com.microsoft.office.plist Nuke that file and MSO works after the move, but the user will have to re-do the first run steps (thankfully not the registration key entry)....
I am sure there are other programs that break on a server move.
Hey dummies, do you hard code paths on your website so it only works on one server?
Chrome and MSO are so bad that they try to open and mount the location specified in the Preference file.
The program eventually crashes and or fails to kill off on log out for the user.
Nothing like lazy programming to make your product seem like it is crap, when it is probably not.
Here is some discussion on the Chromium bug list:
Comment 42 by mar...@chromium.org, Mar 22, 2011 If you think Firefox better suits your needs, then by all means switch to that browser. We aim to be the best browsers for everybody, but there will always be users who have specific requirements that are better met by a different product. Having said all of this, you will probably discover that both Chrome and Firefox do *much* better if you can avoid storing state files on a filesystem that fails to implement full POSIX semantics, and that is shared across multiple logins. Long before Chrome existed, when I was using Firefox as my daily browser, I made it a point to move all of the Firefox state files to local disk. I had a lot less trouble afterwards. All network filesystems (NFS, Coda, ...) have unusual semantics and failure modes. It is better not to use them for parts of the filesystem that are expected to provide full POSIX semantics. This particularly means to never ever use them for /tmp (really bad things happen, if you do!), and to avoid them for some of the files in /home. This especially means ~/.config, ~/.gnome*, ~/.cache, ~/.gconf*, ~/.mozilla and probably a few others that I can't think of right now. None of this means that we shouldn't try to make a best effort to help users who are unfortunate enough to be stuck with a machine, where local storage isn't available. But I would always expect for some problems to remain, if the filesystem is essentially untrustworthy.
I especially love the bits about non full POSIX semantics and "... users who are unfortunate enough to be suck with a machine, where local storage isn't available."
Avoid network filesystems for ~/.mozilla, eh? Network home dirs via nfs etc were around long before programs started becoming written like this as well.
From the looks of the open bugs, many of the bugs would go away with a fix to the file paths in preference and other files....