From: Andres R. <lo...@ho...> - 2004-08-28 17:13:19
|
Hi! Since there has been no respone, I looked a little at fileutils source. I got some interesting findings in copy.c function: static int copy_reg = ( .... ) ---314--- for (;;) { int n_read =3D read (source_desc, buf, buf_size); ---316--- read returns wrong number of bytes (cr/lf -> lf conversion) on cp //server/share/file . condition. Otherwise it returns right number of = bytes. fstat (source_desc, &sb) shows right nunber of bytes all the time. May it be, msys runtime read is somehow affected, but not fileutils?? (If that's the case, I can start looking in other places..) Andres Rand ----------------------------------------- ITV - Sinu lemmiksaated internetis! http://www.itv.ee |
From: Andres R. <lo...@ho...> - 2004-08-30 21:18:47
|
Hello! Earnie: I ment no response with solution. A little progress report: As of today, I managed to build debug version of msys-1.0.dll Few comments on msysDVLPR.rtf: It might contain pointers that conventional MinGW32 is also needed (gcc, g++, mingw-runtime and win32api). I did a clean install without MinGW32 first, then later added relavent packages when .dll build needed mingw32-gcc. src/winsup/cygwin/tty.cc GetConsoleWindow error still present in cvs I managed to get around it *acking* /include/wincon.c with appropr prototype. Other than that, it was a breeze to compile. Now I got gobs of debug data to dig through :) At first clance, some interesting things came up and I think I managed to= isolate some code.. Continued when I get some time again. Andres P.S. Hope that my chatter does not interfier with rather quiet msys maili= ng list. ----------------------------------------- ITV - Sinu lemmiksaated internetis! http://www.itv.ee |
From: Earnie B. <ea...@us...> - 2004-08-31 10:04:28
|
Andres Rand wrote: >Hello! > >Earnie: >I ment no response with solution. > >A little progress report: >As of today, I managed to build debug version of msys-1.0.dll >Few comments on msysDVLPR.rtf: It might contain pointers that >conventional MinGW32 is also needed (gcc, g++, mingw-runtime and >win32api). I did a clean install without MinGW32 first, then later >added relavent packages when .dll build needed mingw32-gcc. >src/winsup/cygwin/tty.cc GetConsoleWindow error still present in cvs >I managed to get around it *acking* /include/wincon.c with appropr >prototype. >Other than that, it was a breeze to compile. > > Somewhere I posted a list of what needed to be included. Seems you're bright enough to figure out the process without help. >Now I got gobs of debug data to dig through :) >At first clance, some interesting things came up and I think I managed to isolate some code.. > > Feel free to ask for help, note though that the archives of this list contains a thread where I helped someone else with the debugging process. For this particular case you need to find where a file is opened that isn't in the mount table and add _O_BINARY to the mode. >Continued when I get some time again. > >Andres > >P.S. Hope that my chatter does not interfier with rather quiet msys mailing list. > > Interfier away, I'm happy to see someone wanting to debug and patch. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Andres R. <lo...@ho...> - 2004-08-31 11:31:25
|
Hi! > Somewhere I posted a list of what needed to be included. Seems you're > bright enough to figure out the process without help. I found that part in list but it was a no-go on my system for some unknown reason (other than making /build dir and there ../src/configure) > > >Now I got gobs of debug data to dig through :) > >At first clance, some interesting things came up and I think I managed to isolate some code.. > > > > > Feel free to ask for help, note though that the archives of this list > contains a thread where I helped someone else with the debugging > process. For this particular case you need to find where a file is > opened that isn't in the mount table and add _O_BINARY to the mode. That tip is more than welcome! Last thing I remember I was poking around in file_handler::open and I wanted to see, how things are opened. Actually I never imagined it (msys) is written in c++ (or objc, can't tell the difference..). Andres |
From: Andres R. <lo...@ho...> - 2004-09-01 21:40:58
Attachments:
path.cc.patch
|
Hi! I think I managed to come up with a patch. Look and say waht do you think.. Maybe some sanity checks are needed or something. At least this way the current cp //server/share/file . problem is gone for my system. Andres. ----------------------------------------- ITV - Sinu lemmiksaated internetis! http://www.itv.ee |
From: Earnie B. <ea...@us...> - 2004-09-02 10:10:56
|
Andres Rand wrote: >Hi! > >I think I managed to come up with a patch. >Look and say waht do you think.. >Maybe some sanity checks are needed or something. > >At least this way the current cp //server/share/file . >problem is gone for my system. > > Really all you need to do is return PC_FULL. PC_SYM_NOFOLLOW is meaningless as that is always the course of action for MSYS. Also, there is no reason to guard for ``#if defined __MSYS__'' as the code will not be incorporated back to the original source. The syscall_printf calls aren't necessary and cause overhead not needed. So your patch should only need to change line 1650 to read ``return PC_FULL;''. Please change it and add an appropriate ChangeLog entry at the top. Thank-you Andres for finding a simple resolution. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Andres R. <lo...@ho...> - 2004-09-02 16:06:44
Attachments:
path.patch
|
Hi! I made another patch and made changes as you suggested. Andres ----------------------------------------- ITV - Sinu lemmiksaated internetis! http://www.itv.ee |
From: Earnie B. <ea...@us...> - 2004-09-06 03:08:31
|
Andres Rand wrote: >Hi! > >I made another patch and made changes as you suggested. > > > I've updated CVS with your patch. I've also updated CVS with some local changes for debugging purposes. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |
From: Earnie B. <ea...@us...> - 2004-08-29 04:13:07
|
Andres, I did respond and yes, the source of the problem is in MSYS. I had=20 stated that I currently don't have time to take a look at MSYS but all=20 files should be opened in binary mode regardless. Patches will be=20 greatly appreciated. Earnie Andres Rand wrote: >Hi! > >Since there has been no respone, I looked a little at fileutils source. >I got some interesting findings in copy.c function: static int copy_reg= ( .... ) >---314--- >for (;;) >{ > int n_read =3D read (source_desc, buf, buf_size); >---316--- >read returns wrong number of bytes (cr/lf -> lf conversion) on >cp //server/share/file . condition. Otherwise it returns right number of= bytes. >fstat (source_desc, &sb) shows right nunber of bytes all the time. > >May it be, msys runtime read is somehow affected, but not fileutils?? >(If that's the case, I can start looking in other places..) > >Andres Rand > >----------------------------------------- >ITV - Sinu lemmiksaated internetis! >http://www.itv.ee > > > >------------------------------------------------------- >This SF.Net email is sponsored by BEA Weblogic Workshop >FREE Java Enterprise J2EE developer tools! >Get your free copy of BEA WebLogic Workshop 8.1 today. >http://ads.osdn.com/?ad_idP47&alloc_id=10808&op=3Dclick >_______________________________________________ >Mingw-msys mailing list >Min...@li... >https://lists.sourceforge.net/lists/listinfo/mingw-msys > > > > =20 > --=20 http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=3D15438 |