[PATCH] setup.exe: mkdir.cc. was: setup.exe crash

Here is a solution for this problem. Please, review. To reproduce the crash write manually a path with non-existent drive in the local package directory edit control. The reason for this crash is that mkdir_p tries to create the path recursevly and does not care if its actually a path component

Re[2]: [PATCH] setup.exe: mkdir.cc. was: setup.exe crash

new return value is a problem for any of the mkdir_p () callers. Here is the ChangeLog entry: 2002-03-26 Pavel Tsekov <[EMAIL PROTECTED]> * mkdir.cc (mkdir_p): Stop processing if the path is exhausted. Return -1 on 'path exhausted' condition.

Re[4]: [PATCH] setup.exe: mkdir.cc. was: setup.exe crash

>> Btw. I haven't checked if the new return value is a problem >> for any of the mkdir_p () callers. RC> Oh, it may well be, so I was going to checkin a variant anyway: RC> 1 is failure :}. Uh, yes... Thanks! I was sure I'm missing something :)

Re[2]: Cygwin 1.3.10 Setup.exe 2.194.2.22 Install Problems With MSVCRT.DLL and source code on Win98

Hello, there! :) Wednesday, April 10, 2002, 10:11:46 AM, you wrote: Ok, found it - its canonicalize_version() in version.cc. There is a pointer 'v' which is modified and then delete[]'d. A trivial patch is attached :) 2002-04-10 Pavel Tsekov <[EMAIL PROTECTED]>

[PATCH] setutp.exe issue was Re[3]: Cygwin 1.3.10 Setup.exe 2.194.2.22 Install Problems With MSVCRT.DLL and source code on Win98

No comments on this at all ? PT> Ok, found it - its canonicalize_version() in version.cc. There is PT> a pointer 'v' which is modified and then delete[]'d. PT> A trivial patch is attached :) PT> 2002-04-10 Pavel Tsekov <[EMAIL PROTECTED]> PT>

Re: [PATCH] setutp.exe issue was Re[3]: Cygwin 1.3.10 Setup.exe 2.194.2.22 Install Problems With MSVCRT.DLL and source code on Win98

Please, ignore this - I was too speedy to type :( Just saw that a new version was released Friday, April 12, 2002, 10:02:37 AM, you wrote: PT> No comments on this at all ?

[PATCH] path_conv::check - Do not check if a directory is executable

Hello, While I was browsing the fhandler_registry code and the *stat() stuff it occured to me that this patch may be useful. I don't know how it improves the speed of the path_conv::check (I don't think it is a noticable improvement), but for sure it saves some cpu cycles. 2002-06

