SHFileOperation works but prints error messages

Question

I'm using Shell API to copy a folder with files.

SHFILEOPSTRUCT sf = {0};
sf.wFunc = FO_COPY;
sf.hwnd = 0;
sf.fFlags = FOF_NOCONFIRMATION | FOF_NOCONFIRMMKDIR | FOF_NOERRORUI | FOF_SILENT | FOF_NO_UI;
sf.pFrom = "C:\\Users\\Sergi0\\AppData\\Local\\Temp\\untar.temp\\000\0";
sf.pTo = "F:\\\0";

// both pFrom and pTo are double NULL terminated, I have rechecked it

int err = SHFileOperation(&sf);

Everything works fine, folder is copied to the drive F: The problem is that messages

internal\sdk\inc\wil\filesystem.h(820)\windows.storage.dll!7684045C: (caller: 7676413A) ReturnHr(2) tid(660) 80070057 Incorrect parameter.
...
internal\sdk\inc\wil\filesystem.h(820)\windows.storage.dll!7684045C: (caller: 7676413A) ReturnHr(101) tid(660) 80070057 Incorrect parameter.

are printed in Visual Studio debug console. There are 100 files inside folder 000 and 100 messages were printed.

Should I be worried about these? I'm using VS 2017 on Windows 10.

UPDATE I have tried with another device, I see the same errors in both VS2017 and VS2008. But, there are no such errors with generic flash drive. So it seems it has something to do with mass storage implementation on the devices I use. I didn't find file filesystem.h anywhere in SDK.

