doesn't get-childitem return null when there are no records?

The second loop is using the loop variable of the first loop. name should be victim. So when there is only one file (its self), it will do nothing, when there is more than one file it will only overwrite the last??

What Simeon said.

(What Simeon said) +

Even when there are multiple files,

copy-item $my_file $name.Name

doesnt do much since $my_file is the same as $name.Name.

"Even when there are multiple files,

copy-item $my_file $name.Name

doesnt do much since $my_file is the same as $name.Name."

Only when my_file is the last file visited by the top loop.

If you think of files a, b, c, d in the case of d been the 249 byte file then nothing would happen, but if c is the 249 file then d will be replaced four times. Even worse (not sure if it can happen) is if none of the files are the 249 file. Then $my_file is undefiend.

Not bad, you saw the bug (the code uses $name instead of $victim inside the second loop), but nobody has precisely stated the situations in which the code would not perform as expected.

Note that the script itself is 249 bytes...and the assumption is it already exists in the current directory (so it will be included in $name_array). The program does have a logical flaw that it assumes it is the one and only 249-byte file in the directory, but let's ignore that for now.

David, get-childitem does return $null when there are no files, but that's fine, the foreach loops will then do nothing (although per the previous paragraph the script assumes that itself, at least, is present in the directory).

- adam

Well, the first thing I noticed was the lines with the length checks of 249. No idea what this length check was for, but in my experience, just checking for eq or neq to some constant value is all too often wrong - what happens if, or should I say, when, it changes?

There's also no check that the length is not zero, which might be something to deal with before attempting tyhe copy ( a zero length file might be open thus causing an error in the script you're not catching).

The bugs your other commentators mention are also clear after studying the code for a bit.

"Not bad, you saw the bug, but nobody has precisely stated the situations in which the code would not perform as expected."

I was more of thinking … the only situation the code works correctly is when there is two files, the first returned by "get-childitem" been the virus, and the second been a target file.

As I see the bug, the code will not work correctly when there is more than two files present, because only the last of the target files will be replaced. Also when the last file returned by "get-chidlitem" is the virus, no files will be altered.

Is that enough information?

Simeon: Yes, I agree with your analysis. Nice work.