[PATCH] _unlink() & rmdir() on /proc/*

Hello, Currently "rm -rf" on a file or directory under /proc returns ENOENT. This is not correct and is caused by the fact that the posix filename for, say, /proc/uptime is translated to the following win32 name: c:\cygwin\proc\uptime (if c:\cygwin is mounted on /). The attached patches fix this

Re: [PATCH] _unlink() & rmdir() on /proc/*

The attached dir.cc.diff in the original mail was wrong. Please, find attached the proper fix for dir.cc. Sorry for the inconvenience :( PT> The attached patches fix this problem by returning EROFS dir.cc.diff Description: Binary data

Re[2]: [PATCH] _unlink() & rmdir() on /proc/*

They are very small: syscalls.cc.diff and dir.cc.diff have 8 lines added. path.cc.diff has line one changed. Does this require an assignment ? CF> I haven't actually read your patch since, AFAIK, you don't have an CF> assignment with Red Hat, right? If this is the case, would you mind CF> send

Re[2]: [PATCH] _unlink() & rmdir() on /proc/*

Hello Christopher, Tuesday, June 04, 2002, 5:35:35 PM, you wrote: CF> I haven't actually read your patch since, AFAIK, you don't have an CF> assignment with Red Hat, right? If this is the case, would you mind CF> sending one in? Yes, I don't have an assignment. Today I've started the process t

Re: [PATCH] path_conv::check - Do not check if a directory is executable

I see that this patch is no longer required. The snapshot from July 4th includes a similiar change. PT> 2002-06-04 Pavel Tsekov <[EMAIL PROTECTED]> PT> * path.cc (path_conv::check): Do not check a directory PT> path against a known list of executable file extensions.

Re[2]: [OT] Copyright assignment form question

CF> Btw, make sure that your employer signs their part, too. It's been aranged :) I wouldn't even think of asking if it wasn't. I'm just waiting for the disclaimer to be printed on a paper with the company sign on it :)

Re: [PATCH] performance patch for /proc/registry -- version 2

On Wed, 26 Mar 2003, Corinna Vinschen wrote: > However... am I doing something wrong? I'm trying to find out what the > performance improvement is on my XP box and both versions of the DLL > (w/ and w/o your patch) are running 7.5 minutes for > > ls -lR /proc/registry > /dev/null > > Or is t

[PATCH] Fix format strings for *_printf in mmap.c

Hello, Does the following patch make any sense ? * 2003-07-21 Pavel Tsekov <[EMAIL PROTECTED]> * mmap.cc: Use proper format specifiers for _off64_t and size_t in format strings passed to syscall_printf () and debug_printf () throughout. -- +++ GMX - Mail, Mes

[PATCH] Add support for ioctl TIOCLINUX, function 6 (get key modifiers) on a TTY

ative just in case. The attached patch is pretty much non-intrusive, while the one employing cygwin_internal () adds a new member to the tty_min structure thus changing the shared memory footprint and I consider it too intrusive. Please, review and share your thoughts :) 2003-08-01 Pavel Tseko

[PATCH] patch.cc: cygdrive_getmntent () - Unify behaviour with fhandler_cygdrive

Hello, Here is a simple patch which makes the behaviour of getmntent () consistent with the one of fhandler_cygdrive. Pavel 2003-08-02 Pavel Tsekov <[EMAIL PROTECTED]> path.cc (cygdrive_getmntent): Do not skip over drives of type DRIVE_REMOVABLE. -- COMPUTERBILD

Re: [PATCH] patch.cc: cygdrive_getmntent () - Unify behaviour with fhandler_cygdrive

> On Sat, Aug 02, 2003 at 01:53:21PM +0200, Pavel Tsekov wrote: > >Here is a simple patch which makes the behaviour of getmntent () > >consistent with the one of fhandler_cygdrive. > > The reason this is there is to avoid long delays in mount table > listings. Well, I gue

Re: [PATCH] patch.cc: cygdrive_getmntent () - Unify behaviour with fhandler_cygdrive

> After giving this a couple days of thought, I decided that this was > not hobgoblin related so I'm going to check this in. Thanks! Of course, if people start complaining, it could easily reverted. Pavel -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test

Re: [PATCH] Add support for ioctl TIOCLINUX, function 6 (get key modifiers) on a TTY

Hello, Should the silence indicate a lack of interest ? Pavel -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualitätssieger! 3. Arcor - 4. web.de - 5. T-Online

[PATCH] readdir (): Do not set 'errno' if end of dir is encountered

Hello, Attached is a patch + a testcase. The testcase can be executed with any of the following directories: /cygdrive /proc /proc/ /proc/registry/HKEY_WHATEVER 2003-08-05 Pavel Tsekov <[EMAIL PROTECTED]> * fhandler_disk_file.cc (fhandler_cygdrive::readdir): Do not

[PATCH]: Use the user supplied cygdrive prefix

-03-06 Pavel Tsekov <[EMAIL PROTECTED]> * path.cc (mount_info::read_cygdrive_info_from_registry): Use the user prefix if it exists. Index: path.cc === RCS file: /cvs/src/src/winsup/cygwin/path.cc,v retrieving revisio

[PATCH]: autoload.cc: Remove unnecessary data entries from .dllname_info sections

Hello, I've been looking at the contents of the cygwin1.dll image in the last few days and I've noticed that the sections named .dllname_info contain a lot of duplicate entries - one for each autoloaded function from a given dll. Although it doesn't hurt to have it, this information is not really

Re: [PATCH]: autoload.cc: Remove unnecessary data entries from .dllname_info sections

On Thu, 10 Mar 2005, Christopher Faylor wrote: > Thanks for the patch but I'd prefer keeping the current functionality which > makes the use of LoadDllprime optional. I didn't know better :( > I've checked in a fix for this so that only one .*_info block is loaded > for any given DLL. Very nic

[PATCH] Fix for sending SIGHUP when the pty master side is close()-ed

Hello, Today, I've finally tracked down the cause of the problem with the stale subshells on MC exit. In the past I've tried to attack the problem in a different manner and wasn't looking at the right place - I suspected some kind of problem / race in the signal handling / delivery, but I was wron

Re: [PATCH] Fix for sending SIGHUP when the pty master side is close()-ed

On Wed, 17 Aug 2005, Christopher Faylor wrote: > On Wed, Aug 17, 2005 at 06:30:25PM +0300, Pavel Tsekov wrote: > >The attached patch solves this problem by rearranging the code a bit. It > >tries to be non-intrusive. I offer it for discussion and comments. I hope > >that