Slashdot Mirror


Developer Accidentally Deletes Three-Month of Work With Visual Studio Code (bingj.com)

New submitter joshtops writes: A developer accidentally three-month of his work. In a post, he described his experience, "I had just downloaded VScode as an alternative and I was just playing with the source control option, seeing how it wanted to stage -- five thousand files -- I clicked discard... AND IT DELETED ALL MY FILES, ALL OF THEM, PERMANENTLY! How the f*uk is this s*it possible, who the hell is the d******* who made the option to permanently delete all the files on a project by accident even possible? Cannot even find them in the Recycle Bin!!!! I didn't even thought that was possible on Windows!!! F*ck this f*cking editor and f*ck whoever implemented this option. I wish you the worst.'

34 of 765 comments (clear)

  1. Version Control = Good by brian.stinar · · Score: 5, Insightful

    This is why offsite backups, and revision control, is a good idea...

    1. Re:Version Control = Good by Anonymous Coward · · Score: 5, Insightful

      What kind of idiot only has one copy of 3 months of work?

    2. Re:Version Control = Good by Shatrat · · Score: 4, Funny

      Sounds like he's a diploma-mill coder who doesn't understand such things. 3 months was probably his entire career...

      --
      09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
    3. Re:Version Control = Good by Aighearach · · Score: 5, Informative

      This isn't about backups, it is about not having a central repository. It isn't enough to have revision control, you have to actually be checking it in to a repository and sharing code. Even if you're only sharing with yourself, you still want your revision control to work well. And if you're not synchronizing anything, then you're not even getting feedback about if the system is working.

      It isn't enough to commit the code, you also have to push it somewhere. Even if that is just a repo on the same box.

      You don't want to restore this situation from backups, you want the restore to be from the repo. Much simpler and more to the point. And the backup would be of the repo, not the working directory!

    4. Re:Version Control = Good by Z00L00K · · Score: 4, Interesting

      He was from I understand trying out a revision control system that was pretty buggy.

      In general I have found out that source control systems related to the Microsoft environment are tricky. They used to have something called Source Safe, it was fine until the repository disk was full, then you lost everything.

      --
      If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
    5. Re:Version Control = Good by F.Ultra · · Score: 5, Interesting

      I don't think that Source Safe ever works fine for any definition of the word. Back some 12-15 years when I was working at a "Omg we can only use Microsofts products" place it was common to see our dev chief roll back the entire Source Safe repository from backups. Some times I saw him do this on a daily basis. Another fine touch where when some dev checked out some files and went on a 5 week vacation leaving the file locked in Source Safe, not the good old days :)

    6. Re: Version Control = Good by bobbied · · Score: 4, Insightful

      I've seen it delete the .git dir before so unless you also push it to a remote, that won't necessarily help.

      Offsite backups, file system backups, wayback machine? Any of these works with Git... Of course, why use Git if you only keep one repo laying around...

      BACKUP your important stuff or stupid mistakes will cost you..

      --
      "File to fit, pound to insert, paint to match" - Aircraft Maintenance 101
    7. Re: Version Control = Good by tk77 · · Score: 5, Insightful

      What? Why not? Git is perfectly fine for a single developer. I use it all the time on personal projects. You can even create multiple local repositories so if you screw up your primary tree you can easily recover it.

    8. Re:Version Control = Good by rogoshen1 · · Score: 5, Funny

      he doesn't have any code left to store, so it's a non-issue!

    9. Re:Version Control = Good by taustin · · Score: 5, Funny

      What kind of a developer doesn't know that Windows programs can permanently delete its own data files?

      I think we know what kind.

    10. Re:Version Control = Good by swillden · · Score: 5, Funny

      What kind of idiot only has one copy of 3 months of work?

      No doubt.

      I once worked with a guy who had the opposite problem. He did not trust the version control system, or much of anything else. He'd check the source out, copy it once onto a USB drive and a second time to his work directory. Then he'd remove the USB drive and put it in a drawer for safekeeping, then proceed to work on the code. Periodically he'd stop and copy his changed files to the USB drive. When he had completed some work, he'd copy the changed files over to the checkout location, then commit the change to the version control system.

      Where it got really nightmarish is when he had multiple changes in progress at once. He'd have a checkout for each stream of work, plus a copy of each checkout on a USB drive, plus a work directory for each. He tried very hard never to do that, which meant he was always refusing to fix important bugs because he was already working on something else, even if what he was doing was less important, just because it was too hard for him to context switch due to his lame system.

      If you're wondering how he kept everything straight, he didn't. He frequently forgot a file or two when copying from his work directory to the checkout, resulting in commits that didn't build because they were missing part of the change (even worse was when they *did* build). Once in a while, he copied from the wrong work directory. As far as I could tell, he never actually used the USB drives for anything at all, just copied to them and put them in a drawer.

      What about merge conflicts? Heh. Merge conflicts terrified him. He was always trying to convince people not to touch any file that he was working on, and advocating for replacing the version control system with one that used a locking model, so he could lock "his" files and be sure that no one else could work on them.

      I was a contractor and only worked at the place for about two months. I still felt like strangling him; I don't know how the others who had to deal with him long-term did it.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    11. Re: Version Control = Good by Just+Some+Guy · · Score: 4, Informative
      That's not true:

      # Create an empty git repo.
      $ cd /tmp && git init --bare repo.git
      Initialized empty Git repository in /private/tmp/repo.git/

      # Clone it.
      $ git clone repo.git test_dir && cd test_dir
      Cloning into 'test_dir'...
      warning: You appear to have cloned an empty repository.
      done.

      # Create a file and add it to the repo.
      $ echo foo > foo && git add foo && git commit -m 'Added foo'
      [master (root-commit) 1813607] Added foo
      1 file changed, 1 insertion(+)
      create mode 100644 foo

      # Modify that file and add the change to the repo.
      $ echo foo2 >> foo && git add foo && git commit -m 'Modified foo'
      [master 6cb6f22] Modified foo
      1 file changed, 1 insertion(+)

      $ cat foo
      foo
      foo2

      # Push the change to the repo we made earlier.
      $ git push
      Counting objects: 6, done.
      Delta compression using up to 8 threads.
      Compressing objects: 100% (2/2), done.
      Writing objects: 100% (6/6), 421 bytes | 421.00 KiB/s, done.
      Total 6 (delta 0), reused 0 (delta 0)
      To /tmp/repo.git
      * [new branch] master -> master

      # Go back to the first version of foo. This simulates the case where
      # we pushed the first commit, then someone else added the second
      # commit.
      $ git reset --hard HEAD^1
      HEAD is now at 241f76f Added foo

      # Now change that file in a different way.
      $ echo foo3 >> foo

      # See? It's different from that second commit.
      $ cat foo
      foo
      foo3

      # Try to pull in that second commit that would overwrite the
      # uncommitted change we just made. Git has your back.
      $ git pull
      Updating 241f76f..3a175e4
      error: Your local changes to the following files would be overwritten by merge:
      foo
      Please commit your changes or stash them before you merge.
      Aborting

      --
      Dewey, what part of this looks like authorities should be involved?
    12. Re:Version Control = Good by Gussington · · Score: 5, Insightful

      What kind of a developer doesn't know that Windows programs can permanently delete its own data files?

      I think we know what kind.

      What kind of developer doesn't even know that when Windows deletes a file, the file is still there, only the index is deleted, any data recovery util will get it back.
      It would've taken less time to recover the deleted files than rant about it on the Internet...

  2. Git by irrational_design · · Score: 4, Informative

    Fortunately he can just retrieve his files from his Git repository, right? Or... he just learned a painful lesson of why you always use a code repository.

    1. Re:Git by swillden · · Score: 5, Interesting

      Fortunately he can just retrieve his files from his Git repository, right? Or... he just learned a painful lesson of why you always use a code repository.

      I have to take this opportunity to tell my favorite oh-shit story.

      Some twenty-odd years ago, I was working on an embedded system project which had about 60 person-years of development effort into it (20 developers, three years). We worked on HPUX workstations with our home directories NFS-mounted on a big Network Appliances NFS server. The server was pretty cool tech for the day, making use of RAID for redundancy, with nifty snapshotting features, including automatic snapshotting that created a set of hidden subdirectories in each directory with your files as they were an hour before, two hours before, etc. Getting back any old version was super easy. Plus we all used CVS, and the CVS server also used NFS storage.

      So... all of our eggs were in one basket, but it was a highly-reliable and flexible basket and, of course, the sysadmin made nightly backups, rotated the tapes offsite, etc. The backups even included the snapshots, providing quite fine-grained history from any point in time. So not bad.

      Well, one day something went wrong, and the NFS server lost everything. I don't know if it was hardware failure, if the sysadmin accidentally did something like "rm -rf /", or what. But it was all gone. All of the developers' home directories, with their working copies, and the central CVS repository. Every Single Line Of Code, all of the design documents other that what happened to be laying around in hardcopy, everything. 60 person-years.

      Oh shit.

      But, backups, right? No.

      Not one.

      The sysadmin had never tested his backups, and it turned out that his backup script didn't have permission to read any of the directories where the important data lived. The backup tapes were all useless. He had dozens of methodically-archived off-site copies of the NFS server system binaries. You know, the ones that come on the installation media.

      OH SHIT!

      Luckily, we had one major customer that was so big, financially, and so influential in the relevant industry, that when they signed their contract to buy our product, they made us commit to keeping a developer on-site, full-time. So we all took turns spending a couple of weeks at a time living in a hotel and working in their facility, on the other side of the continent. And, most importantly, there was a development workstation there. With a local copy of the code that was updated via FTP as needed.

      Now, for you young'uns that only know about distributed version control systems, CVS wasn't (isn't) such a beast. In CVS there's one central repository which has all of the versioned history, all of the branches (not that there were many, because working with branches was a pain in the ass), all of the tags, etc. When you check out the code, you get only the current head revision of the one branch, no history at all.

      That's what this one remote workstation had. A checkout of HEAD, as it was a couple of weeks before the disaster. We carefully copied that, and FTP'd it back home, and used it to start a new, fresh, CVS repository. All of the commit history was gone, and a couple of weeks of work by 20 or so people, but we had nearly-current code. All of the design docs and other bits and pieces were gone, but we had code.

      You may be wondering if, at this point, the sysadmin got canned. He did not. He was called onto the carpet and told that we HAD to have good, tested backups going forward. He agreed that it would be his top priority. A couple of weeks later, he reported back to senior management that we had good backups.

      My boss decided to test it. He disabled snapshotting of his home directory, created a file, put some stuff into it, waited a day (so it would get backed up to tape), then deleted it and walked over to ask the sysadmin to recover it for him.

      The backups still didn

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  3. So, let me get this straight... by djbckr · · Score: 5, Insightful

    He clicks "discard" and it deletes the files. This seems a reasonable outcome. Did he not have any backups? I'm pretty sure that is the *real* WTF.

  4. Oh my god will you bloody editors do some work by wonkey_monkey · · Score: 4, Funny

    A developer accidentally three-month of his work.

    I think someone accidentally a word.

    And what the hell is a "three-month"? If that was ever a thing, it hasn't been for about 300 years.

    --
    systemd is Roko's Basilisk.
  5. Blaming the victim = bad by Anonymous Coward · · Score: 5, Insightful

    The software redefined the semantics of "discard" without informing the user. In Git, discard means "drop pending changes". In VS Code, apparently, discard means "delete and purge all historical references --force". How the hell can the VS Code devs justify introducing such a dangerous and confusing change?

    Captcha: horror

    1. Re:Blaming the victim = bad by jtara · · Score: 4, Informative

      In Git, discard means "drop pending changes".M

      It was ALL PENDING CHANGES.

      He never did any commits!

  6. If he's very very smart by Anubis350 · · Score: 5, Insightful

    If he's very very smart he shut down the machine immediately, mounted the drive read only and recovered the files. The chances are most of them were just unlinked and can be recovered since they havent been overwritten yet

    --
    "goodbye and hello, as always" ~Prince Corwin, from Zelazny's Amber series
  7. The lessons of BACKUP !! by ripvlan · · Score: 5, Insightful

    Now that he's 18 - he has discovered the world isn't fair.

    He goes three months and doesn't have a backup? Even in a ZIP file or on a USB drive, or "insert cloud drive service here"

    An unfortunate mistake and maybe even a poorly implemented feature.

    but I have little sympathy because - well his HD could have crashed or a crypto-worm or... basic data loss could have occurred.

    However - how'd we all learn this lesson? Let others stumble before us or put our own finger in the fan !!!

  8. Re:Guy made a mistake by Jiro · · Score: 4, Insightful

    Just because the user could have navigated the confusing user interface doesn't mean it's his fault. Microsoft created the user interface.

    By your reasoning there is never any such a thing as a user interface problem because the user could always have done something else.

  9. Big Red Button by jtara · · Score: 5, Funny

    "I pushed that big red button and it FUCKING NUKED NORTH KOREA!

    Fuck you, fuck you, fuck you, why would anybody design such a piece of crap!

    Fuck you, joint chiefs of staff!

    Fuck you, football carrier!

    Fuck you, Microsoft, or whoever designed that ugly piece-of-shit fat green-screen laptop!

    Fuck you, Dr. Strangelove! How did we ever hire such a wacko? Nice salute, though! You should
    have fixed that thing a long time ago! I saw the documentary!"

    (Sorry, I'd meant to post this in ALL CAPS, but Slashdot needed to protect everyone from my YELLING...)

  10. Bitbucket and 3 copies minimum by CraigCruden · · Score: 5, Informative

    A single copy on Dropbox that has no SLA with you... is not sufficient.

    You can setup a free account for a private repository on Bitbucket (free for small teams of ... one). (offsite cloud backup).

    You should also be doing regular local backups and rotating them at a friends house as well (3 copies minimum).

  11. question by shentino · · Score: 5, Funny

    Is it ok if we call this developer a git?

  12. Re:Guy made a mistake by ShanghaiBill · · Score: 4, Insightful

    ... and it's Microsoft's fault?

    Yes, it is partly Microsoft's fault. Tools should be designed assuming users will sometimes do dumb things, or sometimes accidentally click the wrong button.

    This guy is clearly a moron, but there are a lot of morons out there, and software should be designed with that in mind.

  13. Re:Guy made a mistake by MightyYar · · Score: 5, Insightful

    There may very well be a user interface problem with the product. I don't want to blame the victim.

    However, this guy was going to lose his work someday. Maybe it would be a hard drive failure. Maybe a corruption. House fire. Who knows? The point is eventually he was going to have data loss because he doesn't back up. Microsoft may very well be the direct cause here, but this guy was NOT following any kind of best practices.

    --
    W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
  14. Just tried it by Zalbik · · Score: 5, Informative

    So just for fun, I tried it.

    Did he happen to ignore the popup with the big yellow exclamation mark that says:
    "Are you sure you want to discard ALL changes? This is IRREVERSIBLE!"

    At the very least the ALL CAPS WITH EXCLAMATION MARK! should have possibly made him think "Hmmm...this seems to be a pretty important question"

    But apparently he decided: "Ah, screw it. It's only 3 months of my life".

    Given that level of skill, I can't think much of importance was lost.

  15. Re:3 months no backups... of course blame the dev. by networkBoy · · Score: 5, Insightful

    to add clarity (and my $0.027)
    It is *absolutely* the developer's responsibility, but *not* his fault.

    The software in question really shouldn't do something this drastic without a second window saying "This will erase files from disk. Are you sure you intend to do this?"

    --
    whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
  16. Re:Guy made a mistake by TWX · · Score: 5, Insightful

    I'd agree with this, especially in the context of the way Microsoft has trained users into normally expecting prompts when actions have very serious, arguably permanent results. User bears some responsibility, but when the design mentality of the UI since the beginning of the company has been to use confirmation prompts then there's an expectation that this will continue.

    If I were him I'd immediately boot to some utility that scans the disk for filesystem clusters marked as deleted/available to attempt to undelete them. That is still a thing, right?

    --
    Do not look into laser with remaining eye.
  17. Re:Guy made a mistake by Nemyst · · Score: 4, Informative

    I'll agree that the language could be clearer, but it does show this popup when you try doing this right now. That should be a hint that something bad might happen, I'd say.

  18. Git out of here, its great. by TiggertheMad · · Score: 4, Insightful

    A single developer shouldn't be using git.

    Why not? I use it for all my projects, if for no other reason than to not be this guy. If I delete all my local code, its on a server and multiple other systems. it is cheap, simple and keeps everything in sync.

    I have had non-coder friends who have heard about git, and asked if it would work for non-code digital assets. (Pictures, e-books, music, etc).

    --

    HA! I just wasted some of your bandwidth with a frivolous sig!
    1. Re:Git out of here, its great. by darkain · · Score: 4, Informative

      Totally this! I've been coding for some 20 years now or so. Even for small personal projects, they go into a managed repository. I lost about a week's worth of code in my youth, then I learned about Microsoft Visual SourceSafe, their local repository system. Then I transitioned that over to Source Offsite, a networked version of SourceSafe. This progression then moved through the ranks of CVS, SVN, and now to GIT. Having version control has so many benefits for even single devs, like diffing revision history. "How did I fuck myself up? Oh yeah, I can just check my commit history!" - This has saved my ass countless times.

  19. Re:3 months no backups... of course blame the dev. by KingMotley · · Score: 5, Insightful

    The software in question really shouldn't do something this drastic without a second window saying "This will erase files from disk. Are you sure you intend to do this?"

    It did actually. He said it came up and warned him "are sure to discard all the changes?" (his words) and he clicked yes. Since he hadn't ever checked anything in, his changes were what he had done in the past 3 months.

    No backups, no source control for 3 months, a guy who doesn't know what source control is or does, and just clicks on warning messages without understanding them is his fault. Regular backups would have saved him. Actually using source control would have saved him. Reading the damn prompt and actually being sure before clicking "Are you sure" would have saved him. Another prompt asking are you really really sure isn't going to save him from himself.