On Wed, Sep 01, 2004 at 04:40:43PM +0200, Arnaud Mouiche wrote: >well. c: is binary > >here a bug. >cygpath -M c:/foo returns > >>> cygpath: file 'c:/foo' - No error > >looking at CVS code and strace, flags are set to zero instead of 0xa; the >file is nor binary nor text
"0xa"? Why would the code use an absolute hex value?
sorry
0xa is the flags return by strace when checking a binary mounted file like. of course, strace dosn't know the #define or enum strings
for example,
run: strace cygpath -M /usr/X11R6/lib/X11/fonts/util/map-KOI8-R (which is mounted a binary)
[....]
282 712265 [main] cygpath 404 mount_info::conv_to_win32_path: src_path /usr/X11R6/lib/X11/fonts/util/map-KOI8-R, dst C:\cygwin\usr\X11R6\lib\X11\fonts\util\map-KOI8-R, flags >>>>> 0xA <<<<<<, rc 0
[....]
in fact 0xA = PATH_BINARY + (something else) , where PATH_BINARY =0x2
we have following calls
cygpath -> cygwin_internal(CW_GET_BINMODE) -> path_conv::check which set path_flags to 0xA for binary, and then returns O_BINARY or O_TEXT to cygpath, depending of the mode.
for c:/foo, path_conv::check set path_flags to zero and cygwin_internal(CW_GET_BINMODE) returns zero instead of O_BINARY or O_TEXT
arnaud
PTC, but not a P that uses an absolute hex value.
cgf
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
