1

I need to enumerate the contents of an MTP android device and transfer files from the device to a Windows PC.

Following the guide found here Transferring Content from a Device to a PC I attempted to transfer a simple text document to a specified directory. However, the output file is always empty, even when the returned value states that X number of bytes have been written.

I created an SSCCE using only the recommended Windows API calls to easily reproduce the issue. I used the API documentation and the official sample project for reference.

main.cpp

Qt project file

To test, I have an android phone connected via MTP with a folder on the root called testFolder and inside there is a file testfile.txt with the text hello world. Upon running this application, the output states that 11 bytes have been written however the file is empty. Please try it yourself?

I can't seem to understand why the file is always empty. Any ideas?

Thanks for your time.

mrg95
  • 2,371
  • 11
  • 46
  • 89
  • Not much to do with Qt but with Win32 API. It is hard to realize what went wrong with your code but you can try to get the last error and description: https://msdn.microsoft.com/en-us/library/windows/desktop/ms680582(v=vs.85).aspx – Alexander V Feb 28 '17 at 00:20
  • @AlexanderVX Thanks! Just implemented that and there was no error. Also calling `GetLastError()` returned 0. The big thing that has me stumped is that the file was created and `StreamCopy` reports that 8 bytes were written. Here is my exact implementation of this taken straight from the sample https://github.com/pauldotknopf/WindowsSDK7-Samples/blob/master/multimedia/wpd/wpdapisample/cpp/ContentTransfer.cpp#L80 – mrg95 Feb 28 '17 at 01:16
  • Maybe that outputPath.toStdWString().c_str() makes wide character string of wchar_t yet the stream expects char? And then zero of one byte of the wide character comes and that is translated to end of string? – Alexander V Feb 28 '17 at 01:43
  • @AlexanderVX Nope. Just tried using the setup from the sample (`strOriginalFileName`) instead of the QString method I was using. The file was created at the working directory, and was still empty. Hmmm. I'm gonna create a SSCCE real quick. – mrg95 Feb 28 '17 at 01:58
  • @AlexanderVX See my edit. I narrowed the issue down into 1 small main.cpp. – mrg95 Feb 28 '17 at 02:54
  • What value is there in `cbBytesRead` before the write? Now I see that that is your own (or somebody's) function and not from Windows itself. I cannot tell if that was because of type of data anymore. – Alexander V Feb 28 '17 at 04:15
  • @AlexanderVX No that was just a reupload of the sample. Here it is direct from Microsoft https://code.msdn.microsoft.com/windowsdesktop/Portable-Devices-COM-API-fd4a5f7d/view/SourceCode#content. Try out my SSCCE. It states that the read and write is 11 bytes, which would be the correct amount, except the file is always empty. – mrg95 Feb 28 '17 at 15:21
  • mc360pro, you have a case when it is not really remotely debuggable through SO. Here you more to expect an advise on how to implement something when the better API can be applied etc. I vaguely recall there is another forum of kind of SO for that. – Alexander V Mar 01 '17 at 16:23
  • @AlexanderVX No, it's definitely a programming question or there is some piece of knowledge I'm missing that would be easily missed by others considering everything I'm doing is straight from the API and Microsoft. The SSCCE should make that real easy to pinpoint for those with a more complete knowledge of the WPD API. – mrg95 Mar 01 '17 at 23:05

1 Answers1

2
  hr = SHCreateStreamOnFile(strOriginalFileName, STGM_CREATE|STGM_WRITE, &finalFileStream);

It usually helps to recognize common coding patterns. Whenever you create a file then you must always close the file. In the C language you have fopen(), you have to call fclose(). In the winapi you have CreateFile(), you have to call CloseHandle(). Even in runtime environments where a lot of the resource management is automagic, like .NET, when you create a FileStream then you have to call Close() or use the using statement.

The code does nothing to explicitly close finalFileStream.

That has consequences, you found one. Short of a memory leak, the implementation of SHCreateStreamOnFile does not know when to flush any buffered but not yet written data to the file. So you end up with a file with no content.

The contract for any interface pointer like IStream is that you always have to explicitly call its Release() function. Note that the code forgets to do this consistently for all the interface pointers it uses. Not the only problem, when you call CoInitialize/Ex() then you have to call CoUninitialize(). Just use the Golden Rule, you always have to cleanup explicitly in code like this.

Fix:

  hr = StreamCopy(finalFileStream, ...);
  if (FAILED(hr)) saysomething(hr);          // Forgotten in original code
  finalFileStream->Release();                // Now it is good.

You can use a smart-pointer type in C++ like CComPtr<> to get it done automagically.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Ah! Makes sense now. I see now that the API says to use CComPtr<>, I'm developing for Windows 7 and that is not an option. I'll give it a shot and then accept the answer. Thanks so much! – mrg95 Mar 02 '17 at 00:31