HN2new | past | comments | ask | show | jobs | submitlogin

A co-worker of mine once wiped out the entire CVS repository at the company we worked for because a symbolic link was placed in his home directory and he thought it was ok to 'rm -Rf' its contents. We were able to build a new repo based off of production and everyone who had changes not in production had to re-introduce those changes, but it was not the developer's fault for wiping out CVS. It was because the sysadmin had set the symbolic links for the primary repository. If you enable developers to do something bad, it isn't always their fault when they do it.

Having intent to destroy something on purpose is a different matter though, and I'm not sure that there is a good argument for it.



Did the sysadmin also forget to create a backup for the repo? I don't think it's a stretch to assume that the developers were somewhat negligent in working on a single repo that can disappear at any time.


There was no backup of the CVS repository. The production server saved us since we were able to treat it as the definitive backup. This was before Git and the concept that everyone had their own copy of the entire repository.

There is a sort of half intent by the developer. Yes, the developer had intended to delete the repository that was in his home directory, but he had no idea that it was actually a link to the master repository.


The developer had hard links or symbolic links? It must have been a hard link to do that type of damage. I find that really dangerous and that's why I never use them. Unless you are using an obscure version of UNIX, rm -rf should delete the delete and not the content of the folder it is linked to.


A hardlink would be safer in this case. If there are two hardlinks to the same file and you rm one of the hardlinks, the other hardlink still works and the file itself isn't deleted.

A symlinked directory, though, being made victim of a recursive rm command, just might result in rm traversing through the directory and deleting everything inside of it.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: