On Thu, Jul 28, 2011 at 2:53 PM, cc caprani wrote:

On Mon, Jul 25, 2011 at 5:41 PM, Bill Moo wrote:

...

for (int o = 0; o < 48; o++) { os << "Write my data here....." ; for (int i = 0; i < 51; i++) { os << i ; // But if I output this simple line and I get a 1 byte file and NO errors or exceptions! } }

i isn't incremented. What is o supposed to do?

Well spotted Colin thank you for taking the time to reply, but in my real code i was incremented. I supplied this pseudo code to demonstrate how I was using the library just in case my usage was incorrect. Of course in the real code if i wasn't incremented then I would never exit the loop so I would not get my file, regardless of its size. I simply can understand why this doesn't work. I am using 64 bit builds of Qt v4.7.2, boost v1.46.1 and using the the Intel compiler v12.0.1029.2010 on Windows 7 SP1 x64 Any help on this would really be appreciated. -- Bill

On Fri, Jul 29, 2011 at 8:42 AM, wrote:

Well spotted Colin thank you for taking the time to reply, but in my real

...

code i was incremented. I supplied this pseudo code to demonstrate how I was using the library just in case my usage was incorrect.

Have you missed maybe an *other* important detail in your pseudocode? If you really want help, provide small working example demonstrating your problem. Try it with reference compiler (msvc/gcc) to make sure it is not a compiler issue.

I simply can understand why this doesn't work. I am using 64 bit builds of

...

Don't hurry

Hi, I appreciate the example was useless and of course missing the timed_lock request, so apologies for wasting your time. I have now provided a complete example as requested, as a Win32 console app built in x64. However, I am unable to test on any compiler other the Intel as I do not have the applicable libraries, but I suspect this may not be a compiler issue. I suspect the real problem lies between the seat and the keyboard. Not to sure what you meant by "Don't hurry" but I suspect there may be an odour or urine in the air. #include "stdafx.h" #include <iostream> #include <fstream> #include #include #include using namespace boost::interprocess ; using namespace boost::posix_time ; int _tmain(int argc, _TCHAR* argv[]) { std::string m_FileName("./locktest.txt") ; std::ofstream os ; os.open(m_FileName.c_str(), std::ios_base::out | std::ios_base::binary | std::ios_base::app) ; try { if (os.is_open()) { file_lock fileLock(m_FileName.c_str()) ; ptime pt(second_clock::local_time()) ; os.setf(std::ios::fixed, std::ios::floatfield) ; os.precision(3) ; if (fileLock.timed_lock(pt += seconds(5))) { try { // Do rows for (int o = 0; o < 48; o++) { os << "This is row " << o << " of 48" << " and this is just text" << "\n" ; // Do columns for (int i = 0; i < 51; i++) { os << i << "\t" ; } } fileLock.unlock() ; } catch (interprocess_exception& e) { std::cout << e.what() ; } catch (std::ofstream::failure e) { std::cout << e.what() ; } } else { std::cout << "No lock on file!" ; } os.close() ; } else { std::cout << "File not opened!" ; } } catch (std::exception& e) { std::cout << e.what() ; } std::cout << "Press a key to close." ; std::cin.get() ; return 0 ; } Thank you. -- Bill

2011/7/30 Ion Gaztañaga

El 30/07/2011 9:58, Bill Moo escribió:

...

On Fri, Jul 29, 2011 at 8:42 AM, >> wrote:

This is a Boost.Interprocess bug that I don't think it can be easily solved. Once you lock a file in Windows, you can only write to it through the handle (internal to fileLock) used to lock it. That's why the handle inside "os" is blocked. I should note this in the documentation as file locking can only be used portably in Interprocess to control access to ANOTHER file (or resource) but not to limit access to the same file you've just locked. From MSDN:

http://msdn.microsoft.com/en-**us/library/aa365203%28v=vs.85%**29.aspxhttp://msdn.microsoft.com/en-us/library/aa365203%28v=vs.85%29.aspx

"Locking a region of a file is used to acquire shared or exclusive access to the specified region using this file handle. If the file handle is inherited by a process created by the locking process, the child process is not granted access to the locked region. If the locking process opens the file a second time, it cannot access the specified region through this second handle until it unlocks the region."

Best,

Hi Ion, Ah! It wasn't me I'm glad to hear that, and thank you very much for the informative reply. I will just have to think of another approach to this. Thank you again for your time. -- Bill