Thanx for the insightful thoughts Ken See more below
> >>> all the std::filesystem implementations I've seen for Windows > >> > >> The implementation on top of Cygwin is not "for Windows", it's "for > >> Cygwin", i.e., "for Posix". And for Cygwin that's the right thing to > do. > >> And that's where we keep talking at cross purposes. > > > > > > Maybe it is the right thing to do, but what is your take of why it must > be so (all the way) ? > > > > I also do understand that it have several advantages in the > > implementation of std::filesystem but it also imply an extra layer of > > abstraction to the underlaying platform, but to just remove the > > _CYGWIN_ macro when building it would make std::filesystem to not > > understand /cygdrive at all (and I guess that would confuse other > > users;-) so I guess it would require some more sophisticated > > implementation (or extend the number of exceptions already existing in > > the underlaying Cygwin-Posix-implementation) > > I'd like to try to make this discussion more concrete by looking at what's > actually going on in the test program main.cpp that you posted at the > beginning of that thread. (I ran it under strace and gdb to see this for > myself.) > > First, your program calls std::filesystem::exists, which ultimately calls > stat(2) in the Cygwin DLL. The work for this is done in the > path_conv::check function and various functions that it calls. These > functions have code that recognizes Win32 paths like C:\Temp, and > std::filesystem::exists therefore reports "true". This is consistent with > the statement at > https://cygwin.com/cygwin-ug-net/using.html#pathnames-win32 about how the > Cygwin DLL treats Win32 paths. > > Next, your program calls std::filesystem::canonical. This calls > std::filesystem::absolute, which reports that C:\Temp is not an absolute > path. > It therefore tries to treat it as a relative path and fails with "No such > file or directory" because <current directory>/C:\Temp does not exist. > Note that the Cygwin DLL never sees the original path C:\Temp in this > case. Again, this is consistent with the statement in the documentation > that Cygwin applications do not necessarily recognize Win32 paths. > > You say this is a bug, because first you're told that C:\Temp exists and > then you're told it doesn't. But I think it just illustrates the hazards > of using > Win32 paths in Cygwin, which tries hard to emulate Posix. Sometimes you > can get away with using Win32 paths and sometimes you can't, depending on > how and when the Cygwin DLL is involved. Well, to call it a bug in this context was maybe wrong, but in a ISO-standard perspective it would be considered a bug ;-) > I don't see a good way to avoid this inconsistency. We could change > Cygwin so that it rigidly recognizes only Posix paths. Cygwin would then > be consistent, but we would be removing a feature that many users have > become accustomed to I guess so too, but they are already there for some reason I don't expect that the posix-functions should accept any non-posix-paths but it would be nice to have the platform independent std::filesystem to work transparently but I guess, since the cygstdc++-library uses the underlaying posix-functions the only reasonable way to accomplish this is to extend the list of features that already exists The sole reason for std::filesystem was to avoid platform dependent code So I guess in practical, it is up to the community of how well motivated they are to extend those Posix-functions but my take in this thread is that many rather would like it to become more ... like an emulator > And it wouldn't help you. Or we could ask all Cygwin package maintainers > to try to patch their packages so that they recognize Win32 paths, but > that's simply not feasible, nor would many package maintainers be willing > to invest the required time. I'm not sure what package maintainers you're referring to here now ? Applications ? Cygwin ? GCC ? > I tried it once with emacs, which I maintain, in response to a user > request. I failed miserably. Every change I made broke something else, > and I finally gave up. > > I don't think g++ will be any easier than emacs, and I don't think you can > expect the g++ maintainer to work on this. Yeah, I noticed that the _CYGWIN_ macro actually was a part of the real libstdc++-distro Thanx Ken and keep up the good work Kristian > Ken -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
