On 22 Dec 2025 19:29, Peter Dimov via Boost wrote:

Gennaro Prota wrote:

...

Hi,

I'm getting some errors from Filesystem in the Cygwin tests of DynamicBitset. I see that Filesystem is tested on Cygwin, so this is odd. Could a maintainer please have a look? Thanks.

<https://github.com/boostorg/dynamic_bitset/actions/runs/20430426737/job/58699726648>.

Probably caused by my merging https://github.com/boostorg/system/pull/137.

Historically, Boost.Filesystem has been using Boost.System's BOOST_POSIX_API and BOOST_WINDOWS_API macros for deciding between POSIX and Windows APIs. Unfortunately, this is not limited just to the underlying implementation of filesystem operations but is also reflected in the native character type used in filesystem::path. The change switched from Windows (wchar_t) to POSIX (char) style API, which is potentially a user-breaking change. Where users previously provided and received wide strings for paths, which were treated as native, now character code conversion will happen, which may or may not work well, depending on the installed locale. The fact that Cygwin is treated as Windows is also mentioned in the documentation. Restoring the previous behavior (by introducing and using Boost.Filesystem-specific set of macros) is easy enough, and I will fix this shortly. But here is the question: do we actually want to consistently treat Cygwin as a POSIX platform across Boost libraries? In regards to Boost.Filesystem, I'm not sure what Cygwin runtime does with paths, as it eventually has to interact with the underlying Windows API. Does it perform character code conversion? Is that conversion correct? Which encoding does it expect? My default opinion wrt. filesystem paths is that one should mess with them as little as possible. Character code conversion is generally a bad idea, unless it is unavoidable. In this regard, continuing to use Windows API on Cygwin is preferable. However, I can understand that it may be surprising to some users who expect native POSIX-style behavior on Cygwin, with any Cygwin-specific features. E.g., I think, Cygwin has its own implementation of symlinks that are incompatible with Windows. So I'm asking the community, what do you think should Boost.Filesystem do? Should it follow other Boost libraries and treat Cygwin as a POSIX system?

On 22 Dec 2025 22:53, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

But here is the question: do we actually want to consistently treat Cygwin as a POSIX platform across Boost libraries?

While the patch to System is a fairly disruptive change, and I did know that, I applied it without hesitation because this patch is also applied by the Cygwin project to their Boost packages.

So I figured that if they're going to do it anyway, we might as well, too.

I can't think of a reason for us to do something different on Cygwin.

Well, given that Boost.Filesystem doesn't compile with it, I'm guessing they also patch Boost.Filesystem? I haven't seen their patches.

El 22/12/2025 a las 20:44, Andrey Semashev via Boost escribió:

But here is the question: do we actually want to consistently treat Cygwin as a POSIX platform across Boost libraries? In regards to Boost.Filesystem, I'm not sure what Cygwin runtime does with paths, as it eventually has to interact with the underlying Windows API. Does it perform character code conversion? Is that conversion correct? Which encoding does it expect?

I think Cygwin is, by definition, a Unix environment at we should treat it like that. ------------------------------ https://cygwin.com/cygwin-ug-net/setup-locale.html "The default locale in the absence of the aforementioned locale environment variables is "C.UTF-8". "Windows uses the UTF-16 charset exclusively to store the names of any object used by the Operating System. This is especially important with filenames. Cygwin uses the setting of the locale environment variables LC_ALL, LC_CTYPE, and LANG, to determine how to convert Windows filenames from their UTF-16 representation to the singlebyte or multibyte character set used by Cygwin." "The setting of the locale environment variables at process startup is effective for Cygwin's internal conversions to and from the Windows UTF-16 object names for the entire lifetime of the current process. Changing the environment variables to another value changes the way filenames are converted in subsequently started child processes, but not within the same process." ------------------------------ So IMHO Filesystem should treat Cygwin as any other Unix system. However, I understand that this breaks previous users. One option would be to offer a backwards compatibility macro switch to go back to the Windows API for those users that want to maintain backwards compatibility. That would require, however, more complicated maintenance (say, testing cygwin both as UNIX and Win32 platforms). Best, Ion

Ion Gaztañaga wrote:

So IMHO Filesystem should treat Cygwin as any other Unix system. However, I understand that this breaks previous users.

I'm not sure that any such previous users actually exist (except for our test suites.)

On 23 Dec 2025 04:12, Peter Dimov via Boost wrote:

Andrey Semashev wrote:

...

Restoring the previous behavior (by introducing and using Boost.Filesystem- specific set of macros) is easy enough, and I will fix this shortly.

I'm not sure it's that easy. If the API selection between System and Filesystem is not consistent, system_category() will be POSIX but you'll be putting GetLastError codes into it.

Yeah, I thought so too.

If you insist on using the Windows API on Cygwin, we'll need to revert the System patch as well.

(Or you could implement your own error_category, I suppose.)

At the moment I just committed the old behavior in develop so that Boost.Filesystem at least compiles and doesn't block others. But recent Cygwin updates seem to have broken something in their WinAPI support as the tests in GHA are failing. Unfortunately, GHA logs also don't show console output of the failed tests. On my local machine, I had an older Cygwin installation, and there the tests passed. After updating Cygwin, they started failing as well. I didn't have time to debug, but I think, current_path() doesn't work for some reason. I think I'm going to try switching to POSIX API. The tests on POSIX are also failing, but for other reasons.