How to lose your work using Undo Copy in Windows
mihai.fmI tested to see what some popular Linux file managers do in this scenario, GNOME Files and KDE Dolphin. Neither of them have undo in the right-click menu. Pressing ctrl+Z pops up the standard "Do you want to permanently delete this file?" confirmation dialog.
Dolphin goes one step further, if you say yes to the confirmation dialog, it shows an additional one: "The file (copy) was copied from (original), but since then it has apparently been modified at (time). Undoing the copy will delete the file, and all modifications will be lost. Are you sure you want to delete (copy)?"
The KDE project does not produce perfect software, but they have attention to details. They are also eager to receive user feedback and to reverse decision after complains. They listen.
The last post of Adventures in Linux and KDE is a good example of this: https://pointieststick.com/2023/05/11/plasma-6-better-defaul...
Agree. While not perfect, they are the best of the DE crop today for my purposes, compared to Gnome, OSX and windows.
Dolphin is the correct behavior.
A similar annoyance is the fact that excel's undo applies to all open excel files. Make a change in a.xls, make a change in b.xls. if you ctrl-z twice with b.xls focused, it'll undo both of the above changes!
This has bitten me more than once. Does anyone actually want this behavior?
I ran into this issue and looked it up. It was an intentional design choice, and kind of makes sense when you realize that Excel sheets can have reference of each other -- they are not necessarily independent. Of course a lot of people probably never do that in their entire lifetime when using Excel and can feel annoying.
They could solve that by keeping track of references and asking you though.
As a daily Excel power user, I'd prefer to just know that there is one expected behaviour, and not to be bothered by a context window. The fact that ctrl-z just changes context to the other workbook is enough notification in itself, and I can just ctrl-y otherwise.
Wouldn't it be a good compromise to ask you on the first occurrence?
No, because I get the point about context very, very quickly. I can’t imagine anything worse than being asked every time when I know exactly what’s going to happen.
Sheets or docs?
Within one doc, and multiple sheets makes sense, I guess.
Across docs doesn’t make sense to me.
Docs.
It's for when you want to have distributed data stores.
For example, if you're building out a doc to track your net worth, income, and spending habits:
- One main sheet that collates all the data required here (e.g. credit card statements, in-flows and out-flows from bank accounts, current debts and current assets)
- Have 3 more docs:
One that collates and summarizes your credit card charges
One that collates your bank statements
One that collates your assets and liabilities
///
Let's say my "credit card charges" sheet automatically pulls in my charges over API, and appends them to the "Charges" sheet in the "Credit Card.xls." Then the "Summary" sheet in this "Credit Card.xls" summarizes this information into something useful. My "Main.xls" (that collates all of my data into something even more readable and useful) can then pull data from this "Credit Card.xls" sheet (through API or locally), and automatically keep itself updated.
I could stuff this all into one single doc, with numerous sheets, but I don't want to deal with the cognitive overhead of having to navigate through an enormous amount of sheets I rarely (if ever) need to touch (again).
Perhaps I don't even have access to the physical "Credit Card.xls" doc, because my personal assistant automatically appends to it, and keeps it uploaded somewhere.
I could stuff this all into one single doc, with numerous sheets, but I don't want to deal with the cognitive overhead of having to navigate through an enormous amount of sheets I rarely (if ever) need to touch (again).
So instead, everybody else has to deal with the cognitive overhead of a document model that is used by no other mainstream PC software program known to Man.
If the point is to only have to work with one doc, then undo across docs is still not useful.
You can definitely reference cells across workbooks
Excel is a law unto itself. The 'feature' that irritates me the most is how a cell copy is forgotten unless you paste immediately. Bear in mind that this is an application so iconoclastic that it had its own C compiler.
This is the thing with Excel. It has such a long history that it had to invent a ton of GUI interactions. A boatload of those interactions were codified in Excel before we created standard ways of doing things that even macOS, Windows and Linux share. In that sense, the modern history of Excel is the slow regression of the app to OS conventions.
For the longest time, Excel had its own windowing system within the app. It's only recently that the Office team saw the light and let the whole OS called Windows control window management in Excel.
Own C compiler? IIRC, that's not quite true. I worked on the C/C++ compiler team at Microsoft from 1991 to 2007, and I don't remember us producing a drop of the compiler just for Excel. I do think there was a special compiler flag for them, though, that fixed the order in which global variables were laid out to duplicate the source order. It was either Excel or Word that saved state by taking the addresses of the first and last global variables of interest, then dumping all memory in that range to disk. The flag was something like -bzalign. The bz stood for Bozo, which hints at the compiler team's thoughts on the practice.
They may be referring to a telephone version of the story that excel was originally compiled to p-code for compactness.
That sounds reasonable. I'd forgotten about the p-code version. I think that was dead by the time I started. I was also fortunate enough to avoid working on the 16-bit compiler backend, and just worked on the 32-bit, referred to internally as the n386 backend, which was pretty much a complete rewrite. The p-code backend would have been a variant of the 16-bit version.
The 'own C compiler' is from Joel Spolsky from when he worked at Microsoft: https://www.joelonsoftware.com/2001/10/14/in-defense-of-not-.... And indeed this states that it was p-code. I'm old enough to remember when p-code was - briefly - a very hot idea.
I know we shipped p-code for general usage, not just internal like Excel. But it might have been internal-only in the mid to late 80s. I found a link [1] talking about some p-code internals, from April 1992, by the guy who hired me at Microsoft about a year before that. The compiler team definitely viewed Excel as one of their most important customers, and were willing to do lots of work to satisfy them.
So p-code wasn't actually dead when I started, but instead shipped with the C/C++ 7.0 compiler, which predated Visual C++. I never worked on C7, since that was 16-bit, and p-code wasn't part of any 32-bit compiler, as I recall.
[1] https://techshelps.github.io/MSDN/BACKGRND/html/msdn_c7pcode...
One program that does copying right IMO is tmux, it keeps a list of recently copied things, which you can view by pressing Ctrl-B = and choose which clipboard to paste.
Very useful when you need to copy multiple separate strings without going back and forth between windows. I've caught myself doing optimistic copying - if I see something that i might need to paste in the future, like git commit hashes, file names, etc. I just copy them all and store them in the clipboard list.
I think there is a program "clipmenu" which does this for X11, but haven't used it too much.
This is my must have extension. Gnome has one and there's an app for that on MacOS. Multiple clipboard entries are such a trivial but useful change that I can't go back to the old way anymore
notepad++ has this feature, and I think current windows versions do as well
I'm continually bewildered by some of Excel's design choices. You can't have two files with the same filename open at the same time even if the files are in different directories. And you can't, for some reason, save to a path with square brackets in it. (You can save it with round brackets, rename the file, and then load the file perfectly fine, though.)
All of that sounds perfectly sensible.
I think Excel is still the old mdi application that has been hacked to look like a sdi application. It’s only a recent innovation that it is possible to have two files open with the same filename.
They fixed that "same file name" annoyance? We have Office 2021(?) at work and it still has that "feature".
That must be a very recent change - I'm sure I've run into that limitation not more than a few months ago.
You can work around this by starting a fresh instance of Excel. Run -> "Excel.exe /x"
Excel is an MDI app pretending to have one document per window. It still has the unified undo buffer from that architecture.
I haven't used Excel much in the past decades but I'm surprised to see the undo behaviour remaining unchanged. Next time you tell me 1904 date formatting is still a thing...
Excel is the archetypal backwards compatible program.
Since Windows 11 includes extensive telemetry, it is possible that Microsoft intentionally designed it this way for user productivity.
Excel has several UI quirks that date back decades. It's never been consistent with the rest of Office even. If Microsoft changed it the accountants would revolt.
> If Microsoft changed it the accountants would revolt.
What's stopping other trades from forming a similarly powerful lobby, like accountants seem to have?
do you have some examples of that quirks?
You can expect data to be destroyed when automatically parsing csv/tsv (default behaviour), especially because it's dependent on the last settings used in the text-to-columns wizard.
Then there's all well-known bugs like floating point addition and locale-dependent function names and 1904 dates.
Conditional formatting accidentally pasting is all over the place.
As others have mentioned, copying and pasting in Excel is bizarre. Highlight the cells to copy; select copy - the source cells now have marching ants around them; perform any action that causes the marching ants to disappear and that content can no longer be pasted. It’s as if those cells are locked as the copy buffer as opposed to some in memory copy like every other copy operation.
It is neither copy nor paste. The copy is "remember this as reference" and paste is "do to this cell to make it relatively similar to the other".
Cut and paste is even better. If the cell to be cut is being referenced, the referencing cell can magically update to the place to paste to.
Selecting and copying the /content/ of a cell is a very normal copy and paste operation.
"Undo copy" seems like it should not even exist. Delete does the same. Seems like the result of trying to hard to "improve" the UI.
It makes sense if you accidentally paste somewhere to immediately be able to undo. But, just like in a text editor, undo should undo the most recent change. Once a copied file has edits, the copy operation isn't most recent, so that's not what should be undone. Of course, file explorer would need to be aware of changes to files it hadn't made for this to work.
I hate to admit it, but this is a valid point. I've used the undo/redo stack in Windows when moving files around and it can be very useful. Consistency of the UI is something I value and often fault microsoft for not having ;-) So undo the copy but they need to get it right - can't undo once the file changed.
i guess simple check for file size and last modification would do the job
>> i guess simple check for file size and last modification would do the job
Or instead of adding even more code, they could remove the feature and let the user Delete the copy.
Except delete sends the file to the recycling bin, where it can easily be recovered. Undo copy removes the file from disk!
No, it makes sense. You might have copied something by mistake, undo is natural, and allows you to keep the undo/redo stack usable.
It just needs to be designed very carefully and not be actionable by mistake without confirmation.
It's actually easy to copy files by accident in windows. Although I think they should prompt the use about whether they want to copy the file rather then add a undo operation.
You know what's even more awesome? Select the desktop and press Ctrl+Z. The last thing you did in Explorer gets undone. Even if it was copying a 100GB file from a network share drive onto your local hard drive. Even if that was weeks ago. It's fantastic.
I was going to post this exact issue.
It's been a thing as far back as I can remember.
The worst part is when you don't remember what the last thing you moved was. You know you've undone something, but you don't know what it is.
Is something going to be broken now?
Are you going to lose something that's now in a place where you weren't expecting it to be any more?
Good luck figuring it out!
Yeah because the desktop is just a special File explorer view.
Does it at least show a confirmation prompt?
Haha you'd think so but nope. I found this out by hitting Ctrl+Z while editing a Word document, no realizing I'd accidentally clicked on the desktop. Next minute, the 14GB VM image that I'd copied to my local machine a week ago was missing.
This happened to me once. I thought I was doing ctrl-Z inside of an app I had been using up to a few minutes earlier, but I hadn't realised that instead a File Explorer window that was currently highlighted.
That was my first thought when reading this: how about accidentally having explorer focused when pressing ctrl-z... Good lord. Usually Linux is more on the rough, "you're a power user so you better never make mistakes" side of things, but according to that other comment, KDE's Dolphin really nailed that scenario.
How unfortunate. Windows should disable the Undo option as soon as the copied file is modified.
Can confirm this is how macOS does it. They remove the file from the stack of Undo actions after it's been modified post-copy.
It's the little things that make the big difference.
MacOS also doesn’t let you cut a file and then lose it by accidentally copying something else to the clipboard, because to “cut and paste” you copy, then use option-command-v to move the file instead of copying.
I think this mistake is usually recoverable in Windows, but
Oops, I accidentally undid my typing.
This mistake is usually unrecoverable but sometimes not, when you’re in file explorer but it’s not a normal file explorer view. For example, when viewing the images of an attached iPhone.
Exactly, that was my first thought.
You'd think that with Windows having an install size of some 7GB that Microsoft would still have room for a tiny amount of code that would prevent this stupid behavior from happening.
For decades, there have been other stupid annoyances with Windows Explorer such not providing options in 'Copy' to allow the automatic renaming of files in cases where the destination contains files of the same name. It stands to reason that there'll be occasions when one doesn't want to overwrite destination files.
For years, I often wondered about how Microsoft employees actually use the stuff they create—or if they use it at all.
How can they continue to use a 'nobbled' Windows when they have the power to actually fix these annoyances? It sort of defies all logic and reason.
Does anyone know the reason?
> How can they continue to use a 'nobbled' Windows when they have the power to actually fix these annoyances?
In a large company, just because you use something, develops it, and is on the specification process, it still doesn't mean you have the power to actually fix anything.
I think you’re underestimating how difficult it is to communicate cross team at a corporation as large as Microsoft.
Undo Copy is a fine feature; there was a recent post here about clipboards and managing the cost of large copied objects.
The problem here is that "undo copy" acted as "undo paste", a ridiculous bug.
Exactly what I was thinking. Copy = context to clipboard, paste = clipboard to context.
Undo copy should only remove the copied thing from the clipboard.
For files, it's not that wrong – copying can be seen as a two step process of selecting what to copy and then where to copy it to, at which point the copy is actually performed. Undoing only the first part wouldn't undo the copy. Still, "Undo Paste" would be a clearer name.
Copy/pasting and undoing pasted text makes sense.
Jetbrains IDEs have a "Local history" feature that is not well known. It watches local files and keeps a backup of previous versions of a file, independently from version control.
This has saved me from a few accidental unrecoverable changes.
git reflog is also your friend.
Iirc VS Code also added that feature last year.
And Vim will also let you go back to any prior state as long as you still have the file open. You can go back to a specific date/time, revert the last 5 minutes etc.
You can enable Vim's persistent undo by setting undofile and undodir options, that way undo works across restarts, no need to keep file open. Another cool feature is Vim's internal undo tree, which allows you to access changes that you undo-ed and then overwrote.
Windows should just prompt for confirmation if the file differs. A reg key should allow a user to disable the confirmation.
Windows 7 does have a delete confirmation for Undo Copy. However, either Windows 8 or 10 removed that confirmation. More reason why people missed Windows 7.
You are right. I didn't get the delete confirmation for Undo Copy on Windows 11, even though I had "Display delete confirmation dialog" checked.
It should be noted that files can often be recovered if you notice soon after accidentally deleting them. You need a file recovery tool that understands your file format (Recuva is a pretty good free tool) but you can save yourself hours of work if you act quickly.
These tools rely on the fact that Windows (and most other operating systems) don't zero out the filesystem when deleting files. This means that the file contents are still there, all you're really missing is the reference to the file contents.
As long as the disk doesn't get overwritten, the files can be saved. The more surefire way to recover files is to stop writing to the drive as soon as you notice your mistake. If you want to use your existing OS for file recovery (much easier, but less likely to succeed) you will need to kill any program running and start a recovery program as soon as possible. Chances are you can't mark the drive you saved the file to as read-only, so speed and luck are essential. It helps to have a file recovery tool installed already, so you don't have to download and install one, increasing the probability of overwriting your precious file contents.
Using easy tools like Recuva and some other paid software, you can often get files back, not only from the original location but also temp files that may have been left behind during editing.
The most reliable way I know involves a Linux recovery disk. It's not exactly beginner friendly, but even moderate knowledge of Linux and the command line can save you hours of work.
The most surefire way I know to recover files is to kill the machine (pull the plug, hold down the power button, etc., so the shutdown process can't write any new files) and to boot into a live Linux distro packing recovery tools. Kali has a bunch, but there are others as well. Make sure not to mount the drive read-write (you probably can't get it to mount automatically after a forced shutdown anyway) so it doesn't corrupt your files and then run recovery software.
Testdisk [1] can often find deleted files, though it's built to recover partitions more than it was made to recover files.
ntfsundelete[2] is a command line tool that was made to find files that were likely to be deleted. It's especially useful if you know the name of the file you're trying to recover.
foremost[3] and its fork scalpel [4] are command line forensic recovery tools originally written by a member of the USAF Office of Special Investigations. They're not as well-maintained as some other tools but they're very versatile if your file format may not be recognized by other tools.
Finally there's Sleuthkit [5], a file recovery tool that will run from Linux leveraging other file recovery tools as well as its own forensic recovery tools, bundled together with a nice GUI. This too was designed for forensic analysis more than anything, but the GUI can help avoid tedious command line work.
With bigger files this becomes harder, because the file may be fragmented and because the larger the file, the higher the probability that new files have been written on top of the old file contents.
For Bitlocker encrypted drives, you'll need to use a tool like dislocker[6]. Make sure to mount data read only though, because Bitlocker is proprietary and reverse engineered tools have a habit of corrupting data when writing to disk.
[1] https://www.cgsecurity.org/wiki/TestDisk
[2] https://linux.die.net/man/8/ntfsundelete
[3] https://foremost.sourceforge.net/
I upvoted this response. It is very thorough and clear. (I can't attest to the veracity of the content but it seems quite logical.) I just wanted to say thanks for writing this. Clearly, these approaches, as you say, are not exactly beginner friendly, but it is great to know that they exist.
I can testify to Recuva being good for this issue. My daughter deleted all files on camera SD card 2 days ago. Popped it out right away and applied recuva on it. It recovered all the pictures as my daughter didnt take any pictures after deletion.
There is one more thing that you can do after unplugging your machine: Image the whole disk to an other one, and try recovery methods on that one. So even if you mess something up, you can try and try again.
I have indeed lost work this way multiple times before. Wish there was some way to outright disable Undo Copy, or at least put it behind a confirmation dialog.
Edit: Actually read the entire page this time and there's indeed a registry edit to disable it, but it disables every other type of undo as well which isn't ideal.
> Wish there was some way to outright disable Undo Copy
The article explains how to:
"Is there a way to prevent this?
Yes. Just disable this silly feature using the Windows Registry.
Create a DWORD entry named MaxUndoItems with a value of 0 under:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced
Alternatively you can run this equivalent command:
reg add "HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Advanced" /v MaxUndoItems /d 0 /t REG_DWORD /f
Log off or restart and the context menu option will be gone. The associated shortcut (Ctrl-Z) will be disabled too (note that this only applies to Explorer, Ctrl-Z will still work in other programs)."
I get that this is a bug in Windows Explorer, I really do. But the discussion is now focusing on all sorts of workarounds like undeleting files, looking up scratch/swap files, etc. When in my opinion, the correct solution is hourly backups. On average, only half an hour of work would've been lost.
I remember a video where the author accidentally deleted all the research and work they did for the video. After panicking and calming down, they typed CTL z (or selected undo in File Explorer) and got all their files back.
This looks like the Windows 11 interface. Thankfully Windows 10 doesn't seem to have that problem. However, Windows 11 has another glaring problem: the context menu includes a trash can icon (not labeled! Although I believe it does have a tooltip if you hover and wait) which, when clicked, deletes the right-clicked item. If you were attempting to open the trash can to look for a deleted file, you just deleted another file.
A simple fix (for MS) would be to just compare the modification time of the copy.
The folder you copy your file (any file that has some importance to you) to should be a onedrive synced folder. Word/Excel/Powerpoint/... files you edit in a synced folder save automatically without the need for you to ctrl+s.
If you undo copy that file you will find it in your onedrive history.
The solution to the “undo copy” == “permanent delete” isn’t cloud storage. The solution is simply not to enable that option if the file has been modified. Or at least hide the option behind very explicit warnings.
I’m not saying cloud storage isn’t a good idea as well. But it solves a slightly different problem while creating new ones (needing a Microsoft account, needing an internet connection, files being suitable for cloud storage, etc).
One might argue that this feature should not even exist, since it does not add anything (except probems) on top of a normal "delete" which you can do anyway.
Edit: I think I got this wrong. Most likely, this is due to some "Undo <action>" always being displayed.
My dream job would be to get hired directly by higher ups (board, VPs, etc.) and be given authority to hunt down and fix idiotic stuff like this.
It is a fantasy because seemingly stupid stuff often has relatively good reasons to exist, but boy would I have a field day at most big tech companies.
I treat every file that's important to me the same when I have to edit it, I hit save first, then edit what needs attention. After making any change more then a few minutes of work, hit save. Undo is always the last option.
I am a terribly slow typist, so this is a habit I formed many years ago.
No amount of hitting save would have saved the author here
My mistake, I meant to say use "Save As" in my post. With save as used, I add a number to the existing file name, thus undo copy only erases the original file copied from one folder to the other folder. (The original file is still persevered in the first folder.) Sorry.
Good, that's what I do. At least it's what I do by far most of the time. Trouble is, the inevitable happens on rare occasions when I don't follow those rules. Moreover, such disasters usually happen when I'm a hurry.
That's why, by now, Microsoft should have recognized that such incidents happen and responded by building in protections into Windows to avoid them.
And how is that relevant to the specific scenario presented in the article?
That would not have helped you in the case described in the article.
When Windows Explorer first appeared 30 years ago, it seemed too complex for me, so I stayed with Norton Commander and its clones that entire time. Guess stupidity can be advantageous.
Also, I've never seen XCOPY fail this way. What is this "Windows Explorer" thing people keep referring to?
Not sure if it's the same issue, but undo (and redo) in Notepad was so frustratingly unstable. Maybe the fixed that already (my last Windows was the 8.1).
In typical Windows fashion, even the terrible behavior is named incorrectly. It looks like it undid the paste, not the copy.
You can add a custom template to PowerPoint. Doing that you would not need to make a direct file copy like this. :)
You know, Windows really needs a single menu where you can manage and customize the contents of the right-click menu.
What did XP do?
Did you check the c:\users\user\appdata\local\temp folder? Make sure to enable 'show hidden files'.
Of course, but average end user shouldn't have to go to folder that they are likely unaware even exists..
Thanks for giving us hope but it's not there