Steven Watanabe wrote:

AMDG

...

...

It looks like stat is setting errno to ENOENT. Do you get the same behavior if the file exists before starting the program?

Yes, the behavior is the same whether the program writes

Clarke, Carus V wrote: the file or if the file had been previously written.

...

Okay. Try using stat directly, instead of using Boost.Filesystem. If that works, then can you use a debugger to find exactly what arguments Boost.Filesystem is passing to stat?

In Christ, Steven Watanabe

Actually, the Boost.Filesystem library for Boost 1.44 uses the Windows API GetFileAttributes functions for reading file status on Cygwin, and it was in calls to these functions that things were failing. Since my last post, the Cygwin developers have updated the base Cygwin system (to 1.7.7-1). Updating my Cygwin installation to the new version has fixed the problem. Apparently, the 1.7.6-1 version had some bugs that were inadvertently introduced in an attempt to improve Cygwin functionality. I do have a question that might be better asked in a new thread, but here it is. Why does the Boost.Filesystem library force the use of Windows-style paths for Cygwin? The Cygwin system prefers Posix or mixed paths with forward slashes as separators. The use of Win32 paths on Cygwin is now deprecated, and Cygwin actually issues a warning the first time it encounters a Windows-style path. See http://cygwin.com/cygwin-ug-net/using.html#using-pathnames for more information. The Cygwin GCC 4.3.4 compiler no longer supports the -mno-cygwin option that was supported under Cygwin 1.5 and earlier. This means that any application created with this compiler depends on the Cygwin dll. Also, Boost does not appear to have a Cygwin platform for regression testing. Would it help if I or someone else could set one up? Thanks for your help. Carus V. (Bud) Clarke carus.v.clarke@boeing.com