You aren't double null terminating your strings. They are only single null-terminated. — David Heffernan, Feb 05 '18 at 17:21
side note: in C++ `{0}` only zeros the first field, if you intend to do the whole structure you should just use `{}` which will zero the entire structure. — Mgetz, Feb 05 '18 at 17:48
I've seen that exception pop up elsewhere when a drive attached to the system was faulty. No idea if that applies here but can you try a different source/destination? — Basic, Feb 05 '18 at 17:48
With the edit to the question you are double null terminating. But I now wonder what your code really is. — David Heffernan, Feb 05 '18 at 17:55
@Mgetz False. Aggregate initialization value-initializes all members for which initializers were not explicitly provided, which for primitive types is equivalent to zero-initialization. Bottom line is, `SHFILEOPSTRUCT sf = {0};` is perfectly fine and sets all members of the structure to zero or NULL as needed. — Igor Tandetnik, Feb 05 '18 at 18:10
@Mgetz Just wanted to write the same as Igor. Here is the [relevant part of the reference](http://en.cppreference.com/w/cpp/language/aggregate_initialization): _"If the number of initializer clauses is less than the number of members or initializer list is completely empty, the remaining members are value-initialized."_ [Value-initialization](http://en.cppreference.com/w/cpp/language/value_initialization) in this case means set-to-zero. — zett42, Feb 05 '18 at 18:14
if you attach debugger to explorer - you can view many such debug output messages. this is win 10 "feature" — RbMm, Feb 05 '18 at 18:23
@IgorTandetnik I highly suggest you look at the output assembly from MSVC. You'll facepalm pretty hard. — Mgetz, Feb 05 '18 at 18:29
@Mgetz - i look assembly of `SHFILEOPSTRUCT sf = {0};` - it zeroinit all `sf` — RbMm, Feb 05 '18 at 18:37
@Mgetz [Looks perfectly OK](https://godbolt.org/g/Fj4yJC) from where I sit. — Igor Tandetnik, Feb 05 '18 at 18:41
@IgorTandetnik [mine looks better because it's not doing two independent stores](https://godbolt.org/g/T2vMFx) — Mgetz, Feb 05 '18 at 18:43
@Mgetz That may be. Nevertheless, your claim that `SHFILEOPSTRUCT sf = {0};` only zero-initializes the first members and leaves the rest uninitialized is false. — Igor Tandetnik, Feb 05 '18 at 18:45
@Mgetz - `/O3` option have not sense for CL - use `/O2` or `/Ox` for full optimization. anyway result with `S s = {};` and `S s = {0};` both corect — RbMm, Feb 05 '18 at 18:49
Do you get the same messages when running the code on a clean install of Windows? You can use [DebugView](https://learn.microsoft.com/en-us/sysinternals/downloads/debugview) to see those messages, so you don't have to install Visual Studio. It would also be helpful if you mentioned, what types of volumes C: and F: are (local drives, removable drives, network drives). — IInspectable, Feb 05 '18 at 23:35
@Basic I'll try another devices, but the error messages are about call parameters validation, so I don't suspect the device. — Sergi0, Feb 06 '18 at 14:11
@IInspectable Nope, I can't get a clean install at the moment. C: is a local windows drive, F is removable. I'll try a couple of difference devices. — Sergi0, Feb 06 '18 at 14:12
@Basic it may have bee the device after all (I have update the original post). It isn't faulty, but something is definitely not right. — Sergi0, Feb 06 '18 at 16:17

score 8 · Accepted Answer · answered Feb 06 '18 at 17:31

8

You don't need to worry about these messages. The copy engine is trying to get information about the destination directory (F:\) but it turns out that it's not a directory; it's a drive. The error is returned ("Silly copy engine, that's not a directory."), the copy engine says "Sorry," and everything proceeds normally.

Sorry for creating unnecessary alarm.

answered Feb 06 '18 at 17:31

Raymond Chen

44,448
11
96
135

Note, Raymond or I will file a bug on this and try to get it fixed. thanks for the report. – Chris Guzak Feb 06 '18 at 17:50
Raymond Chen apologized to me and he made it all better – Sergi0 Feb 06 '18 at 23:28
@ChrisGuzak Thanks. Please let me know if that turns out as a possible problem on the device side after all. – Sergi0 Feb 06 '18 at 23:31
1

@Sergi0 Nope, it's completely on us. I dug in a little deeper. We are trying to get some information from a non-NTFS volume (your flash drive is probably FAT32), and the call fails, and due to overzealous error reporting, we print a message even though the failure is benign. – Raymond Chen Feb 07 '18 at 01:38
@RaymondChen oh, now I see the difference with the USB stick. device is FAT16, and USB stick is NTFS. – Sergi0 Feb 07 '18 at 14:53

score 2 · Answer 2 · answered Feb 05 '18 at 21:03

2

Should I be worried about these?

If the files are being copied correctly, and SHFileOperation() is not reporting an error back to your code, then no, do not worry about it. The debug messages are internal to the API and the "incorrect parameter" errors are being handled internally by the API.

On the other hand, SHFILEOPSTRUCT does have an fAnyOperationsAborted field that will be set to TRUE if any of the individual files fails to copy. SHFileOperation() itself may be successful overall, but individual files may have failed, so your code should check for that condition.

answered Feb 05 '18 at 21:03

Remy Lebeau

555,201
31
458
770

everything OK, the removable drive is OK, i have no problems while deleting or copying files there from explorer or total commander. fAnyOperationsAborted is always zero. I'm worried because this is the first version of app built on VS2017. I have used VS2008 before and never saw any of those. – Sergi0 Feb 06 '18 at 14:09
All files are copied, the number of messages corresponds to the number of files. – Sergi0 Feb 06 '18 at 14:10
@Sergi0 like I said, don't worry about it (you can't do anything about it anyway). If you don't like seeing the debug messages, file a bug report with Microsoft. – Remy Lebeau Feb 06 '18 at 15:10
I have updated the question, I'm more worried now :) – Sergi0 Feb 06 '18 at 16:16
@Sergi0 my guess is the API issues a command that the device doesn't like/support, so the API either skips the command or tries something else. Again, no big deal, it is just of the implementation and is handled internally. – Remy Lebeau Feb 06 '18 at 18:59

SHFileOperation works but prints error messages

2 Answers2