I need to implement an application that streams data from disk. It is important that the data throughput is fairly constant and is not interupted by any other activity on the disk.
From Windows Vista onwards, the GetFileBandwidthReservation() and SetFileBandwidthReservation() functions have been introduced specifically for this purpose. However, I cannot get this to work. I've searched the internet but I cannot find much information on this (and no working code samples seem to exist online).
Code to reproduce:
HANDLE h = ::CreateFile(L"D:\\testfile", GENERIC_READ, 0, NULL, OPEN_EXISTING, FILE_FLAG_NO_BUFFERING | FILE_FLAG_SEQUENTIAL_SCAN, NULL);
DWORD periodMilliseconds, bytesPerPeriod, transferSize, numOutstandingRequests;
BOOL discardable;
BOOL result = ::GetFileBandwidthReservation(h, &periodMilliseconds, &bytesPerPeriod,
&discardable, &transferSize, &numOutstandingRequests);
if (result == FALSE) // result is always false!
{
DWORD reason = ::GetLastError(); // reason is always 1!
std::cout << "Error: " << reason << std::endl;
}
result = ::CloseHandle(h);
The call to GetFileBandwidthReservation always returns FALSE which indicates a failure. GetLastError returns 1 which isn't very helpfull. If a try to invoke *Set*FileBandwithReservation I get the same result.
I am testing this on a PC with Windows Server 2008 SP2 (32-bit).
Does anybody have any idea of what I am doing wrong? Any help will be greatly appreciated.
This requires support from the disk device driver. The kind of driver that you'd find in an upscale server, not a consumer level machine. Ask more questions about this at serverfault.com
Related
Based on what I can find on the internet this doesn't seem to be something a lot of people do but I'm pretty stuck so I'm going to put it out here. I'm using WMI in C++ to try to manipulate SQL Server settings. I have the following code that doesn't return a result from my WMI query and I'm at a loss as to why:
hr = pLoc->ConnectServer(CComBSTR(L"root\\Microsoft\\SqlServer\\ComputerManagement10"), // Object path of WMI namespace
NULL, // User name. NULL = current user
NULL, // User password. NULL = current
0, // Locale. NULL indicates current
NULL, // Security flags
0, // Authority (e.g. Kerberos)
0, // Context object
&pSvc);
// ----- Check for success and set proxy blanket here -----
IEnumWbemClassObject* pClassEnum = 0;
hr = pSvc->ExecQuery(_bstr_t("WQL"), _bstr_t("SELECT * FROM FilestreamSettings"),
WBEM_FLAG_FORWARD_ONLY | WBEM_FLAG_RETURN_IMMEDIATELY,
NULL,
&pClassEnum);
if (SUCCEEDED(hr) && pClassEnum)
{
ULONG uReturn = 0;
while (pClassEnum && !myInstanceFound)
{
hr = pClassEnum->Next(WBEM_INFINITE, 1, &pObjInstance, &uReturn);
if (0 == uReturn || !pObjInstance)
{
break;
}
// Get the value of the InstanceName property - the SQL Server instance name
CComVariant vtProp;
hr = pObjInstance->Get(L"InstanceName", 0, &vtProp, 0, 0);
if (SUCCEEDED(hr) && (VT_BSTR) == vtProp.vt)
{
if (vtProp.bstrVal == _bstr_t('MyInstance'))
{
myInstanceFound = true;
}
}
}
.
.
.
}
The ExecQuery command succeeds. The pClassEnum enumerator object is not null, so the while loop executes. The call to 'Next', however, does not return an object (pObjectInstance is null) and &uReturn is 0 (which, as I understand it means that the call to 'Next' returned 0 results). However, if I run the same query in the wbemtest tool, I get two results (which is correct, as I have 2 SQL Server instances on this machine). I have limited C++ skills and this is my first time with WMI. Not only do I not see what's wrong here, I'm not even sure what else to try. The few code samples I've seen suggest this code should be correct. Any help would be greatly appreciated!
Thanks,
Dennis
Update: The call to Next() actually returns S_FALSE. Which, if I'm reading the docs correctly, mostly just confirms the issue of not getting a result. Next() returns S_FALSE if there are less than the number of requested results (in my case, less than 1 - or in other words, 0).
Update #2: This same code does work on my laptop (well, the Next() call does anyway). Differences are: Does work on my laptop - Win 10, Sql Server 2019 (have to change namespace to be ComputerManagement15 instead of 10), FileStream already enabled. Does not work - Win 7 VM, Sql Server 2008, FileStream not enabled. A query using Wbemtest tool gets the correct data in both cases. Just thought I'd post in case this helps.
FYI, in case anyone stumbles across this: I didn't technically solve this, in that I never got my C++ code to work. I wrote some C# code using SQL Server Management Objects (basically a wrapper over WMI) and made it into a COM server that I could call from C++. Even this didn't work directly because my C# COM server kept getting an "Access Denied" even if I ran the C++ COM client application as Administrator. What eventually worked was to extract the SSMO code out into its own C# console app which I then ran from my C# COM server as its own process using the "run as" verb so it would run as Administrator. This finally managed to enable Filestream on my SQL Server instance. It's possible there was a better/easier way to get this done but I found something that worked (although it was pretty kludgy). So if there's a chance this helps anyone else, I'm putting it out there.
I'm using it like this:
if(QDir("G:/").isReadable()){
qDebug("G Is readable!"); //Do something with G:/
}
As I said, in Qt Creator it runs fine without a problem, it checks if the drive is readable, and if so it prints it to the console, if not, it does nothing.
But when I run the .exe file, it keeps giving me errors each time it does the check (every 2 seconds) if the drive isn't readable.
"There is no disk in the drive. Please insert a disk into drive G:."
I don't want this error to keep appearing, what do I do?
Edit: I think it's the isReadable function that causes the problem, is there any other way to do what I want to do? Or maybe should I write the code myself?
This message is generated by Windows.
There is a workaround for users that have applications that cannot be fixed. The error messages may be suppressed by setting 2 to registry key ErrorMode in:
Computer\HKEY_LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\Windows
It looks that if QDir::isReadable() is called after removing the media it triggers that error. QDir::exists() always returns true if the drive letter is present in the system, so it cannot be used here.
For now I see that it is possible to check removable media using native Windows API, see the answer to How to detect if media is inserted into a removable drive/card reader
The following code is able to detect that the media is removed without triggering the error:
#include <windows.h>
HANDLE hDevice = CreateFile (L"\\\\.\\G:", // like "\\.\G:"
FILE_READ_ATTRIBUTES, // read access to the attributes
FILE_SHARE_READ | FILE_SHARE_WRITE, // share mode
NULL, OPEN_EXISTING, 0, NULL);
if (hDevice == INVALID_HANDLE_VALUE) {
// not valid device
return;
}
WORD cbBytesReturned;
bool bSuccess = DeviceIoControl (hDevice, // device to be queried
IOCTL_STORAGE_CHECK_VERIFY2,
NULL, 0, // no input buffer
NULL, 0, // no output buffer
(LPDWORD)&cbBytesReturned, // # bytes returned
NULL); // synchronous I/O
CloseHandle(hDevice); // close handle
if (bSuccess && QDir("G:/").isReadable()) {
// G is readable
}
I've been trying to find information on a file by using CreateFile() and DeviceIoControl(). However I keep running into ERROR_HANDLE_EOF which from my understanding means that the starting virtual cluster number is past the end of the file even though I am starting at 0. Here is a few snippets of my code, let me know if you guys have any idea what's going wrong.
HANDLE hFile = INVALID_HANDLE_VALUE; //drive or file to be checked
LPWSTR txtFile = L"Text.txt"; //text file
hFile = CreateFile(txtFile, //target file
GENERIC_READ | GENERIC_WRITE, //read and write
FILE_SHARE_READ|FILE_SHARE_WRITE,//allows sharing of read and writes
NULL, //security prevents child process from inheriting the handle
OPEN_EXISTING, //open file or drive if it exist
FILE_ATTRIBUTE_NORMAL, //default settings for files
NULL); //template file with generiv read access rights
if (hFile == INVALID_HANDLE_VALUE) //error handling
{
cout<<"File does not exist"<<endl;
CloseHandle (hFile);
system("pause");
}
cout<<"you opened the file succesfully: "<<hFile<<endl;
STARTING_VCN_INPUT_BUFFER startVcn;
RETRIEVAL_POINTERS_BUFFER retrievalBuffer;
DWORD error =ERROR_MORE_DATA;
BOOL returns;
startVcn.StartingVcn.QuadPart = 0;
while( error ==ERROR_MORE_DATA){
DWORD bytesReturned;
returns = DeviceIoControl(hFile,
FSCTL_GET_RETRIEVAL_POINTERS,
&startVcn,
sizeof(STARTING_VCN_INPUT_BUFFER),
&retrievalBuffer,
sizeof(RETRIEVAL_POINTERS_BUFFER),
&bytesReturned,
NULL);
error = GetLastError();
switch(error){
case ERROR_HANDLE_EOF:
cout<<"ERROR_HANDLE_EOF"<<endl;
returns = true;
break;
case ERROR_MORE_DATA:
cout<<"ERROR_MORE_DATA"<<endl;
startVcn.StartingVcn = retrievalBuffer.Extents[0].NextVcn;
case NO_ERROR:
cout<<"NO_ERROR, here is some info: "<<endl
<<retrievalBuffer.StartingVcn.QuadPart<<endl
<<retrievalBuffer.Extents[0].Lcn.QuadPart<<endl
<<retrievalBuffer.Extents[0].NextVcn.QuadPart
- retrievalBuffer.StartingVcn.QuadPart<<endl;
returns = true;
break;
default:
cout<<"Error in the code or input error"<<endl;
break;
}
}
I wrote pretty much the same program myself and, like the OP, I found that I was getting ERROR_HANDLE_EOF which I couldn’t explain. When I went looking for an explanation, I never found one but stumbled across this post. The OP’s program looks correct to me so I strongly suspect the explanation for the behaviour is the same as mine. I realize it is way too late to help the OP but for the benefit of anyone else who spends 1 whole day working this out, I think the answer is…
Educated guess: ‘Small files’ don’t get a cluster assigned to them and when you query a ‘small file’ with the above program you will receive ERROR_HANDLE_EOF. This sort of makes sense, but is very unfriendly and useless to a newbie like myself. Experiments on the machine I have led me to believe that a ‘small file’ is 736 bytes or less. 737 bytes or more starts using clusters. I found these limits by performing a binary search on various file sizes using Linux/cygwin ‘dd’ command to generate files of the required size.
At this time, I have not found anyone supporting my claim about 736 vs 737 bytes, but http://www.ntfs.com/ntfs_optimization.htm does say “On NTFS if file is small enough, it can be stored in MFT record itself without using additional clusters.”
My systems are using Windows 10, NTFS simple volumes. I don’t understand NTFS, the MFT or attributes very well. Perhaps someday I will find the appropriate structure that explains why this number comes about (like structure can be up to 1K and already has 288 bytes in use??).
I am helping a friend to finish a final year project in which he has this circuit that we want to switch on and off using a C++ program.
I initially thought it would be easy, but I have failed to implement this program.
The main problem is that
Windows XP and above don't allow direct access to hardware so some websites are suggesting that I need to write a driver or find a driver.
I have also looked at some projects online but they seem to work for Windows XP but fail to work for Windows 7.
Also, most projects were written in VB or C# which I am not familiar with.
Question:
Is there a suitable driver that works for Windows XP and Windows 7, and if yes how can I use it in my code? (code snippets would be appreciated)
Is there a cross platform way of dealing communicating with parallel ports?
Have a look at codeproject: here, here and here. You'll find treasures.
The 1st link works for Windows 7 - both 32 bit and 64 bit.
You shouldn't need to write a driver or anything -- you just call CreateFile with a filename like "LPT1" to open up a handle to the parallel port, and then you can use WriteFile to write data to it. For example:
HANDLE parallelPort = CreateFile("LPT1", GENERIC_WRITE, 0, NULL, OPEN_EXISTING, 0, NULL);
if(parallelPort == INVALID_HANDLE_VALUE)
{
// handle error
}
...
// Write the string "foobar" (and its null terminator) to the parallel port.
// Error checking omitted for expository purposes.
const char *data = "foobar";
WriteFile(parallelPort, data, strlen(data)+1, NULL, NULL);
...
CloseHandle(parallelPort);
We had a line of code
if( !CreateFile( m_hFile, szFile, GENERIC_READ|GENERIC_WRITE, 0, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL ) )
{
DWORD dwErr = GetLastError();
CString czInfo;
czInfo.Format ("CMemoryMapFile::OpenAppend SetFilePointer call failed - GetLastError returned %d", dwErr);
LOG(czInfo);
return false;
}
This code worked great for many years. A few weeks ago, we had a customer with a problem. Turns out, the problem could be traced to this line of code, where the function would return a INVALID_HANDLE_VALUE handle and GetLastError() returned ERROR_FILE_NOT_FOUND(2).
Now, this is very confusing to us. OPEN_ALWAYS should direct the file to be created if it does not exist. So, why are we getting a ERROR_FILE_NOT_FOUND?
More confusion: For this customer, this only happened on one network share point (we were using a UNC path). Other UNC paths to other machines for this customer worked. Local paths worked. All our other customers (10000+ installs) have no problem at all.
The customer was using XP as the client OS, and the servers were running what appeared to be standard Windows Server 2003 (I think the Small Business Server version). We could not replicate their errors in our test lab using the same OS's. They could repeat the problem with several XP clients, but the problem was only on one server (other Server 2003 servers did not exhibit the problem).
We fixed the problem by nesting two CreateFile calls, the first with OPEN_EXISTING, and the second with CREATE_ALWAYS if OPEN_EXISTING failed. So, we have no immediate need for a fix.
My question: Does anyone have any idea why this API call would fail in this particular way? We are puzzled.
Addendum:
The CreateFile function above is a wrapper on the Windows API function. Here's the code:
bool CMemoryMapFile::CreateFile( HANDLE & hFile, LPCSTR szFile, DWORD dwDesiredAccess, DWORD dwShareMode, DWORD dwCreationDisposition, DWORD dwFlagsAndAttributes )
{
hFile = ::CreateFile (szFile, dwDesiredAccess, dwShareMode, NULL,
dwCreationDisposition, dwFlagsAndAttributes, NULL);
return (hFile != INVALID_HANDLE_VALUE)
}
First, you should always check for success of the CreateFile() API like this:
if (CreateFile(...) == INVALID_HANDLE_VALUE)
{
// handle the error
}
because CreateFile() doesn't return !=0 in case of success, but anything other than INVALID_HANDLE_VALUE (which is -1).
Then, the CreateFile() can fail in the situation you described if either the directory doesn't exist where you want to create/open the file in, or it can fail if the user has the rights to open and write files in that directory, but no rights to create new files.
Maybe the directory you wanted to create the file in did not exist?
Are you sure you fixed it by using 2 CreateFile calls? Or did you just not reproduce it?
We have also seen this problem when a file is accessed by a UNC share. None of the ideas and suggestions applied in our case - the directory always exists, the parameters to CreateFile are correct, we are checking the return correctly.
We believe this to be a shares issue. We solved the problem with a simple retry loop:
If a CreateFile with OPEN_ALWAYS fails with ERROR_FILE_NOT_FOUND, we simply sleep for a few ms and try again. It always works second time (if it failed first time).
If CreateFile fails, it will return INVALID_HANDLE_VALUE which is non-zero (I think it's negative 1). So CreateFile might be succeeding and returning zero as the handle.
It's only safe to check GetLastError() after a function fails but it looks like you might be checking the last error when CreateFile has succeeded (returned zero).
According to this article, some functions set the "last error" if they succeed:
My guesses would be something server related like the server not implementing support correctly for that filesystem operation. Maybe a linux server compared to a windows server?
Your arguments to create file are incorrect, so I assume that this is some sort of CreateFile helper function.
A call to CreateFile should look like:
m_hFile = CreateFile( szFile, GENERIC_READ|GENERIC_WRITE, 0, 0, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, 0 );
if(m_hFile == INVALID_HANDLE_VALUE)