Custom Query (245 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (43 - 45 of 245)

Ticket Resolution Summary Owner Reporter
#246 wontfix Outdated Information about file handles bird dmik
Description

If the process connects its stdin/out/err handles to pipes using DosDupHandle?() and then starts a child with spawn*() (perhaps, fork too?), isatty() called in the child one will return 1 for stdin/out/err while they are actually pipes, not character devices any longer.

In fact, calling isatty() in the parent process after DosDupHandle?() will continue to return 1 too.

My guess is that once LIBC has cached imported file handle information, it is never refreshed. I see these options:

  1. Don't cache information for imported file handles but instead always fetch it from the system. The question is the performance impact.
  1. Provide a custom libc extension (available to end user programs) that resets the cache of imported file handles. This extension is to be called by the end user program when it manipulates file handles bypassing LIBC (as in case of DosDupHandle?()) as well as by spawn*() and fork().
  1. A combination of 1 and 2. I.e. reset the cache for the particular handle in public calls like isatty() but still use the cached information internally (i.e. through libc_FH, etc.). This should not have a big performance impact and still free the programmer from caring about this cache at all (which is a good thing).
#360 fixed Path rewriter affected paths cause crashes in forked child dmik
Description

Involving paths registered in the kLIBC path rewriter causes a crash when doing mkstemp in the forked child (the test case attached). If I use open instead of mkstemp, then the program doesn't crash but instead creates a file in a wrong location.

In the test case I use paths starting with /tmp which is mapped to %TMP% (which is set to D:\Temp). In case of open the file is created in D:\ instead of D:\Temp. I also experience similar troubles with other rewriter paths.

Note that if execute the same mkstemp or open from the parent process, all works as it should.

#132 fixed Please add a high-mem safe wrapper for DosQueryAppType() bird guest
Description

DosQueryAppType?() is not listed in the high-mem supporting APIs and indeed it acts weird (returncode=87 and appType=0 whatever the real appType is) when being passed a char* as first argument that is located above 512MB. So it would be great, if it a SafeDosQueryAppType?() wrapper could be written and then add it to os2safe.h.

Note: See TracQuery for help on using queries.