MOVE operation in a PS script has been failing for weeks; original files deleted but not written to new location. Are they recoverable?

Question

We have a script that was supposed to move LOG files off a server onto a local repository. It turned out the author of the script added an apostrophe by accident in the destination:

MOVE /y "C:\XXX\XXX\XXX\audit.*.log" "\\[FQDN]\XXX`$\XXX\XXX\XXX"

(Notice the apostrophe before the dollar sign)

The log files have been disappearing from the server and, presumably because of the typo, they have not been showing up in the repository server.

The third-party vendor who monitors the server has also mentioned that it seems the hard drive is getting filled up, which would be consistent with the size of the missing log files (around 500MB each, daily for the last 6 weeks).

Question: are these missing log files recoverable? Does Windows store files from a MOVE operation somewhere in a hidden/temp folder, or are they gone for good? For the time being, I'm not worried about the hard drive space, as I've corrected the error. I would like to recover the logs, if possible.

The OS of the server & repository are both Windows Server 2019 (I think).

Answer 1

We have a script that was supposed to move LOG files off a server onto a local repository. It turned out the author of the script added an apostrophe by accident in the destination:

The apostrophe might not necessarily be an accident; it is the 'escape' character in PowerShell (e.g. "`n" in PS has similar meaning to "\n" in other languages, both expanding to a newline character).

As PowerShell strings will expand $variables, it is normal to place an escape character in front of a $ that needs to remain a literal "$" (e.g. "foo`$bar"), and even though variable expansion won't happen in your specific example, the backtick still has the same result of making "`$" produce a literal dollar sign (which is what you probably want there).

Does Windows store files from a MOVE operation somewhere in a hidden/temp folder,

It doesn't. However, it also does not delete the originals until the copy from source to destination is successful. If the script had really been moving the files to a nonexistent share, both the PowerShell "Move-Item" and the Cmd.exe "MOVE" would have stopped after failing to create the output file, without deleting anything.

The fact that the server is slowly running out of disk space also indicates that the script did successfully create files on the target directory, implying that the target directory actually exists. (Windows doesn't invent share names out of nowhere, so this would not have happened if the script had incorrectly used "xxx`$" as the share name as you're assuming.)

Make sure that the UNC path actually represents the server-side folder that you're expecting (i.e. it's probably just that you're looking in folder A but the share is mapped to folder B). If you know the file names, search all of the server's disks for that exact name (e.g. Cmd's dir/a/b/s c:\foo.log). If the disk is filling up, run SpaceSniffer or WinDirStat and look at what the largest directory is – that's where your logs are.