From psionic at psionic.de Fri Feb 1 08:27:34 2002 From: psionic at psionic.de (Jochen Schaeuble) Date: Fri, 1 Feb 2002 09:27:34 +0100 Subject: ftpfs-mini-patch Message-ID: <20020201082734.GD2067@psionic.de> Hi, I've modified the vfsutil.c source a bit so I can connect to a ftp server where the username contains the @ symbol. It's really simple... I just changed the strchr into a strrchr. That's all. I hope this mini-patch is helpful to others out there. Greets, jochen P.S. I'm not subscribed on this list. If you want to reach me please use my e-mail address. -------------- next part -------------- --- mc-4.5.55.orig/vfs/utilvfs.c Fri Aug 3 12:12:18 2001 +++ mc-4.5.55/vfs/utilvfs.c Fri Feb 1 08:57:06 2002 @@ -89,7 +89,7 @@ } /* search for any possible user */ - at = strchr (pcopy, '@'); + at = strrchr (pcopy, '@'); /* We have a username */ if (at){ From kai at cmail.ru Mon Feb 4 09:24:51 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Mon, 4 Feb 2002 11:24:51 +0200 Subject: ftpfs-mini-patch References: <20020201082734.GD2067@psionic.de> Message-ID: <008501c1ad5d$ce472f60$8a65a8c0@sav> Hello, Jochen! > I've modified the vfsutil.c source a bit so I can connect to a ftp > server where the username contains the @ symbol. It's really simple... > I just changed the strchr into a strrchr. That's all. I hope this > mini-patch is helpful to others out there. There are can be at `@' symbols in password and in path too, so this patch can break more things. Regards, Andrew. From sav at it.efp.com.ua Mon Feb 4 11:57:08 2002 From: sav at it.efp.com.ua (Andrew V. Samoilov) Date: Mon, 4 Feb 2002 13:57:08 +0200 Subject: ftpfs-mini-patch References: <20020201082734.GD2067@psionic.de> <008501c1ad5d$ce472f60$8a65a8c0@sav> <20020204111012.GA4268@psionic.de> Message-ID: <00d301c1ad73$12b4d610$8a65a8c0@sav> > Hi Andrew, > I had no problem yet but I don't have the case you mentioned. So this > patch works for me :). Do you have a suggestion how to solve the > problem in a more elegant way? It will be fine if it will be possible to protect `@', `:' and `/' by backslash or something else. From volker_apelt at yahoo.de Mon Feb 4 15:52:45 2002 From: volker_apelt at yahoo.de (Volker Apelt) Date: Mon, 4 Feb 2002 16:52:45 +0100 (CET) Subject: Making/using libvfs standalone. Message-ID: <20020204155245.6660B5B5@apelt-pc.in-house> Hallo, What parts of the ./vfs directory are required to use the libvfs.so as a standalone library? I am investigating how libvfs can be used as a part of another project. Is the is the library libvfs.so it self and the header file vfs.h enough? At the end of this message you will find a patch, which changes ./vfs/Make-mc.in to allow compilation of util-alone.c It requires LIBDIR, which was not defined. Is setting it to "\"${mclibdir}\"" OK? Thank you, Volker Apelt -- Volker Apelt volker_apelt . at . yahoo.de (remove the dots, please) Dipl. Chem. +49 6172 31126 -------------- next part -------------- diff -u -r -bB mc-4.5.55/vfs/Make-mc.in mc-my/vfs/Make-mc.in --- mc-4.5.55/vfs/Make-mc.in Mon Feb 4 16:19:08 2002 +++ mc-my/vfs/Make-mc.in Wed Aug 1 18:15:22 2001 @@ -202,10 +202,10 @@ utilunix.sor sfs.so fish.so direntry.so cpio.so %.sor: ../src/%.c + $(CC) -c -fpic $(CPPFLAGS) $(DEFS) $(CFLAGS) -DLIBDIR="\"${mclibdir}\"" -DVFS_STANDALONE $< -o $@ - $(CC) -c -fpic $(CPPFLAGS) $(DEFS) $(CFLAGS) -DVFS_STANDALONE $< -o $@ %.so: %.c + $(CC) -c -fpic $(CPPFLAGS) $(DEFS) $(CFLAGS) -DLIBDIR="\"${mclibdir}\"" -DVFS_STANDALONE $< -o $@ - $(CC) -c -fpic $(CPPFLAGS) $(DEFS) $(CFLAGS) -DVFS_STANDALONE $< -o $@ libvfs.so: $(VFSSOOBJS) gcc $(VFSSOOBJS) -shared -o libvfs.so From Marc.FALESSE at supinfo.com Tue Feb 5 01:34:04 2002 From: Marc.FALESSE at supinfo.com (FALESSE Marc) Date: Tue, 5 Feb 2002 02:34:04 +0100 Subject: Making/using libvfs standalone Message-ID: <4A0B1814A98C2B4D98994A6668071CB92F6C0B@mail.supinfo.com> >What parts of the ./vfs directory are required to use the >libvfs.so as a standalone library? >I am investigating how libvfs can be used as a part of >another project. You *might* be interested in GnomeVFS. Take a look at : http://developer.gnome.org/doc/API/gnome-vfs/ Marc Falesse From Marc.FALESSE at supinfo.com Tue Feb 5 01:35:58 2002 From: Marc.FALESSE at supinfo.com (FALESSE Marc) Date: Tue, 5 Feb 2002 02:35:58 +0100 Subject: Making/using libvfs standalone Message-ID: <4A0B1814A98C2B4D98994A6668071CB92F6C0C@mail.supinfo.com> >What parts of the ./vfs directory are required to use the >libvfs.so as a standalone library? >I am investigating how libvfs can be used as a part of >another project. You *might* be interested in GnomeVFS. Take a look at : http://developer.gnome.org/doc/API/gnome-vfs/ Marc Falesse From kai at cmail.ru Tue Feb 5 08:40:19 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Tue, 5 Feb 2002 10:40:19 +0200 Subject: Unprintable characters with --enable-charset References: Message-ID: <003c01c1ae20$c8f3ec60$8a65a8c0@sav> Hello! > > > I want to continue discussion about displaying unprintable > > characters. > > The problem has arised when I tried to use new experimental > > feature "Support for charset selection and > > conversion" (--enable-charset). I set c_y_r_i_l_l_i_c input encodings > > and decided to view any binary file. After few strokes on PgDn MC screen > > was completely crashed and I saw invitation to search strange regex. > > I guess that it's exactly the problem that I noticed immediately in the > charset patch. It relies on charset conversion doing filtering of > unprintable characters. > > That's precisely the reason why the charset patch is experimental and is > disabled by default. > > I promise to look into that before releasing the next version (unless the > release is forced by security issues). > > > #ifdef HAVE_CHARSET > > - if (display_codepage < 0) { > > +/* Because of broken printable[] in charset.c */ > > +/* we still need in filtering characters #127 and #155 */ > > Exactly! I applied patch below to CVS: ChangeLog: * util.c [HAVE_CHARSET] (is_printable): Eliminate printable. * setup.c [HAVE_CHARSET] (load_setup): Don't use init_printable_table(). * charset.c (printable): Removed. (init_printable_table): Removed. Index: util.c =================================================================== RCS file: /cvs/gnome/mc/src/util.c,v retrieving revision 1.57 diff -u -p -r1.57 util.c --- util.c 2002/01/17 07:17:54 1.57 +++ util.c 2002/02/04 17:48:13 @@ -78,13 +78,10 @@ int is_printable (int c) c &= 0xff; #ifdef HAVE_CHARSET - if (display_codepage < 0) { - if (xterm_flag) - return xterm_printable[c]; - else - return (c > 31 && c != 127 && c != 155); - } else - return printable[ c ]; + if (xterm_flag) + return xterm_printable[c]; + else + return (c > 31 && c != 127 && c != 155); #else if (eight_bit_clean){ if (full_eight_bits){ Index: charsets.c =================================================================== RCS file: /cvs/gnome/mc/src/charsets.c,v retrieving revision 1.12 diff -u -p -r1.12 charsets.c --- charsets.c 2002/01/29 15:10:00 1.12 +++ charsets.c 2002/02/04 17:48:14 @@ -15,7 +15,6 @@ struct codepage_desc *codepages; uchar conv_displ[256]; uchar conv_input[256]; -uchar printable[256]; int load_codepages_list(void) { @@ -142,21 +141,6 @@ char errbuf[255]; * in mc.charsets */ #define CP_ASCII 0 - -char* init_printable_table( int cpdisplay ) -{ - int i; - - /* Fill printable characters table */ - for (i=0; i<=127; ++i) - printable[i] = (i > 31 && i != 127); - - for (i=128; i<=255; ++i) { - printable[i] = 1; - } - - return NULL; -} char* init_translation_table( int cpsource, int cpdisplay ) { Index: setup.c =================================================================== RCS file: /cvs/gnome/mc/src/setup.c,v retrieving revision 1.57 diff -u -p -r1.57 setup.c --- setup.c 2002/01/17 07:17:54 1.57 +++ setup.c 2002/02/04 17:48:15 @@ -573,7 +573,6 @@ load_setup (void) display_codepage = get_codepage_index( cpname ); } - init_printable_table( display_codepage ); init_translation_table( source_codepage, display_codepage ); #endif /* HAVE_CHARSET */ } From sav at it.efp.com.ua Wed Feb 6 13:49:05 2002 From: sav at it.efp.com.ua (Andrew V. Samoilov) Date: Wed, 6 Feb 2002 15:49:05 +0200 Subject: Ftpfs security hole particulary fixed References: Message-ID: <004401c1af15$0e6a5c30$8a65a8c0@sav> Hi, Pavel! > It would be better it you reported the problem with that server. Gregory A Lundberg mailed me: > All this is handled by the external bin/ls program; what you get is what the > program does. But I don't know ls option to produce this output. > You > could also test other FTP clients to see it they work with the broken > server (try e.g. gftp and Far Manager). Far Manager use "LIST" without Unix ls options and does not show dotfiles. And if I use "LIST -la" instead "LIST -la ." all is ok. I don't know, is this has not problem with other ftp servers, but it seems it's safe. Regards, Andrew. I commited patch below: ChangeLog: * ftpfs.c (dir_load): Use "LIST -la" instead of "LIST -la ." to eliminate problem with wu-ftpd. Close sock on error. Eliminate goto. Index: ftpfs.c =================================================================== RCS file: /cvs/gnome/mc/vfs/ftpfs.c,v retrieving revision 1.85 diff -u -p -u -p -r1.85 ftpfs.c --- ftpfs.c 2002/02/01 12:21:55 1.85 +++ ftpfs.c 2002/02/06 12:08:01 @@ -1231,17 +1232,17 @@ again: sock = open_data_connection (me, super, "LIST", 0, TYPE_ASCII, 0); else if (cd_first) /* Dirty hack to avoid autoprepending / to . */ - sock = open_data_connection (me, super, "LIST -la .", 0, TYPE_ASCII, 0); + /* Wu-ftpd produces strange output for '/' if 'LIST -la .' used */ + sock = open_data_connection (me, super, "LIST -la", 0, TYPE_ASCII, 0); else { /* Trailing "/." is necessary if remote_path is a symlink but don't generate "//." */ - char *path = g_strconcat (remote_path, - (!*remote_path) ? "" : PATH_SEP_STR, - ".", - NULL); + char *path = (*remote_path) ? concat_dir_and_file (remote_path, ".") + : NULL; sock = open_data_connection (me, super, "LIST -la", path, TYPE_ASCII, 0); - g_free (path); + if (path) + g_free (path); } if (sock == -1) @@ -1279,10 +1280,16 @@ again: int res = vfs_s_get_line_interruptible (me, buffer, sizeof (buffer), sock); if (!res) break; + if (res == EINTR) { me->verrno = ECONNRESET; - goto error; + close (sock); + disable_interrupt_key(); + get_reply(me, SUP.sock, NULL, 0); + print_vfs_message(_("ftpfs: failed")); + return -1; } + if (logfile){ fputs (buffer, logfile); fputs ("\n", logfile); @@ -1328,12 +1335,6 @@ again: } #endif return 0; - -error: - disable_interrupt_key(); - get_reply(me, SUP.sock, NULL, 0); - print_vfs_message(_("ftpfs: failed")); - return -1; fallback: if (SUP.strict == RFC_AUTODETECT) { From dickey at herndon4.his.com Wed Feb 6 10:41:06 2002 From: dickey at herndon4.his.com (Thomas Dickey) Date: Wed, 6 Feb 2002 05:41:06 -0500 Subject: mc-4.5.99a In-Reply-To: ; from proski@gnu.org on Wed, Feb 06, 2002 at 12:24:58AM -0500 References: <20020205195619.A13073@bloatware.reston01.va.comcast.net> Message-ID: <20020206054106.A430@bloatware.reston01.va.comcast.net> On Wed, Feb 06, 2002 at 12:24:58AM -0500, Pavel Roskin wrote: > Hi, Thomas! > > On Tue, 5 Feb 2002, Thomas Dickey wrote: > > > One of the package porters noted that there were some bugs in mc (in the > > ncurses configuration) which do not appear in the previous stable version. > > Besides these fixes, I note that the mouse interface is broken (he was > > complaining about a problem with the editor which I haven't seen yet). > > > > The attached patch fixes resizing (perhaps I'll come back to this after lynx). > > I don't quite understand the situation. Is it your patch or somebody mine (I didn't see the contact address in the readme, so I looked in the changelog to see who would be a good contact). > elses? I don't want to credit wrong people. The patch seems to be good, > but since there is no detailed comment, I must spent more time checking > it. There was more than one problem with resize: a) the missing $ncurses_version caused resizeterm to not be found. b) checking a report that mc didn't use the whole screen when setting xterm font to "Unreadable", I noticed that mc died when I made the screen very large. That was a buffer-overflow problem when the screen width was wider than 1024. (screen.c) c) while debugging for the former bug, I tried using gdb with ElectricFence. But that didn't work. The problem was that mc's sigwinch handler was calling resizeterm, which performs malloc's, etc., which essentially hung the process. That was probably leftover from my first patch in 1997 or 1998. So I ifdef'd out the (unnecessary) call. (layout.c) d) before that ("c" took some work ;-), I found that mc was treating the resize event as a SIGTSTP. That was fixed by the ifdef in key.c > > Please use the mailing list mc-devel at gnome.org next time. > > Lost ncurses_version is indeed a problem, but I've applied a more > elaborate fix. I've applied all other patches as well. > > Thank you! no problem. When is the next version to be completed? (So I know to come back and fix the mouse, if needed, before then). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net From sav at it.efp.com.ua Wed Feb 6 14:59:36 2002 From: sav at it.efp.com.ua (Andrew V. Samoilov) Date: Wed, 6 Feb 2002 16:59:36 +0200 Subject: mc-4.5.99a References: <20020205195619.A13073@bloatware.reston01.va.comcast.net> <20020206054106.A430@bloatware.reston01.va.comcast.net> Message-ID: <000601c1af1e$e6adbcf0$8a65a8c0@sav> Hi, Thomas! > c) while debugging for the former bug, I tried using gdb with > ElectricFence. But that didn't work. The problem was that > mc's sigwinch handler was calling resizeterm, which performs > malloc's, etc., which essentially hung the process. That was > probably leftover from my first patch in 1997 or 1998. So > I ifdef'd out the (unnecessary) call. (layout.c) This is my patch and mc with slang does not inform child(s) about SIGWING. Is where more elegant way to inform child about SIGWINCH. Does your application(s) invoked from mc resize itself after mc resizing? Regards, Andrew. From dickey at herndon4.his.com Wed Feb 6 15:11:10 2002 From: dickey at herndon4.his.com (Thomas E. Dickey) Date: Wed, 6 Feb 2002 10:11:10 -0500 (EST) Subject: mc-4.5.99a In-Reply-To: <000601c1af1e$e6adbcf0$8a65a8c0@sav> Message-ID: On Wed, 6 Feb 2002, Andrew V. Samoilov wrote: > Hi, Thomas! > > > c) while debugging for the former bug, I tried using gdb with > > ElectricFence. But that didn't work. The problem was that > > mc's sigwinch handler was calling resizeterm, which performs > > malloc's, etc., which essentially hung the process. That was > > probably leftover from my first patch in 1997 or 1998. So > > I ifdef'd out the (unnecessary) call. (layout.c) > > This is my patch and mc with slang does not inform child(s) about > SIGWING. Is where more elegant way to inform child about SIGWINCH. > Does your application(s) invoked from mc resize > itself after mc resizing? I only ifdef'd out the call for the ncurses case (slang is not affected). There is a similar call in another part of the code which checks the flag set in the handler. That works for the case I was looking at. I didn't test that with a child process running (just mc, and with the embedded editor - I'm not sure how to set up a child process in the manner which you suggest may not work). -- T.E.Dickey http://invisible-island.net ftp://invisible-island.net From Dmitry.Semyonov at oktet.ru Wed Feb 6 16:06:07 2002 From: Dmitry.Semyonov at oktet.ru (Dmitry Semyonov) Date: Wed, 6 Feb 2002 19:06:07 +0300 (MSK) Subject: mc 4.5.55 bug with copying folder over file with the same name. Message-ID: Hello! Versions info: ------------- Red Hat Linux version 2.2.16 (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) GNU Midnight Commander 4.5.55 compiled from sources: Edition: text mode Virtual File System: tarfs, extfs, ftpfs, mcfs With builtin Editor Using S-Lang library with terminfo database With subshell support as default With support for background operations With mouse support on xterm With multiple codepages support Using locale "en_US" (from environment variable LC_ALL) Bug: Try to copy folder "dir1" into folder "dir2" containing regular --- file named "dir1". 1. mc will not report any error. 2. You will see that "dir1" file attributes were rewritten with attributes of folder "dir1". 3. Moreover if you will try to move the folder instead of copy, it will be lost without any warning... ...Bye..Dmitry. From proski at gnu.org Thu Feb 7 04:41:34 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 6 Feb 2002 23:41:34 -0500 (EST) Subject: Unprintable characters with --enable-charset In-Reply-To: <003c01c1ae20$c8f3ec60$8a65a8c0@sav> Message-ID: Hello! > * util.c [HAVE_CHARSET] (is_printable): Eliminate printable. > * setup.c [HAVE_CHARSET] (load_setup): Don't use > init_printable_table(). > > * charset.c (printable): Removed. > (init_printable_table): Removed. Good enough. -- Regards, Pavel Roskin From proski at gnu.org Thu Feb 7 04:58:10 2002 From: proski at gnu.org (Pavel Roskin) Date: Wed, 6 Feb 2002 23:58:10 -0500 (EST) Subject: Ftpfs security hole particulary fixed In-Reply-To: <004401c1af15$0e6a5c30$8a65a8c0@sav> Message-ID: Hello! > > You > > could also test other FTP clients to see it they work with the broken > > server (try e.g. gftp and Far Manager). > > Far Manager use "LIST" without Unix ls options and does not show dotfiles. That's what I expected. Thank you for checking it. > And if I use "LIST -la" instead "LIST -la ." all is ok. > I don't know, is this has not problem with other ftp servers, but it seems it's safe. I tested MC on a few sites and found that it doesn't work on ftp.netbsd.org. It shows the top-level directory, but show nothing in /pub. Here's the log: PASV 227 Entering Passive Mode (204,152,184,75,238,199) LIST -la /pub/. 150 Opening ASCII mode data connection for '/bin/ls'. 226 Transfer complete. I think that "LIST -la /pub" would have chances to work on more systems. MC before your patch doesn't work on ftp.netbsd.org at all. But you probably didn't go far enough to eliminate all trailing dots. > /* Trailing "/." is necessary if remote_path is a symlink > but don't generate "//." */ Maybe trailing "/" is sufficient? Besides, ftp.netbsd.org/pub is not a symlink. Maybe the code isn't doing what the comment says? Thank you for your patch! -- Regards, Pavel Roskin From proski at gnu.org Thu Feb 7 05:02:39 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 7 Feb 2002 00:02:39 -0500 (EST) Subject: mc 4.5.55 bug with copying folder over file with the same name. In-Reply-To: Message-ID: Hello! > Bug: Try to copy folder "dir1" into folder "dir2" containing regular > --- file named "dir1". > 1. mc will not report any error. > 2. You will see that "dir1" file attributes were rewritten with > attributes of folder "dir1". > 3. Moreover if you will try to move the folder instead of copy, > it will be lost without any warning... This bug appears to be fixed in the current code. I could not reproduce it with the CVS version of MC. -- Regards, Pavel Roskin From proski at gnu.org Thu Feb 7 05:31:24 2002 From: proski at gnu.org (Pavel Roskin) Date: Thu, 7 Feb 2002 00:31:24 -0500 (EST) Subject: mc-4.5.99a In-Reply-To: <20020206054106.A430@bloatware.reston01.va.comcast.net> Message-ID: Hi, Thomas! > mine (I didn't see the contact address in the readme, so I looked in the > changelog to see who would be a good contact). Thanks for the patch and for the explanation. Fortunately, I described your changes close enough, and the complete explanation is now in the list archives. > a) the missing $ncurses_version caused resizeterm to not be found. Clearly my bug. Fixed. Actually, the whole scheme for ncurses detection should be simplified. Currently MC cannot find ncurses on QNX Neutrino 6.1.0 because it mimics old curses too closely. > b) checking a report that mc didn't use the whole screen when setting > xterm font to "Unreadable", I noticed that mc died when I made the > screen very large. That was a buffer-overflow problem when the > screen width was wider than 1024. (screen.c) Thank you for finding it. Having dynamic buffers just to survive this "torture" would be a waste of resources, but boundary check is a good idea. > c) while debugging for the former bug, I tried using gdb with > ElectricFence. But that didn't work. The problem was that > mc's sigwinch handler was calling resizeterm, which performs > malloc's, etc., which essentially hung the process. That was > probably leftover from my first patch in 1997 or 1998. So > I ifdef'd out the (unnecessary) call. (layout.c) Thanks! > d) before that ("c" took some work ;-), I found that mc was treating > the resize event as a SIGTSTP. That was fixed by the ifdef in > key.c I could not find any references to SIGTSTP in key.c. My understanding is that your patch makes MC ignore KEY_RESIZE. I wonder if the screen can actually be resized at this time. > no problem. When is the next version to be completed? (So I know to come > back and fix the mouse, if needed, before then). I'm currently considering end of March for the 4.6 release. Unfortunately, my job in AT&T Labs takes too much of my time and resources (yet it's a great place to work), but I hope to be able to work on MC anyways. VFS needs to be made more reliable (many thanks to Andrew Samoilov for doing so much not-trivial work on it). MC should use color with S-Lang not only on a few "known good" terminals. I want to scan the list for remaining unapplied patches. Time permitting, MC should compile on Win32 with MSVC and MinGW. Also the regex problems on Cygwin should be sorted out. Last week before the release will be dedicated to portability testing, This time it should be easier, because Automake is used consistently in all directories and there is no GNOME code. -- Regards, Pavel Roskin From sav at it.efp.com.ua Thu Feb 7 09:35:56 2002 From: sav at it.efp.com.ua (Andrew V. Samoilov) Date: Thu, 07 Feb 2002 11:35:56 +0200 Subject: mc 4.5.55 bug with copying folder over file with the same name. References: Message-ID: <3C624A7C.8090404@it.efp.com.ua> Pavel Roskin wrote: > Hello! > > >>Bug: Try to copy folder "dir1" into folder "dir2" containing regular >>--- file named "dir1". >> 1. mc will not report any error. >> 2. You will see that "dir1" file attributes were rewritten with >> attributes of folder "dir1". >> 3. Moreover if you will try to move the folder instead of copy, >> it will be lost without any warning... >> > > This bug appears to be fixed in the current code. I could not reproduce > it with the CVS version of MC. Fixed in CVS on January 15, 2002. See http://mail.gnome.org/archives/mc-devel/2002-January/msg00022.html for patch. From kai at cmail.ru Thu Feb 7 09:56:02 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Thu, 07 Feb 2002 11:56:02 +0200 Subject: Ftpfs security hole particulary fixed References: Message-ID: <3C624F32.4050109@cmail.ru> Hello! > I tested MC on a few sites and found that it doesn't work on > ftp.netbsd.org. It shows the top-level directory, but show nothing in > /pub. Here's the log: > > PASV > 227 Entering Passive Mode (204,152,184,75,238,199) > LIST -la /pub/. > 150 Opening ASCII mode data connection for '/bin/ls'. > 226 Transfer complete. > > I think that "LIST -la /pub" would have chances to work on more systems. Not at ftp.netbsd.org. Single way is "cd then ls" ;-( Can you report this problem to NetBSD-ftpd developers? > > MC before your patch doesn't work on ftp.netbsd.org at all. But you > probably didn't go far enough to eliminate all trailing dots. > > >> /* Trailing "/." is necessary if remote_path is a symlink >> but don't generate "//." */ >> > > Maybe trailing "/" is sufficient? Besides, ftp.netbsd.org/pub is not a > symlink. Maybe the code isn't doing what the comment says? > It does, but I have not access to amiga ftp server. Trailing "/." removed for Amiga server in translate(), but remote_is_amiga ignored in dir_load(). BTW, why do you complain against "LIST -laL"? From dickey at herndon4.his.com Thu Feb 7 11:34:44 2002 From: dickey at herndon4.his.com (Thomas E. Dickey) Date: Thu, 7 Feb 2002 06:34:44 -0500 (EST) Subject: mc-4.5.99a In-Reply-To: Message-ID: On Thu, 7 Feb 2002, Pavel Roskin wrote: > Actually, the whole scheme for ncurses detection should be simplified. > Currently MC cannot find ncurses on QNX Neutrino 6.1.0 because it mimics > old curses too closely. yes - it can be hard distinguishing between versions of curses (as you may see from the macros I've written for tin/lynx). I do have a QNX to experiment with, but haven't been on it recently. (ncurses does build, but there is some problem with the linker - it prefers using the system's shared libraries rather than the static ones I prefer for testing - but libtool does have that case addressed). > > d) before that ("c" took some work ;-), I found that mc was treating > > the resize event as a SIGTSTP. That was fixed by the ifdef in > > key.c > > I could not find any references to SIGTSTP in key.c. My understanding is > that your patch makes MC ignore KEY_RESIZE. I wonder if the screen can > actually be resized at this time. The code (further down in that module) was and'ing KEY_RESIZE with 0xff, which made it equal ^Z, and consequently interpreted as SIGTSTP. I don't think it was apparent before - my recollection is that MC was using its own signal handler. (Perhaps a bug in the way I set it up - ncurses sigwinch was probably active, otherwise I wouldn't have gotten that problem). > > no problem. When is the next version to be completed? (So I know to come > > back and fix the mouse, if needed, before then). > > I'm currently considering end of March for the 4.6 release. > Unfortunately, my job in AT&T Labs takes too much of my time and resources > (yet it's a great place to work), but I hope to be able to work on MC > anyways. ok - then I probably have time to revisit it. That was the xterm mouse (I had configured without gpm, to simplify debugging). The cursor keys work properly (but that was surprising since ESCDELAY is set to 0 - so I still have a couple of unanswered questions). The original report that got me looking at MC is that running the editor on FreeBSD produces some screen trash. -- T.E.Dickey http://invisible-island.net ftp://invisible-island.net From volker_apelt at yahoo.de Thu Feb 7 11:55:11 2002 From: volker_apelt at yahoo.de (Volker Apelt) Date: Thu, 7 Feb 2002 12:55:11 +0100 (CET) Subject: Making/using libvfs standalone. In-Reply-To: <20020204155245.6660B5B5@apelt-pc.in-house> References: <20020204155245.6660B5B5@apelt-pc.in-house> Message-ID: <20020207115511.BF2A5553@apelt-pc.in-house> Re: to my self: On Mon, 4 Feb 2002 16:52:45 +0100 (CET) Volker Apelt wrote: > Is the is the library libvfs.so it self and the header file vfs.h > enough? A short test showed it is sufficient. If you use it from c++ you have to wrap the .h in 'extern "C" { ..header .. } ', because the vfs.h is not properly wrapped. -- Volker Apelt volker_apelt . at . yahoo.de (remove the dots, please) Dipl. Chem. +49 6172 31126 From pkozelka at email.cz Fri Feb 8 09:48:46 2002 From: pkozelka at email.cz (Petr Kozelka) Date: Fri, 8 Feb 2002 10:48:46 +0100 Subject: mouse wheel Message-ID: <003501c1b085$cd9a6070$a372daa0@eurotel.cz> Hello Pavel, do you think that MC will support mouse wheel ? Or, is it there already, and needs just to be configured somehow ? Petr From kai at cmail.ru Fri Feb 8 10:14:34 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Fri, 8 Feb 2002 12:14:34 +0200 Subject: Some translated messages changed Message-ID: <20020208121434.A417@it.efp.com.ua> Hello, I commited patch and there are some translated messages changed. I fixed Russian and Ukrainian translations, but other languages need to be fixed. s/"ftpfs: storing file %d (%lu)"/"ftpfs: storing file %lu (%lu)"/ s/"%s: %s: %s %3d%% (%ld bytes transfered)"/"%s: %s: %s %3d%% (%lu bytes transfered)"/ s/"%s: %s: %s %ld bytes transfered"/"%s: %s: %s %lu bytes transfered"/ Regards, Andrew. Index: mc/vfs/ChangeLog diff -u mc/vfs/ChangeLog:1.379 mc/vfs/ChangeLog:1.380 --- mc/vfs/ChangeLog:1.379 Thu Feb 7 14:22:21 2002 +++ mc/vfs/ChangeLog Fri Feb 8 04:42:38 2002 @@ -1,3 +1,19 @@ +2002-02-08 Andrew V. Samoilov + + * direntry.c (vfs_s_retrieve_file): Use off_t for total + and stat_size. + + * vfs.c (vfs_s_resolve_symlink): Use snprintf + instead of sprintf. + (vfs_print_stats): Use off_t for have and need. Cast + have to double to eliminate negative percent(s). + Fix print_vfs_message string formats. + + * vfs.h (vfs_print_stats): Adjust declaration. + + * ftpfs.c (file_store): Use off_t for total. + Fix print_vfs_message string format. + 2002-02-07 Andrew V. Samoilov * ftpfs.c (dir_load): Speed up cd_first calculation. Index: mc/vfs/ftpfs.c diff -u mc/vfs/ftpfs.c:1.88 mc/vfs/ftpfs.c:1.89 --- mc/vfs/ftpfs.c:1.88 Thu Feb 7 14:22:20 2002 +++ mc/vfs/ftpfs.c Fri Feb 8 04:42:38 2002 @@ -1359,7 +1359,8 @@ static int file_store(vfs *me, vfs_s_super *super, char *name, char *localname) { - int h, sock, n, total; + int h, sock, n; + off_t total; #ifdef HAVE_STRUCT_LINGER struct linger li; #else @@ -1415,8 +1416,8 @@ goto error_return; } total += n; - print_vfs_message(_("ftpfs: storing file %d (%lu)"), - total, (unsigned long) s.st_size); + print_vfs_message(_("ftpfs: storing file %lu (%lu)"), + (unsigned long) total, (unsigned long) s.st_size); } disable_interrupt_key(); close(sock); Index: mc/vfs/vfs.h diff -u mc/vfs/vfs.h:1.57 mc/vfs/vfs.h:1.58 --- mc/vfs/vfs.h:1.57 Mon Jan 21 16:26:50 2002 +++ mc/vfs/vfs.h Fri Feb 8 04:42:38 2002 @@ -338,7 +338,8 @@ #define URL_DEFAULTANON 1 #define URL_NOSLASH 2 -extern void vfs_print_stats (char *fs_name, char *action, char *file_name, int have, int need); +extern void vfs_print_stats (const char *fs_name, const char *action, + const char *file_name, off_t have, off_t need); /* Don't use values 0..4 for a while -- 10/98, pavel at ucw.cz */ #define MCCTL_REMOVELOCALCOPY 5 Index: mc/vfs/vfs.c diff -u mc/vfs/vfs.c:1.80 mc/vfs/vfs.c:1.81 --- mc/vfs/vfs.c:1.80 Mon Jan 21 06:52:25 2002 +++ mc/vfs/vfs.c Fri Feb 8 04:42:38 2002 @@ -1840,21 +1840,21 @@ } void -vfs_print_stats (char *fs_name, char *action, char *file_name, int have, int need) +vfs_print_stats (const char *fs_name, const char *action, const char *file_name, off_t have, off_t need) { static char *i18n_percent_transf_format = NULL, *i18n_transf_format = NULL; - + if (i18n_percent_transf_format == NULL) { - i18n_percent_transf_format = _("%s: %s: %s %3d%% (%ld bytes transfered)"); - i18n_transf_format = _("%s: %s: %s %ld bytes transfered"); - } + i18n_percent_transf_format = _("%s: %s: %s %3d%% (%lu bytes transfered)"); + i18n_transf_format = _("%s: %s: %s %lu bytes transfered"); + } if (need) - print_vfs_message (i18n_percent_transf_format, - fs_name, action, file_name, have*100/need, have); + print_vfs_message (i18n_percent_transf_format, fs_name, action, + file_name, (int)((double)have*100/need), (unsigned long) have); else - print_vfs_message (i18n_transf_format, - fs_name, action, file_name, have); + print_vfs_message (i18n_transf_format, + fs_name, action, file_name, (unsigned long) have); } #ifndef VFS_STANDALONE Index: mc/vfs/direntry.c diff -u mc/vfs/direntry.c:1.38 mc/vfs/direntry.c:1.39 --- mc/vfs/direntry.c:1.38 Thu Aug 16 18:23:05 2001 +++ mc/vfs/direntry.c Fri Feb 8 04:42:38 2002 @@ -3,7 +3,7 @@ * * Written at 1998 by Pavel Machek , distribute under LGPL. * - * $Id: direntry.c,v 1.38 2001/08/16 22:23:05 proskin Exp $ + * $Id: direntry.c,v 1.39 2002/02/08 09:42:38 andrew Exp $ * * Very loosely based on tar.c from midnight and archives.[ch] from * avfs by Miklos Szeredi (mszeredi at inf.bme.hu) @@ -368,7 +368,7 @@ return (MEDATA->find_entry) (me, entry->dir->super->root, linkname, follow - 1, 0); else { /* FIXME: this does not work */ char *fullpath = vfs_s_fullpath(me, entry->dir); - sprintf(buf, "%s/%s", fullpath, linkname); + snprintf(buf, sizeof (buf), "%s/%s", fullpath, linkname); g_free (fullpath); return (MEDATA->find_entry) (me, entry->dir->super->root, buf, follow - 1, 0); } @@ -934,14 +934,14 @@ vfs_s_retrieve_file(vfs *me, struct vfs_s_inode *ino) { /* If you want reget, you'll have to open file with O_LINEAR */ - int total = 0; + off_t total = 0; char buffer[8192]; int handle, n; - int stat_size = ino->st.st_size; + off_t stat_size = ino->st.st_size; struct vfs_s_fh fh; memset(&fh, 0, sizeof(fh)); - + fh.ino = ino; handle = mc_mkstemps (&ino->localname, me->name, NULL); From leventyavas at yahoo.com Mon Feb 11 14:56:41 2002 From: leventyavas at yahoo.com (levent yavas) Date: Mon, 11 Feb 2002 06:56:41 -0800 (PST) Subject: suggestions Message-ID: <20020211145641.38534.qmail@web14501.mail.yahoo.com> i downloaded mc-4.5.99a. i'm very happy with it. below are some good things that i enjoyed: * symlinking is easier (same filename appears in dialog box) * killing mc no longer overwrites its config file (to defaults) * home-end keys on xterm works but it's not bug-free. below are top biting ones: * when viewing inside zip files or after exiting them mc displays this error message and screen becomes corrupted: zip error: could not create output file (/home/levent/archive.zip) uzip (copyin): 'zip' failed - non-zero exit sattus what i understand from this error is, mc tries to write archive files this bug also keeps cdrom busy(of course when archive is in cdrom) i forced to exit mc, then cdrom happiliy unmounts. cdrom unmount problem also occurs when i looked inside tar files. * when numlock status is on, '/' on numeric keyboard works fine. but when numlock is off, '/' produces 'o' on xterm i have some wishes to see as mc's functionality * i have (and lots of users have i believe) lots of archives in cd's which are signed as executable (0555), thanks to vfat module. there is good to see mc has an option like 'dont execute files' so it's possible to enter inside archive files even they're marked as executable * color theme setting menu: i have a different colortable. i believe some users have too my computer is: Linux gediz 2.4.18-pre9 #2 Fri Feb 8 14:12:26 EET 2002 i686 unknown my colortable is: export MC_COLOR_TABLE="basecolor=lightgray,black:normal=lightgray,black: executable=green,black:link=brightcyan,black:stalledlink=lightred,black: device=yellow,black:special=gray,black:core=red,black: marked=yellow,black:directory=brightblue,black: markselect=yellow,lightgray:selected=black,lightgray:errors=red,black: input=lightgray,black:reverse=black,lightgray: menu=black,lightgray:menusel=lightgray,black:menuhot=brown,lightgray: menuhotsel=brown,black:editnormal=lightgray,black: editbold=white,black:editmarked=black,lightgray" __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com From oskar at osk.mine.nu Mon Feb 11 19:33:42 2002 From: oskar at osk.mine.nu (Oskar Liljeblad) Date: Mon, 11 Feb 2002 20:33:42 +0100 Subject: suggestions In-Reply-To: <20020211145641.38534.qmail@web14501.mail.yahoo.com> References: <20020211145641.38534.qmail@web14501.mail.yahoo.com> Message-ID: <20020211193342.GA564@oskar> On Monday, February 11, 2002 at 06:41, levent yavas wrote: [..] > but it's not bug-free. below are top biting ones: > > * when viewing inside zip files or after exiting them > mc displays > this error message and screen becomes corrupted: > zip error: could not create output file > (/home/levent/archive.zip) > uzip (copyin): 'zip' failed - non-zero exit sattus > > what i understand from this error is, mc tries to > write archive files Can you explain this in more detail please? Do you always get this error when you have browsed inside a zip file and exit MC? Or does this only happen with some specific zip archives? Also, can you tell me which version of zip that you are using (just type zip in the terminal and send me the output). Regards, Oskar Liljeblad (oskar at osk.mine.nu) From nerijus at users.sourceforge.net Mon Feb 11 20:04:22 2002 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Mon, 11 Feb 2002 22:04:22 +0200 (EET) Subject: suggestions In-Reply-To: <20020211193342.GA564@oskar> References: <20020211145641.38534.qmail@web14501.mail.yahoo.com> <20020211193342.GA564@oskar> Message-ID: On Mon, 11 Feb 2002 20:33:42 +0100 Oskar Liljeblad wrote: OL> > but it's not bug-free. below are top biting ones: OL> > OL> > * when viewing inside zip files or after exiting them OL> > mc displays OL> > this error message and screen becomes corrupted: OL> > zip error: could not create output file OL> > (/home/levent/archive.zip) OL> > uzip (copyin): 'zip' failed - non-zero exit sattus OL> > OL> > what i understand from this error is, mc tries to OL> > write archive files OL> OL> Can you explain this in more detail please? Do you always OL> get this error when you have browsed inside a zip file and OL> exit MC? It happens for me when I view (F3) some file in archive. I see the same error message if there are no permissions to write, otherwise archive's date becomes current date. OL> Or does this only happen with some specific OL> zip archives? I think with all, but I'm not sure. OL> Also, can you tell me which version of zip that you are OL> using (just type zip in the terminal and send me the output). Copyright (C) 1990-1999 Info-ZIP Type 'zip "-L"' for software license. Zip 2.3 (November 29th 1999). Usage: UnZip 5.42 of 14 January 2001, by Info-ZIP. Maintained by C. Spieler. Send bug reports to the authors at Zip-Bugs at lists.wku.edu; see README for details. Usage: unzip [-Z] [-opts[modifiers]] file[.zip] [list] [-x xlist] [-d exdir] Regards, Nerijus From nerijus at users.sourceforge.net Mon Feb 11 20:11:06 2002 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Mon, 11 Feb 2002 22:11:06 +0200 (EET) Subject: PATCH for mc.ext.in Message-ID: Hello, mplayer plays both mpg and avi files much better than gtv (from smpeg) and xanim. Both links and w3m support frames and tables, besides, default RH 7.2 server installation includes links, but not lynx. And both use less space than lynx. Ted displays rtf files very nicely, as gnumeric displays xls files. Regards, Nerijus --- mc.ext.in.orig Thu Nov 29 23:27:55 2001 +++ mc.ext.in Mon Feb 11 21:51:37 2002 @@ -276,10 +276,10 @@ ### Multimedia ### regex/\.(mpe?g|MPE?G|Mpe?g)$ - Open=(gtv %f 2>/dev/null &) + Open=(mplayer %f 2>/dev/null &) regex/\.(avi|AVI|Avi|mov|MOV|Mov)$ - Open=(xanim %f 2>/dev/null &) + Open=(mplayer %f 2>/dev/null &) regex/\.(rm|RM|Rm|ram|RAM|Ram)$ Open=(realplay %f &) @@ -302,8 +302,8 @@ # html regex/\.([Hh]tml?|HTML?)$ #Open=if echo "%d/%p" | grep ^ftp; then $viewer %d/%p; else $viewer file:%p; fi - Open=if test -n "@X11_WWW@" && test -n "$DISPLAY"; then echo @X11_WWW@ %f; (@X11_WWW@ %f &) >/dev/null 2>&1; else lynx -force_html %f; fi - View=%view{ascii} lynx -dump -force_html %f; + Open=if test -n "@X11_WWW@" && test -n "$DISPLAY"; then echo @X11_WWW@ %f; (@X11_WWW@ %f &) >/dev/null 2>&1; else links %f || w3m %f || lynx -force_html %f; fi + View=%view{ascii} links -dump %f || w3m -dump %f || lynx -dump -force_html %f # StarOffice and OpenOffice shell/.sdw @@ -319,10 +319,17 @@ type/^Microsoft\ Word View=%view{ascii} catdoc -w %f || word2x -f text %f - || strings %f +# RTF document +regex/\.(rtf|RTF|Rtf)$ + Open=(Ted %f &) # http://www.nllgg.nl/Ted/ + View=%view{ascii} strings %f + # Microsoft Excel Worksheet regex/\.([Xx]l[sw]|XL[SW])$ + Open=(gnumeric %f &) View=%view{ascii} xls2csv %f || strings %f type/^Microsoft\ Excel + Open=(gnumeric %f &) View=%view{ascii} xls2csv %f || strings %f # Use StarOffice to open any MS Office documents From oskar at osk.mine.nu Wed Feb 13 09:21:52 2002 From: oskar at osk.mine.nu (Oskar Liljeblad) Date: Wed, 13 Feb 2002 10:21:52 +0100 Subject: suggestions In-Reply-To: <20020212165651.72156.qmail@web14510.mail.yahoo.com> References: <20020211193342.GA564@oskar> <20020212165651.72156.qmail@web14510.mail.yahoo.com> Message-ID: <20020213092152.GA3173@oskar> On Tuesday, February 12, 2002 at 08:51, levent yavas wrote: > it occurs in read only archives. i attached an > info-zip > compressed archive. please keep it read-only and enter > the archive with mc, then view bk.html with F3 and > exit. the problem is here. please consider i'm not > saying mc is responsible from info-zip's bugs, but it > seems it is trying to write archive Hm. You are right. It seems MC writes the file to an archive when you exit the internal viewer. Not nice at all...! This is either a bug in extfs or MC. This is what happens: (/home/usel/try2.zip has permissions -r--r--r--.) "Enter" is pressed when cursor is over try2.zip: list /home/usel/try2.zip "F3" is pressed when cursor is over file bk.html in try2.zip: copyout /home/usel/try2.zip bk.html /tmp/extfsQA8iFb "Q" is pressed to exit the viewer, now the file is copied back into the archive: copyin /home/usel/try2.zip bk.html /tmp/extfsQA8iFb This means that every time you enter a zip archive an view files in it, the archive is modified! This should also be true for all other archives supported via extfs. Regards, Oskar Liljeblad (oskar at osk.mine.nu) From oskar at osk.mine.nu Wed Feb 13 09:32:34 2002 From: oskar at osk.mine.nu (Oskar Liljeblad) Date: Wed, 13 Feb 2002 10:32:34 +0100 Subject: suggestions In-Reply-To: <20020213092152.GA3173@oskar> References: <20020211193342.GA564@oskar> <20020212165651.72156.qmail@web14510.mail.yahoo.com> <20020213092152.GA3173@oskar> Message-ID: <20020213093234.GA4679@oskar> On Wednesday, February 13, 2002 at 10:52, usel wrote: > > This means that every time you enter a zip archive an view > files in it, the archive is modified! This should also be true > for all other archives supported via extfs. Correction: It does happen when you view files with an ".html" extension. The effect may be the same with other filetypes as well. But regular text files files without extension are not copied back into the archive! Oskar Liljeblad (oskar at osk.mine.nu) From despair at sama.ru Wed Feb 13 23:39:01 2002 From: despair at sama.ru (Walery Studennikov) Date: Thu, 14 Feb 2002 03:39:01 +0400 Subject: New version on mc-multiscreen-patch Message-ID: <20020214033901.A30501@prog1> Hello. Recently I've updated the "MC-multiscreen" patch to version 0.7, and it is available at http://www.sama.ru/~despair/mc/mc-multiscreen-0.7.patch.tar.gz . This verson is based on http://www.sama.ru/~despair/mc/mc-cvs-multiscreen-0.6.patch.gz , released by Andrew Samoilov. I will remind: Andrew has ported v0.5 to the CVS version of MC, and made --enable-dlgswitch option for ./configure . What's new in whis v0.7 release: * F12 behaviour repaired in editor, which was broken in v0.6 * Bookmarks/clipboard-in-menu features are separated to another independent patch: http://www.sama.ru/~despair/mc/mc-bookmarks-0.7.patch.tar.gz * ChangeLogs updated both for multiscreen and bookmarks patches * Cosmetic changes in bookmarks/clipboard patch Now about applying the patch. After patching the sources (use CVS sources or latest snapshot from http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/ ) , you need to rebuild configure.in and src/Makefile.in files. If you use CVS version you can use ./autogen.sh to rebiuld them automatically. After that you have to run ./configure with option --enable-dlgswitch Also you can pass this option directly to ./autogen.sh if you use it. -- Regards, Walery From sav at it.efp.com.ua Thu Feb 14 13:08:13 2002 From: sav at it.efp.com.ua (Andrew V. Samoilov) Date: Thu, 14 Feb 2002 15:08:13 +0200 Subject: New version on mc-multiscreen-patch References: <20020214033901.A30501@prog1> Message-ID: <3C6BB6BD.3080907@it.efp.com.ua> Hello! Walery Studennikov wrote: > What's new in whis v0.7 release: > > * F12 behaviour repaired in editor, which was broken in v0.6 I complain about F12 in editor. "Save As" is useful feature. > * Bookmarks/clipboard-in-menu features are separated to another > independent patch: > http://www.sama.ru/~despair/mc/mc-bookmarks-0.7.patch.tar.gz Fine. > * ChangeLogs updated both for multiscreen and bookmarks patches > > * Cosmetic changes in bookmarks/clipboard patch You puts your changes near CVS keywords again. Please move #ifdef DLGSWITCH before #ifdef HAVE_CHARSET in main.c. Don't hardcode debug filename in log_mc_handler. It can be new mc option. Use vfs_file_is_local() to determine file location in edit/editwidget.c:edit(). It will be best if somebody rewrite edit engine to use dir properly. It might be set to mc_return_cwd() if directory is NULL and filename is not absolute. It is not good idea to always concat dir and file - resulted filename may confuse users. PATH_SEP and PATH_SEP_STR have to be used instead of '/' and "/". Regards, Andrew. From despair at sama.ru Thu Feb 14 13:34:56 2002 From: despair at sama.ru (Walery Studennikov) Date: Thu, 14 Feb 2002 17:34:56 +0400 Subject: New version on mc-multiscreen-patch Message-ID: <20020214173456.B13537@prog1> On Thu, Feb 14, 2002 at 03:08:13PM +0200, Andrew V. Samoilov wrote: > >* F12 behaviour repaired in editor, which was broken in v0.6 > > I complain about F12 in editor. "Save As" is useful feature. It is still accessible through menu, anyway We would loose uniformity if F12 will behave another way in the editor. > You puts your changes near CVS keywords again. > Please move #ifdef DLGSWITCH before #ifdef HAVE_CHARSET > in main.c. Fixed (see v0.7.1) > Don't hardcode debug filename in log_mc_handler. > It can be new mc option. Do you mean a compile-time or a run-time option? > Use vfs_file_is_local() to determine file location > in edit/editwidget.c:edit(). It will be best if somebody > rewrite edit engine to use dir properly. It might be > set to mc_return_cwd() if directory is NULL and filename > is not absolute. It is not good idea to always concat > dir and file - resulted filename may confuse users. > > PATH_SEP and PATH_SEP_STR have to be used instead of '/' > and "/". It will be fixed soon. -- Regards, Walery From makovick at kmlinux.fjfi.cvut.cz Thu Feb 14 18:57:15 2002 From: makovick at kmlinux.fjfi.cvut.cz (Jindrich Makovicka) Date: Thu, 14 Feb 2002 19:57:15 +0100 Subject: [PATCH] copy_file_file bugfix & other responsiveness fixes Message-ID: <3C6C088B.8050601@kmlinux.fjfi.cvut.cz> This patch addresses the following issues 1) in file.c/copy_file_file, an event is read twice but only the second one is checked, which makes copying extremely hard to abort 2) view.c/search - added missing enable_interrupt_key(), also added checking for ESC 3) view.c/block_search - rewritten the search algorithm to use a lookup table - a little speedup 4) view.c - added an interruptible version of mc_read, displaying also the reading progress 5) find.c - content_search now check for events and searching can be suspended anytime (this is however a bit dirty hack, requiring a subtle change in dlg.c) Please cc: to my private email, I am not a subscriber. Regards, -- Jindrich Makovicka 8<-------- snip diff -urN vanilla/mc-4.5.99a/src/dlg.c mc-4.5.99a/src/dlg.c --- vanilla/mc-4.5.99a/src/dlg.c Wed Nov 7 13:15:11 2001 +++ mc-4.5.99a/src/dlg.c Wed Feb 13 23:25:58 2002 @@ -848,6 +848,8 @@ (*h->callback) (h, 0, DLG_IDLE); } } + + if (!h->running) break; update_cursor (h); (*h->callback)(h, 0, DLG_PRE_EVENT); diff -urN vanilla/mc-4.5.99a/src/file.c mc-4.5.99a/src/file.c --- vanilla/mc-4.5.99a/src/file.c Wed Jan 30 16:30:20 2002 +++ mc-4.5.99a/src/file.c Wed Feb 13 22:01:51 2002 @@ -734,7 +734,11 @@ } file_progress_set_stalled_label (ctx, stalled_msg); - file_progress_show_bytes (ctx, *progress_bytes + n_read_total, ctx->progress_bytes); + return_status = file_progress_show_bytes (ctx, *progress_bytes + n_read_total, ctx->progress_bytes); + if (return_status != FILE_CONT) { + mc_refresh (); + goto ret; + } return_status = file_progress_show (ctx, n_read_total, file_size); mc_refresh (); if (return_status != FILE_CONT) diff -urN vanilla/mc-4.5.99a/src/find.c mc-4.5.99a/src/find.c --- vanilla/mc-4.5.99a/src/find.c Wed Nov 14 21:54:55 2001 +++ mc-4.5.99a/src/find.c Thu Feb 14 09:06:58 2002 @@ -44,6 +44,7 @@ #include "wtools.h" #include "cmd.h" /* view_file_at_line */ #include "boxes.h" +#include "key.h" #include "../vfs/vfs.h" #if defined(HAVE_RX_H) && defined(HAVE_REGCOMP) @@ -85,6 +86,10 @@ static int is_start; /* Status of the start/stop toggle button */ static char *old_dir; +static int resuming; +static int last_line; +static int last_pos; + static Dlg_head *find_dlg; /* The dialog */ static WButton *stop_button; /* pointer to the stop button */ @@ -410,7 +415,7 @@ * Search the global (FIXME) content_pattern string in the * DIRECTORY/FILE. It will add the found entries to the find listbox. */ -static void +static int search_content (Dlg_head *h, char *directory, char *filename) { struct stat s; @@ -419,19 +424,20 @@ int file_fd; regex_t r; /* FIXME: move from search_content and make static */ int flags = REG_EXTENDED|REG_NOSUB; + int ret_val = 0; fname = concat_dir_and_file (directory, filename); if (mc_stat (fname, &s) != 0 || !S_ISREG (s.st_mode)){ g_free (fname); - return; + return 0; } file_fd = mc_open (fname, O_RDONLY); g_free (fname); if (file_fd == -1) - return; + return 0; g_snprintf (buffer, sizeof (buffer), _("Grepping in %s"), name_trunc (filename, FIND2_X_USE)); @@ -454,6 +460,14 @@ int has_newline; char *p; int found = 0; + Gpm_Event event; + int c; + + if (resuming) { + resuming = 0; + line = last_line; + pos = last_pos; + } while ((p = get_line_at (file_fd, buffer, &pos, &n_read, sizeof (buffer), &has_newline))){ if (found == 0){ /* Search in binary line once */ @@ -469,11 +483,35 @@ found = 0; } g_free (p); + + if ((line & 0x3f) == 0) { + c = get_event (&event, h->mouse_status == MOU_REPEAT, 0); + if (c != EV_NONE) { + dlg_process_event (h, c, &event); + if (h->ret_value == B_ENTER + || h->ret_value == B_CANCEL + || h->ret_value == B_AGAIN + || h->ret_value == B_PANELIZE) { + stop_idle (h); + ret_val = 1; + break; + } + if (!h->send_idle_msg) { + resuming = 1; + last_line = line; + last_pos = pos; + ret_val = 1; + break; + } + } + } + } regfree (&r); } disable_interrupt_key (); mc_close (file_fd); + return ret_val; } static int @@ -569,9 +607,12 @@ } if (regexp_match (find_pattern, dp->d_name, match_file)){ - if (content_pattern) - search_content (h, directory, dp->d_name); - else + if (content_pattern) { + if (search_content (h, directory, dp->d_name)) { + g_free (tmp_name); + return 1; + } + } else find_add_match (h, directory, dp->d_name); } @@ -815,6 +856,7 @@ static int run_process (void) { + resuming = 0; set_idle_proc (find_dlg, 1); run_dlg (find_dlg); return find_dlg->ret_value; diff -urN vanilla/mc-4.5.99a/src/view.c mc-4.5.99a/src/view.c --- vanilla/mc-4.5.99a/src/view.c Thu Nov 15 00:20:38 2001 +++ mc-4.5.99a/src/view.c Thu Feb 14 11:54:48 2002 @@ -424,6 +424,56 @@ return 0; } +#define READ_PAGE_SIZE 32768 +ssize_t +mc_read_interruptible (WView *view) +{ + int w = view->widget.cols - view->have_frame + 1; + int fd = view->file; + void *buf = view->data; + size_t count = view->s.st_size; + ssize_t to_read, res; + ssize_t total = 0; + Dlg_head *d = 0; + Gpm_Event event; + int c; + + got_interrupt (); + enable_interrupt_key (); + + if (verbose) { + d = message (D_INSERT, _(" View "), _("Readingz %s"), view->filename); + mc_refresh (); + } + + while (count) { + to_read = count > READ_PAGE_SIZE ? READ_PAGE_SIZE : count; + res = mc_read(fd, buf, to_read); + total += res; + if (res != to_read) + break; + if (got_interrupt ()) + break; + event.x = -1; + if (verbose) { + view_percent (view, total, w, TRUE); + mc_refresh (); + c = get_event (&event, 0, 0); + if (c != EV_NONE) { + dlg_process_event (d, c, &event); + if (d->ret_value == B_CANCEL) + break; + } + } + buf += to_read; + count -= to_read; + } + disable_interrupt_key (); + dlg_run_done (d); + destroy_dlg (d); + return total; +} + /* return values: NULL for success, else points to error message */ static char * init_growing_view (WView *view, char *name, char *filename) @@ -491,7 +541,7 @@ view->data = (unsigned char*) g_malloc (view->s.st_size); if (view->data == NULL || mc_lseek(view->file,0,0) != 0 - || mc_read(view->file, view->data, view->s.st_size) != view->s.st_size){ + || mc_read_interruptible(view) != view->s.st_size){ if (view->data != NULL) g_free (view->data); close_view_file (view); @@ -1449,6 +1499,8 @@ int found_len, search_start; int search_status; Dlg_head *d = 0; + Gpm_Event event; + int c; /* Used to keep track of where the line starts, when looking forward */ /* is the index before transfering the line; the reverse case uses */ @@ -1456,8 +1508,10 @@ long forward_line_start; long reverse_line_start; long t; + /* Clear interrupt status */ got_interrupt (); + enable_interrupt_key (); if (verbose){ d = message (D_INSERT, _(" Search "), _("Searching %s"), text); @@ -1487,12 +1541,19 @@ } if (got_interrupt ()) break; + if (verbose) { + event.x = -1; + c = get_event (&event, 0, 0); + if (c != EV_NONE) { + dlg_process_event (d, c, &event); + if (d->ret_value == B_CANCEL) + break; + } + } } forward_line_start = p; - disable_interrupt_key (); s = get_line_at (view, &p, &t); reverse_line_start = p; - enable_interrupt_key (); if (!s) break; @@ -1552,6 +1613,8 @@ int w = view->widget.cols - view->have_frame + 1; char *d = buffer, b; + int lookup[256]; + int i, step; unsigned long e; /* clear interrupt status */ @@ -1561,8 +1624,15 @@ search_update_steps (view); update_activate = 0; + + for (i = 0; i < 256; i++) + lookup[i] = len; + for (i = len-1; i >= 0; i--, d++) + lookup[(unsigned char)*d] = i; + + d = buffer; - while (e < view->last_byte){ + while (e+len-1 < view->last_byte){ if (e >= update_activate){ update_activate += update_steps; if (verbose){ @@ -1572,18 +1642,24 @@ if (got_interrupt ()) break; } - b = get_byte (view, e++); - - if (*d == b){ - d++; - if (d - buffer == len){ - disable_interrupt_key (); - return e - len; - } - } else { - e -= d - buffer; + + b = get_byte(view, e+len-1); + step = lookup[(unsigned char)b]; + + if (step == 0) { d = buffer; + while (1) { + b = get_byte (view, e++); + if (*d != b) break; + d++; + if (d - buffer == len) { + disable_interrupt_key (); + return e - len; + } + } + step = 1; } + e += step; } disable_interrupt_key (); return -1; From sav at it.efp.com.ua Fri Feb 15 12:18:13 2002 From: sav at it.efp.com.ua (Andrew V. Samoilov) Date: Fri, 15 Feb 2002 14:18:13 +0200 Subject: mc.1 translated in Russian Message-ID: <3C6CFC85.8070309@it.efp.com.ua> Hello, Pavel! I converted and fixed/translated a half of binary mc.hlp.ru (by Victor Kostromin ) to nroff mandoc format. I plan to finish this work in february, and where to put this file is a good questions. Possible places are doc/mc.1.ru.in or doc/ru/mc.1.in. Regards, Andrew. From MRossi at system-group.it Fri Feb 15 12:41:14 2002 From: MRossi at system-group.it (Rossi Maurizio) Date: Fri, 15 Feb 2002 13:41:14 +0100 Subject: Patch for QNX Neutrino (sorry for typo error). Message-ID: <001101c1b61e$121dc6e0$aa02000a@mrossi> Hello. I would suggest a patch for Midnight Commander when compiled on QNX Neutrino (aka Realtime Platform). In function "canonicalize_pathname()" contained in file "src/ultilunix.c" please change: #if defined(__QNX__) with #if defined(__QNX__) && !defined(__QNXNTO__) This is required because the native QNX Neutrino peer-to-peer networking (Qnet) differ from QNX4 (Fleet) i.e. nodes are not prefixed with "//[nid]". Best regards. Maurizio Rossi System S.p.A. mrossi at system-group.it From proski at gnu.org Sat Feb 16 03:47:02 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 15 Feb 2002 22:47:02 -0500 (EST) Subject: mc.1 translated in Russian In-Reply-To: <3C6CFC85.8070309@it.efp.com.ua> Message-ID: Hi, Andrew! > I converted and fixed/translated a half of binary mc.hlp.ru > (by Victor Kostromin ) > to nroff mandoc format. Great! > I plan to finish this work in february, > and where to put this file is a good questions. > > Possible places are doc/mc.1.ru.in > or doc/ru/mc.1.in. doc/ru/mc.1.in is better. Actually, I think that the manuals should not be processed by configure to substitute current paths. Instead, the manual should be universal and should explain how to find out where the files are installed. But doc/ru/mc.1.in is a good start. Let me sort out automake problems if you have any. By the way, it would be nice if you applied your script to the Hungarian translation as well - it is already on CVS (lib/mc.hlp.hu). -- Regards, Pavel Roskin From proski at gnu.org Sat Feb 16 03:56:17 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 15 Feb 2002 22:56:17 -0500 (EST) Subject: Patch for QNX Neutrino (sorry for typo error). In-Reply-To: <001101c1b61e$121dc6e0$aa02000a@mrossi> Message-ID: Hi, Maurizio! > I would suggest a patch for Midnight Commander when compiled on QNX Neutrino > (aka Realtime Platform). > In function "canonicalize_pathname()" contained in file "src/ultilunix.c" > please change: > > #if defined(__QNX__) > > with > > #if defined(__QNX__) && !defined(__QNXNTO__) > > This is required because the native QNX Neutrino peer-to-peer networking > (Qnet) differ from QNX4 (Fleet) i.e. nodes are not prefixed with "//[nid]". I don't know anything about peer-to-peer networking on QNX Neutrino, so I left this code just in case, assuming that it would be harmless on all versions of QNX. But if you have problems, I would like to know more. Could you please describe the problem that your patch is supposed to fix? -- Regards, Pavel Roskin From proski at gnu.org Sat Feb 16 04:15:14 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 15 Feb 2002 23:15:14 -0500 (EST) Subject: suggestions In-Reply-To: <20020213093234.GA4679@oskar> Message-ID: Hi, Oskar! > > This means that every time you enter a zip archive an view > > files in it, the archive is modified! This should also be true > > for all other archives supported via extfs. > > Correction: It does happen when you view files with an ".html" > extension. The effect may be the same with other filetypes > as well. But regular text files files without extension are > not copied back into the archive! I confirm this bug with the CVS version of MC. It's a serious problem. It seems to be a bug either in the extfs implementation or in exec_extension() (src/ext.c). -- Regards, Pavel Roskin From despair at sama.ru Sun Feb 17 02:27:37 2002 From: despair at sama.ru (Walery Studennikov) Date: Sat, 16 Feb 2002 21:27:37 -0500 Subject: New version on mc-multiscreen-patch Message-ID: <20020216212737.A513@localhost.localdomain> Andrew V. Samoilov wrote: > Don't hardcode debug filename in log_mc_handler. > It can be new mc option. > Use vfs_file_is_local() to determine file location > in edit/editwidget.c:edit(). It will be best if somebody > rewrite edit engine to use dir properly. It might be > set to mc_return_cwd() if directory is NULL and filename > is not absolute. It is not good idea to always concat > dir and file - resulted filename may confuse users. > PATH_SEP and PATH_SEP_STR have to be used instead of '/' > and "/". Well, it seems to be fixed too : * configure.in: Add --with-logfile=path_to_logfile option * main.c (log_mc_handler): Use MC_DEBUG_LOG_FILE insted of hardcoded debug filename * edit/editwidget.c (edit): Use vfs_file_is_local() instead heuristics, Use PATH_SEP and PATH_SEP_STR insted of '/' and "/" respectively http://www.sama.ru/~despair/mc/mc-multiscreen-0.7.3.patch.tar.gz -- Regards, Walery From avarakin00 at hotmail.com Mon Feb 18 19:42:21 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Mon, 18 Feb 2002 14:42:21 -0500 Subject: Include glib into mc distribution? References: <20020216212737.A513@localhost.localdomain> Message-ID: Hi, I think it would be great if glib will be included as part of mc, and will be statically linked with glib. That will greatly simplify building and deployment of mc. What do you think about that? Alex From proski at gnu.org Mon Feb 18 21:51:20 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 18 Feb 2002 16:51:20 -0500 (EST) Subject: Patch for QNX Neutrino (sorry for typo error). In-Reply-To: <000901c1b89d$58e71500$aa02000a@mrossi> Message-ID: Hi, Rossi! > in "canonicalize_pathname()" there are some statements compiled ONLY when > the system is QNX i.e. #if defined(__QNX__). > So the "canonicalize_pathname()" does something very special ONLY if > compiled for QNX. > > #if defined(__QNX__) Only if compiled on QNX or QNX Neutrino, which are different systems. Do you think that I'm not looking at the code I'm writing about? Maybe I wasn't clear, but why assume that I'm speculating about something I haven't seen? canonicalize_pathname() does the same thing on QNX and QNX Neutrino. It loops on one of them (QNX Neutrino). You are assuming that the code would not loop on QNX. I'm saying that there is nothing that would make canonicalize_pathname() work differently on QNX and QNX Neutrino. You are showing me the code that demonstrates exactly that, while pretending that you are disproving my words. I'm not going to discuss it privately. If you want to use my time, it's fair that you take the risk of your errors being exposed to the list subscribers. I'm aware of the problem and will try to fix it. -- Regards, Pavel Roskin From proski at gnu.org Mon Feb 18 22:38:27 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 18 Feb 2002 17:38:27 -0500 (EST) Subject: Patch for QNX Neutrino (sorry for typo error). In-Reply-To: Message-ID: Hi, Maurizio! Sorry for confusing your first and last names in the previous message :-( > I'm aware of the problem and will try to fix it. Done. canonicalize_pathname() wasn't checking that the second character is also '/' while checking for Qnet names. That's why '/x86' was wrongly considered a Qnet name. The loop happened when canonicalizing '/x86/..' This bug has been in MC for years, and nobody has reported it so far. I also disabled detection of Qnet names under QNX Neutrino as you suggested. -- Regards, Pavel Roskin From lists at pervalidus.net Tue Feb 19 19:47:33 2002 From: lists at pervalidus.net (=?iso-8859-1?B?RnLpZOlyaWMgTC4gVy4=?= Meunier) Date: Tue, 19 Feb 2002 16:47:33 -0300 Subject: Include glib into mc distribution? Message-ID: <20020219194733.GB166@pervalidus> Alexander Varakin wrote: > I think it would be great if glib will be included as part of > mc, and will be statically linked with glib. You can always compile GLib with --disable-shared or link Midnight Commander with the static version. For some unknown reason Slackware does that. Maybe because it doesn't support dependencies. > That will greatly simplify building and deployment of mc. How ? > What do you think about that? I don't like it. Other developers include copies of Readline and other libraries, which I also consider a bad idea. -- 0 at pervalidus.{net, dyndns.org} From proski at gnu.org Tue Feb 19 20:05:46 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 19 Feb 2002 15:05:46 -0500 (EST) Subject: Include glib into mc distribution? In-Reply-To: Message-ID: Hello, Alexander! > I think it would be great if glib will be included as part of mc, and will > be statically linked with glib. > That will greatly simplify building and deployment of mc. > What do you think about that? Sorry, I don't understand from the above if you are talking about sources or the binaries. What kind of problems do you have because glib is not included? -- Regards, Pavel Roskin From proski at gnu.org Tue Feb 19 21:32:12 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 19 Feb 2002 16:32:12 -0500 (EST) Subject: suggestions In-Reply-To: Message-ID: Hello! > > > This means that every time you enter a zip archive an view > > > files in it, the archive is modified! This should also be true > > > for all other archives supported via extfs. > > > > Correction: It does happen when you view files with an ".html" > > extension. The effect may be the same with other filetypes > > as well. But regular text files files without extension are > > not copied back into the archive! > > I confirm this bug with the CVS version of MC. It's a serious problem. > It seems to be a bug either in the extfs implementation or in > exec_extension() (src/ext.c). The problem is specific to extfs. extfs_ungetlocalcopy() opens the file with O_WRONLY flag, but extfs_open() thinks that the file should be marked as changed just because of that. In fact, extfs_ungetlocalcopy() only honors the "has_changed" flag in the code marked as "Should not happen" !!! I believe that both functions are wrong. The file should be marked as changed only is in was created, not if because it was opened for writing. On the other hand, extfs_ungetlocalcopy() should open the file for reading (i.e. not for writing), but has_changed should be set in the file flags if it's set in the argument. ============================== --- ChangeLog +++ ChangeLog @@ -1 +1,10 @@ +2002-02-19 Pavel Roskin + + * extfs.c (extfs_open): Only create a new entry if it has not + been found and O_CREAT is set. Consider file as changed only + if it has been successfully created. + (extfs_getlocalcopy): Open file only for reading. This prevents + marking file as changed. Actually use the has_changed argument. + Reported by Nerijus Baliunas + 2002-02-12 Pavel Roskin --- extfs.c +++ extfs.c @@ -607,11 +607,16 @@ static void *extfs_open (vfs *me, char * char *mc_extfsdir; struct entry *entry; int local_handle; - const int do_create = (flags & O_ACCMODE) != O_RDONLY; + int created = 0; if ((q = get_path_mangle (file, &archive, 0, 0)) == NULL) return NULL; - entry = find_entry (archive->root_entry, q, 0, do_create); + entry = find_entry (archive->root_entry, q, 0, 0); + if (entry == NULL && (flags & O_CREAT)) { + /* Create new entry */ + entry = find_entry (archive->root_entry, q, 0, 1); + created = (entry != NULL); + } if (entry == NULL) return NULL; if ((entry = my_resolve_symlinks (entry)) == NULL) @@ -642,7 +647,7 @@ static void *extfs_open (vfs *me, char * g_free (q); g_free (mc_extfsdir); g_free (archive_name); - if (my_system (EXECUTE_AS_SHELL | EXECUTE_SETUID | EXECUTE_WAIT, shell, cmd) && !do_create){ + if (my_system (EXECUTE_AS_SHELL | EXECUTE_SETUID | EXECUTE_WAIT, shell, cmd) && !created){ free (entry->inode->local_filename); entry->inode->local_filename = NULL; g_free (cmd); @@ -658,7 +663,7 @@ static void *extfs_open (vfs *me, char * extfs_info = g_new (struct pseudofile, 1); extfs_info->archive = archive; extfs_info->entry = entry; - extfs_info->has_changed = do_create; + extfs_info->has_changed = created; extfs_info->local_handle = local_handle; /* i.e. we had no open files and now we have one */ @@ -1308,12 +1313,13 @@ static char *extfs_getlocalcopy (vfs *me static int extfs_ungetlocalcopy (vfs *me, char *path, char *local, int has_changed) { struct pseudofile *fp = - (struct pseudofile *) extfs_open (me, path, O_WRONLY, 0); + (struct pseudofile *) extfs_open (me, path, O_RDONLY, 0); if (fp == NULL) return 0; if (!strcmp (fp->entry->inode->local_filename, local)) { fp->archive->fd_usage--; + fp->has_changed |= has_changed; extfs_close ((void *) fp); return 0; } else { ============================== -- Regards, Pavel Roskin From avarakin00 at hotmail.com Wed Feb 20 01:54:51 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Tue, 19 Feb 2002 20:54:51 -0500 Subject: Include glib into mc distribution? References: Message-ID: Hi, Let me exlain my point. I am working on quite a few Unix machines: AIX, HP, Solaris. Some of them are here in NJ, some in TX. I never met the sysadmin in TX, the sysadmin here in NJ is also the head of local IS departmemt which means he is a very busy person. I don't have root access to any of those machines. If I want to install mc on any of those machines using binaries which I downloaded from the inetrnet I have to ask a sysadmin to install THREE packages - mc, glib and libintl. You can imagine what they say if I would ask them to do so! But I am sure I could convince them to install just ONE package - mc, which includes all packages. So my only option is to build all myself , which is again a hassle - I have to build all three packages in my home directory instead of just one. I am sure there are many people around in similar situation and many just give up on using mc. Thanks, Alex ----- Original Message ----- From: "Pavel Roskin" To: "Alexander Varakin" Cc: Sent: Tuesday, February 19, 2002 3:05 PM Subject: Re: Include glib into mc distribution? > Hello, Alexander! > > > I think it would be great if glib will be included as part of mc, and will > > be statically linked with glib. > > That will greatly simplify building and deployment of mc. > > What do you think about that? > > Sorry, I don't understand from the above if you are talking about sources > or the binaries. > > What kind of problems do you have because glib is not included? > > -- > Regards, > Pavel Roskin > > _______________________________________________ > Mc-devel mailing list > Mc-devel at gnome.org > http://mail.gnome.org/mailman/listinfo/mc-devel > From proski at gnu.org Wed Feb 20 02:56:16 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 19 Feb 2002 21:56:16 -0500 (EST) Subject: Include glib into mc distribution? In-Reply-To: Message-ID: Hello! > If I want to install mc on any of those machines using binaries which I > downloaded from the inetrnet I have to ask a sysadmin to install THREE > packages - mc, glib and libintl. Well, in this case you are talking about binaries. The problem is, I have no influence on the package builders. I can also imagine that they have more that one project using glib and libintl. I think that good sysadmins will rather install 3 packages in the native format and made by teams who are experienced in making packages for that OS rather than a binary tarball from any single person, even the maintainer of the package. > You can imagine what they say if I would ask them to do so! I really don't see any difference between installing one package and instaling 3 packages. > But I am sure I could convince them to install just ONE package - mc, which > includes all packages. I'm not sure. > So my only option is to build all myself , which is again a hassle - I have > to build all three packages in my home directory instead of just one. > I am sure there are many people around in similar situation and many just > give up on using mc. You don't have to build gettext unless you really want translated messages. Regarding glib, I consider making a separate source distribution for those who don't want to install glib. Another option would be to use compiled but not installed glib to compile mc. I'll think about it. -- Regards, Pavel Roskin From avarakin00 at hotmail.com Wed Feb 20 03:33:23 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Tue, 19 Feb 2002 22:33:23 -0500 Subject: Include glib into mc distribution? References: Message-ID: Hi, > > You can imagine what they say if I would ask them to do so! > > I really don't see any difference between installing one package and > instaling 3 packages. Well, for my local sysadmin it will really make a difference - he is using sh for interactive shell and Windows notepad plus clipboard trick for editing command line :-) > Regarding glib, I consider making a separate source distribution for those > who don't want to install glib. Are you considering to include the headers and sources of glib into mc distribution? That would be great! Regards, Alex From nerijus at users.sourceforge.net Wed Feb 20 04:55:42 2002 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Wed, 20 Feb 2002 06:55:42 +0200 (EET) Subject: Include glib into mc distribution? In-Reply-To: References: Message-ID: On Tue, 19 Feb 2002 22:33:23 -0500 Alexander Varakin wrote: AV> Well, for my local sysadmin it will really make a difference - he is using AV> sh for interactive shell and Windows notepad plus clipboard trick for AV> editing command line :-) Probably :-( ;) AV> > Regarding glib, I consider making a separate source distribution for those AV> > who don't want to install glib. AV> AV> Are you considering to include the headers and sources of glib into mc AV> distribution? AV> That would be great! Why? Can't you just download it? I thought you were talking about binary distribution? Regards, Nerijus From kai at cmail.ru Wed Feb 20 11:51:18 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Wed, 20 Feb 2002 13:51:18 +0200 Subject: mc.1 translated in Russian References: Message-ID: <3C738DB6.104@cmail.ru> Hi, >>I converted and fixed/translated a half of binary mc.hlp.ru >>(by Victor Kostromin ) >>to nroff mandoc format. >> >>I plan to finish this work in february, >>and where to put this file is a good questions. >> I finished this work today and it will be uploaded as http://www.linux.zp.ua/mc/mc.1.ru.in.gz Also I plan to sent this manual page to Russian Team of Free Translation Project >> >>Possible places are doc/mc.1.ru.in >>or doc/ru/mc.1.in. >> > >doc/ru/mc.1.in is better. Actually, I think that the manuals should not >be processed by configure to substitute current paths. Instead, the >manual should be universal and should explain how to find out where the >files are installed. > mc.hlp.ru does it. > But doc/ru/mc.1.in is a good start. Let me sort out >automake problems if you have any. > I also like doc/ru/mc.1.in, but as far as I know patch can't create absent directory, so it will be hard to make patches. And I leave all of automake staff to you, sorry. Also %{var} macro and smbfs are not documented in mc.1.in but in mc.hlp.ru. history and hotlist files are not documented too. > >By the way, it would be nice if you applied your script to the Hungarian >translation as well - it is already on CVS (lib/mc.hlp.hu). > There is too many manual work. My sed script can't differ .PP, .IP and .TP. BTW man2hlp has some problems with cyrillic. Sometimes it eats whitespaces between words and does not split long lines. Regards, Andrew. From dmartina at excite.com Wed Feb 20 10:45:09 2002 From: dmartina at excite.com (David Martin) Date: Wed, 20 Feb 2002 05:45:09 -0500 (EST) Subject: Spanish translations updated Message-ID: <20020220104509.B4E1C8AF1F@xprdmailfe.excite.com> An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: es-4.5.99-5.po.bz2 Type: application/octet-stream Size: 25127 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: es_ES-4.5.99-5.po.bz2 Type: application/octet-stream Size: 25158 bytes Desc: not available URL: From proski at gnu.org Fri Feb 22 05:03:03 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 22 Feb 2002 00:03:03 -0500 (EST) Subject: Include glib into mc distribution? In-Reply-To: Message-ID: Hello! > > Regarding glib, I consider making a separate source distribution for those > > who don't want to install glib. > > Are you considering to include the headers and sources of glib into mc > distribution? > That would be great! Read my words again. "Separate distribution" means that it will be a separate bigger tarball especially for those who don't have glib and don't want to install it. And I'll make it only if I have time and there is enough interest from the users. You actually can do it yourself right now. It requires no coding, just some understanding of Autoconf, Automake and Libtool. Put glib to a subdir, make sure that "configure" and "make" know about it. Remove check for glib. Disable shared library support. Change makefiles to link mcserv and mc against the included glib. Test it. Pack it. -- Regards, Pavel Roskin From avarakin00 at hotmail.com Fri Feb 22 05:10:54 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Fri, 22 Feb 2002 00:10:54 -0500 Subject: Another Win32 port, this time for cygwin References: <20020220104509.B4E1C8AF1F@xprdmailfe.excite.com> Message-ID: Hi, I was able to build and somehow run the latest mc sources from CVS using cygwin. If somebody want to do the same, my environment is: 1. Win 2000 2. Cygwin : autoconf 2.52-5 automake 1.5a-1 bash 2.05a-2 binutils 20011002-1 cygwin 1.3.6-6 gcc 2.95.3-5 m4 0.0 make 3.79.1-5 3. CVS sources as of 2/21/2 4. GLIB 1.2.10 Problems and solutions: 1. Glib didn't compile, made a small fix: *** glib-1.2.10/gstrfuncs.c Tue Feb 27 01:00:22 2001 --- glib-1.2.10_old/gstrfuncs.c Mon Nov 5 21:50:44 2001 char *msg; ! extern char *strsignal (int sig); switch (signum) char *msg; ! // extern char *strsignal (int sig); switch (signum) Another problem with glib : the installer put glib.m4 into wrong place, manually copied it into right place. 2. While compiling libintl the libintl.def was missing, I just created a dummy one, which is containing just one line: EXPORTS Can it be fixed properly ? 3. Was having problems compiling zh_TW.po, must be GNU gettext installation problem, just removed all references to zh_TW from makefile . 4. libintl is compiled with -DGETTEXT_STATIC flag whereas the rest of the system without it, so I had zillions of link errors. Temporarily fixed it by adding -DGETTEXT_STATIC to CFLAGS of all makefiles 5. Had some more linking errors, found that some *.c files were missing in makefiles, added them manually. Looks like a general problem of the build system . Was able to link. It runs under bash, rxvt and xterm of XFree86. I liked how it runs under XFree86 xterm most of all. The problems are: 1. many problems related to regexp 2. subshell hangs very often Regards, Alex From avarakin00 at hotmail.com Fri Feb 22 05:47:40 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Fri, 22 Feb 2002 00:47:40 -0500 Subject: Include glib into mc distribution? References: Message-ID: Hello! > Read my words again. "Separate distribution" means that it will be a > separate bigger tarball especially for those who don't have glib and don't > want to install it. And I'll make it only if I have time and there is > enough interest from the users. I saw some posts in the net from users who were having problems because of the glib. Most of these users are not users anymore just because they were unable to build mc :-( I found the following example in the cygwin list: //////////////////////////////////////////////////////// I am trying to compile mc 4.5.55 with no luck. First, it complained I did not have glib so I tried to install that. However, glib complained I did not have pkgconfig. I downloaded the latest version of pkgconfig and I can't get that to install either. I read the instructions and typed "./configure" then "make" then "make install". I get a variety of errors and eventually, it does not work. //////////////////////////////////////////////////////// Apparently this guy is not mc user anymore... And he was having problem on machine with "root" access, forget about production machine with tyrant sysadmin. I also had a problem with glib - its installer put glib.m4 to a wrong place, it took me some time to figure out this problem. The size of glib is about 500K, which will be about 200K compressed, so the size it is not a problem since the mc distribution is about 3 Megs. We already have slang and gettext included and this is very good - people don't have hassles with them. Let's be consistent! Alex From proski at gnu.org Fri Feb 22 05:59:33 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 22 Feb 2002 00:59:33 -0500 (EST) Subject: mc.1 translated in Russian In-Reply-To: <3C738DB6.104@cmail.ru> Message-ID: Hi, > Also %{var} macro and smbfs are not documented in mc.1.in but in mc.hlp.ru. > history and hotlist files are not documented too. It is fine, but somehow the old text about mc.sh slipped into your translation. It is a very bad idea for an interactive program to ask the user to write a script. Users are not supposed to write scripts; in fact, they are not even supposed to read the manuals unless they are interested in details - the interface should be self-explanatory! On the technical side, the translated manual has "@prefix" without trailing "@" in two places. Please check your script. > >By the way, it would be nice if you applied your script to the Hungarian > >translation as well - it is already on CVS (lib/mc.hlp.hu). > > > There is too many manual work. My sed script can't differ .PP, .IP and .TP. Is it a limitation of the script or the information is actually lost in mc.hlp? Could you please send me the script? > BTW man2hlp has some problems with cyrillic. Sometimes it eats > whitespaces between words and does not split long lines. I found it immediately when I looked into the sources. /* Don't add control characters to the length */ if (c < 32) continue; c is "int", it gets the value from "char *buffer", char is signed by default, so it gets extended to negative integers. I've committed a patch - it's fixed now. Actually, man2hlp shows a real problem in the translation - empty .SH at the line 4016. By the way, where does "QueryBox" come from? There is no such word in the original manual. Also the translation overuses empty pairs of double quotes. Run this to see what I mean: grep '""' mc.1.ru.in -- Regards, Pavel Roskin From proski at gnu.org Fri Feb 22 06:27:44 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 22 Feb 2002 01:27:44 -0500 (EST) Subject: Include glib into mc distribution? In-Reply-To: Message-ID: > I saw some posts in the net from users who were having problems because of > the glib. Most of these users are not users anymore just because they were > unable to build mc :-( > I found the following example in the cygwin list: > //////////////////////////////////////////////////////// > I am trying to compile mc 4.5.55 with no luck. First, it complained I did > not have glib so I tried to install that. However, glib complained I did > not have pkgconfig. I downloaded the latest version of pkgconfig and I > can't get that to install either. I read the instructions and typed > "./configure" then "make" then "make install". I get a variety of errors > and eventually, it does not work. The documentation for mc 4.5.55 specifies clearly that it requires glib 1.2.x. That guy apparently took glib 1.3.x. In fact, the main reason why I don't want to switch to glib 1.3.x is because it requires pkgconfig and pkgconfig needs to be compiled by the end user. This message should be forwarded to glib developers - it's their problem. I have no time to rewrite pkgconfig in shell, but somebody should do it! I actually put 1.2.x everywhere where glib was mentioned in INSTALL and INSTALL.FAST. But I missed README. I'm fixing it in CVS now. > Apparently this guy is not mc user anymore... > And he was having problem on machine with "root" access, forget about > production machine with tyrant sysadmin. Sysadmins are supposed to install precompiled software from trusted sources or read the documentation before compiling. > I also had a problem with glib - its installer put glib.m4 to a wrong place, > it took me some time to figure out this problem. That's very interesting! You are mixing together things that are just inconvenient and things that are very wrong! When compliling an package that uses automake and the tarball was properly checked by "make distcheck" (I did it with 4.5.55), no files that are part of the distribution should be regenerated. Could you please provide more details about the failure? Can you still reproduce it? > The size of glib is about 500K, which will be about 200K compressed, so the > size it is not a problem since the mc distribution is about 3 Megs. > We already have slang and gettext included and this is very good - people > don't have hassles with them. > Let's be consistent! glib-1.2.10.tar.gz is 412k compressed. -- Regards, Pavel Roskin From kai at cmail.ru Fri Feb 22 08:23:26 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Fri, 22 Feb 2002 10:23:26 +0200 Subject: mc.1 translated in Russian References: Message-ID: <3C75FFFE.9000605@cmail.ru> Hello, >>Also %{var} macro and smbfs are not documented in mc.1.in but in mc.hlp.ru. >>history and hotlist files are not documented too. >> You were some harry to remove REDME.smbfs. I planed to rewrite it completely. > >It is fine, but somehow the old text about mc.sh slipped into your >translation. It is a very bad idea for an interactive program to ask the >user to write a script. Users are not supposed to write scripts; in fact, >they are not even supposed to read the manuals unless they are interested >in details - the interface should be self-explanatory! > Ok, I will sync russian translation with original mc.1.in. > >On the technical side, the translated manual has "@prefix" without >trailing "@" in two places. Please check your script. > This were my faults, my script don't do this. >>>By the way, it would be nice if you applied your script to the Hungarian >>>translation as well - it is already on CVS (lib/mc.hlp.hu). >>> >>There is too many manual work. My sed script can't differ .PP, .IP and .TP. >> > >Is it a limitation of the script or the information is actually lost in >mc.hlp? > I did not find solution in 5 minutes, so I did not investigate this issue carefuly. > Could you please send me the script? > Sure. But there are some known issues. It does not produce .\"LINK2 if link is splited. I know how to implement it, but I was too lazy to implement and test it for 3 or 4 cases, sorry. > >>BTW man2hlp has some problems with cyrillic. Sometimes it eats >>whitespaces between words and does not split long lines. >> > >I found it immediately when I looked into the sources. > > /* Don't add control characters to the length */ > if (c < 32) > continue; > >c is "int", it gets the value from "char *buffer", char is signed by >default, so it gets extended to negative integers. I've committed a patch >- it's fixed now. > Thanks! BTW as far as a know man2hlp was not designed to accept localized section headers, so I use .SH "Russian translation" .\"Original section header" in hope somebody else improve man2hlp.c. Another improvement is to eliminate perl. I understand it is standard now, but many host have not installed this package for some reasons yet. Yes, I know perl is used in uzip, and I belive this uzip is better than old shell script, but as for me it was one of the unpleasant acquirements of 4.5.52. Also xnc.hlp is completely binary file now, and it should be also converted into mandoc format. > > >Actually, man2hlp shows a real problem in the translation - empty .SH at >the line 4016. > FIxed. > > >By the way, where does "QueryBox" come from? There is no such word in the >original manual. > It came from mc.1.hlp.ru. > > >Also the translation overuses empty pairs of double quotes. Run this to >see what I mean: > >grep '""' mc.1.ru.in > grep '""' mc.1.in also outputs 4 empty .SH entries. BTW, I am not familiar with mandoc, so I don't know how to incorporate '"' in section header in other way. Also I don't know how to eliminate additional spaces for cases like some text ( .I option ) I need something like .BR, .BI, IR family from mm. Regards, Andrew. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: hlp2mandoc.sed URL: From kai at cmail.ru Fri Feb 22 14:55:14 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Fri, 22 Feb 2002 16:55:14 +0200 Subject: mc.1 translated in Russian References: <3C75FFFE.9000605@cmail.ru> Message-ID: <3C765BD2.7090507@cmail.ru> Hello, >>>> By the way, it would be nice if you applied your script to the >>>> Hungarian translation as well - it is already on CVS (lib/mc.hlp.hu). >>>> >>> There is too many manual work. My sed script can't differ .PP, .IP >>> and .TP. >>> >> >> Is it a limitation of the script or the information is actually lost >> in mc.hlp? >> > I did not find solution in 5 minutes, so I did not investigate this > issue carefuly. I can't imagine how to understand what "-C args" Some text... is .TP .I "\-C args" Some text... but not simple .PP .I "\-C args" Some text... > >> Could you please send me the script? >> > Sure. But there are some known issues. It does not produce .\"LINK2 > if link is splited. > I know how to implement it, but I was too lazy to implement and test > it for 3 or 4 cases, sorry. Also `-' must be espaped for .I >> >> By the way, where does "QueryBox" come from? There is no such word >> in the original manual. >> It came from xnc.hlp. >> >> Also the translation overuses empty pairs of double quotes. Run this >> to see what I mean: >> >> grep '""' mc.1.ru.in >> > grep '""' mc.1.in also outputs 4 empty .SH entries. Well, after generating mc.hlp.ru I understand what you means. I think some of these "" can be replaced with '. > > I need something like .BR, .BI, IR family from mm. > Well, I found .BR, .IR in mandoc, but as far as I remember they were absent in SCO man package. Also these constractions are not supported by man2hlp. Regards, Andrew. From oskar at osk.mine.nu Fri Feb 22 22:57:57 2002 From: oskar at osk.mine.nu (Oskar Liljeblad) Date: Fri, 22 Feb 2002 23:57:57 +0100 Subject: diff filesystem Message-ID: <20020222225757.GA4126@oskar> I got tired of waiting when browsing kernel patch files using the patchfs in mc, so wrote this patch. It adds a new vfs called difffs (with prefix udiff), replacing the patchfs bash script in extfs. The main (and only) difference is that read a file in the diff takes O(1) worst case, compared to O(n) worst case (n = size of the whole diff file) in patchfs. (The kernel 2.5.5 5MB patch takes 3-4 seconds to load, and waiting that long every time you want to view a single file inside it is unacceptable.) This patch is against the 2002-02-22-06 snapshot. This patch does not replace patchfs with udiff in the default configuration files. Much of this patch was copied from tar.c, so I consider the copyright owner to be same as for that file. Let me know what you decide to do with this patch. Oskar Liljeblad (oskar at osk.mine.nu) -------------- next part -------------- diff -ruN mc-4.5.99a/vfs/Makefile.am mc-4.5.99a-oskar/vfs/Makefile.am --- mc-4.5.99a/vfs/Makefile.am Wed Feb 20 07:15:00 2002 +++ mc-4.5.99a-oskar/vfs/Makefile.am Fri Feb 22 23:04:46 2002 @@ -13,6 +13,7 @@ local.c \ names.c \ tar.c \ + diff.c \ sfs.c \ vfs.c diff -ruN mc-4.5.99a/vfs/diff.c mc-4.5.99a-oskar/vfs/diff.c --- mc-4.5.99a/vfs/diff.c Thu Jan 1 01:00:00 1970 +++ mc-4.5.99a-oskar/vfs/diff.c Fri Feb 22 23:06:27 2002 @@ -0,0 +1,438 @@ +/* Virtual File System: Diff file system. + Copyright (C) 1995 The Free Software Foundation + + Written by: 2002 Oskar Liljeblad + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU Library General Public License + as published by the Free Software Foundation; either version 2 of + the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU Library General Public License for more details. + + You should have received a copy of the GNU Library General Public + License along with this program; if not, write to the Free Software + Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ + +/* Namespace: vfs_difffs_ops */ + +#include +#include +#include "utilvfs.h" /* for message_2s, message_1s */ +#include "xdirentry.h" +#include "../src/dialog.h" /* for MSG_ERROR */ +#include + +#define MIN_CHUNK 64 +#define READBUFSIZE 32768 + +struct readbuf { + int fd; + char *buf; + size_t pos; + size_t len; +}; + +static void *diff_super_check(vfs *me, char *archive_name, char *op) +{ + static struct stat stat_buf; + if (mc_stat(archive_name, &stat_buf)) + return NULL; + return &stat_buf; +} + +static int diff_super_same(vfs *me, struct vfs_s_super *parc, char *archive_name, char *op, void *cookie) +{ + struct stat *archive_stat = cookie; /* stat of main archive */ + + if (strcmp(parc->name, archive_name) != 0) + return 0; + + if (vfs_uid && (!(archive_stat->st_mode & 0004)) + && ((archive_stat->st_gid != vfs_gid) || !(archive_stat->st_mode & 0040)) + && ((archive_stat->st_uid != vfs_uid) || !(archive_stat->st_mode & 0400))) + return 0; + + /* Has the cached archive been changed on the disk? */ + if (parc->u.tar.tarstat.st_mtime < archive_stat->st_mtime) { /* Yes, reload! */ + (*vfs_tarfs_ops.free)((vfsid) parc); + vfs_rmstamp (&vfs_tarfs_ops, (vfsid) parc, 0); + return 2; + } + + /* Hasn't been modified, give it a new timeout */ + vfs_stamp (&vfs_tarfs_ops, (vfsid) parc); + return 1; +} + +static int diff_fh_open(vfs *me, vfs_s_fh *fh, int flags, int mode) +{ + if ((flags & O_ACCMODE) != O_RDONLY) + ERRNOR (EROFS, -1); + return 0; +} + +static void diff_free_archive(vfs *me, vfs_s_super *archive) +{ + if (archive->u.tar.fd != -1) + mc_close(archive->u.tar.fd); + if (archive->u.diff.list_fd != -1) + close(archive->u.diff.list_fd); + if (archive->u.diff.list_name != NULL) { + unlink(archive->u.diff.list_name); /* ignore error? */ + g_free(archive->u.diff.list_name); + } +} + +static int diff_read(void *fh, char *buffer, int count) +{ + off_t begin = FH->ino->u.tar.data_offset; + int fd = FH_SUPER->u.tar.fd; + vfs *me = FH_SUPER->me; + + if (begin == -2) { + if (lseek(FH_SUPER->u.diff.list_fd, FH->pos, SEEK_SET) < 0) + ERRNOR(errno, -1); + if ((count = read(FH_SUPER->u.diff.list_fd, buffer, count)) < 0) + ERRNOR(errno, -1); + FH->pos += count; + return count; + } + + if (mc_lseek(fd, begin + FH->pos, SEEK_SET) != begin + FH->pos) + ERRNOR(EIO, -1); + + count = MIN(count, FH->ino->st.st_size - FH->pos); + + if ((count = mc_read(fd, buffer, count)) == -1) + ERRNOR(errno, -1); + + FH->pos += count; + return count; +} + +static int diff_ungetlocalcopy (vfs *me, char *path, char *local, int has_changed) +{ + /* We do just nothing. (We are read only and do not need to free local, + * since it will be freed when diff archive will be freed + * We have to report error if file has changed. + */ + ERRNOR(EROFS, -has_changed); +} + +static void rb_free(struct readbuf *rb) +{ + g_free(rb->buf); +} + +static void rb_init(struct readbuf *rb, int fd) +{ + rb->fd = fd; + rb->len = 0; + rb->pos = 0; + rb->buf = g_malloc(READBUFSIZE); +} + +static ssize_t rb_readchar(struct readbuf *rb, char *buf) +{ + if (rb->pos >= rb->len) { + rb->len = 0; + do { + int rc = mc_read(rb->fd, rb->buf+rb->len, READBUFSIZE-rb->len); + if (rc < 0) + return rc; + if (rc == 0) { + if (rb->len == 0) + return 0; + break; + } + rb->len += rc; + } while (rb->len < READBUFSIZE); + rb->pos = 0; + } + *buf = rb->buf[rb->pos++]; + return 1; +} + +static ssize_t rb_getdelim(struct readbuf *rb, char **lineptr, size_t *n, int delim) +{ + int nchars_avail; + char *read_pos; + + if (!*lineptr) { + *n = MIN_CHUNK; + *lineptr = g_malloc(*n); + } + nchars_avail = *n; + read_pos = *lineptr; + + for (;;) { + char c; + int rc; + + rc = rb_readchar(rb, &c); + + if (nchars_avail < 2) { + if (*n > MIN_CHUNK) + *n *= 2; + else + *n += MIN_CHUNK; + nchars_avail = *n + *lineptr - read_pos; + *lineptr = g_realloc (*lineptr, *n); + read_pos = *n - nchars_avail + *lineptr; + } + + if (rc < 0) + return -1; + if (rc == 0) { + if (read_pos == *lineptr) + return 0; + break; + } + + *read_pos++ = c; + nchars_avail--; + + if (c == delim) + break; + } + + *read_pos = 0; + return read_pos - (*lineptr); +} + +static int diff_open_archive(vfs *me, vfs_s_super *archive, char *name, char *op) +{ + int diff_fd, list_fd, type, result; + long size, list_size = 0; + long offset; + mode_t mode; + struct vfs_s_inode *root; + struct stat std_st; + struct readbuf rb; + char *linebuf = NULL; + size_t linesize = 0; + ssize_t start_offset = -1; + struct vfs_s_inode *parent = NULL; + char *filename = NULL; + struct vfs_s_entry *entry; + struct vfs_s_inode *inode; + + diff_fd = mc_open(name, O_RDONLY); + if (diff_fd == -1) { + message_3s(1, MSG_ERROR, _("Cannot open \"%s\"\n%s"), name, g_strerror(mc_errno)); + ERRNOR(ENOENT, -1); + } + + archive->name = g_strdup(name); + mc_stat(name, &(archive->u.tar.tarstat)); + archive->u.tar.fd = -1; + + /* Find out the method to handle this diff file */ + size = is_gunzipable(diff_fd, &type); + mc_lseek(diff_fd, 0, SEEK_SET); + if (size > 0) { + char *s; + mc_close(diff_fd); + s = g_strconcat(archive->name, decompress_extension(type), NULL ); + diff_fd = mc_open(s, O_RDONLY); + if (diff_fd == -1) + message_3s(1, MSG_ERROR, _("Cannot open \"%s\"\n%s"), s, g_strerror(mc_errno)); + g_free(s); + if (diff_fd == -1) + ERRNOR(ENOENT, -1); + } + + archive->u.tar.fd = diff_fd; + mode = archive->u.tar.tarstat.st_mode & 07777; + if (mode & 0400) mode |= 0100; + if (mode & 0040) mode |= 0010; + if (mode & 0004) mode |= 0001; + mode |= S_IFDIR; + + root = vfs_s_new_inode (me, archive, &archive->u.tar.tarstat); + root->st.st_mode = mode; + root->u.tar.data_offset = -1; + root->st.st_nlink++; + root->st.st_dev = MEDATA->rdev++; + vfs_s_add_dots(me, root, NULL); + archive->root = root; + + std_st.st_mode = 0444 | S_IFREG; + std_st.st_uid = 0; + std_st.st_gid = 0; + std_st.st_rdev = 0; + std_st.st_ctime = time(NULL); /* ignore errors */ + std_st.st_atime = std_st.st_ctime; + std_st.st_mtime = std_st.st_ctime; + + /* Create temporary file for FILELIST */ + list_fd = mc_mkstemps(&archive->u.diff.list_name, "sfs", NULL); + if (list_fd == -1) { + message_1s(1, MSG_ERROR, _("Cannot create temporary file")); + return -1; /* handle better? */ + } + archive->u.diff.list_fd = list_fd; + + rb_init(&rb, diff_fd); + offset = 0; + result = -1; + + for (;;) { + ssize_t linelen; + + linelen = rb_getdelim(&rb, &linebuf, &linesize, '\n'); + if (linelen < 0) { + me->verrno = errno; + break; + } + offset += linelen; + + if (linelen == 0 || strncmp(linebuf, "diff ", 5) == 0) { + char *q; + int c; + + if (start_offset != -1) { + std_st.st_size = offset - start_offset - linelen; + + inode = vfs_s_new_inode(me, archive, &std_st); + inode->u.tar.data_offset = start_offset; + + entry = vfs_s_new_entry(me, filename, inode); + vfs_s_insert_entry(me, parent, entry); + g_free(filename); + filename = NULL; + } + if (linelen == 0) { + result = 0; + break; + } + + start_offset = offset - linelen; + + for (c = linelen-1; isspace(linebuf[c]); c--); + linebuf[c+1] = 0; + + q = strrchr(linebuf, ' '); + if (q == NULL) { + message_1s(1, MSG_ERROR, _("Inconsistent diff file")); + break; + } + + write(list_fd, q+1, linebuf + c - q); + write(list_fd, "\n", 1); + list_size += linebuf + c - q + 1; + + filename = strrchr(q+1, '/'); + if (filename == NULL) { + filename = q+1; + q = linebuf+linelen; /* "" */ + } else { + *(filename++) = 0; + q = q+1; + } + + filename = g_strdup(filename); + + parent = vfs_s_find_inode(me, archive->root, q, LINK_NO_FOLLOW, FL_MKDIR); + if (parent == NULL) { + message_1s(1, MSG_ERROR, _("Inconsistent diff file")); + break; + } + } + } + + std_st.st_size = list_size; + inode = vfs_s_new_inode(me, archive, &std_st); + /* -2 is the magic code that identifies this special file */ + inode->u.tar.data_offset = -2; + entry = vfs_s_new_entry(me, "FILELIST", inode); + vfs_s_insert_entry(me, root, entry); + + rb_free(&rb); + g_free(filename); + g_free(linebuf); + return result; +} + +static struct vfs_s_data diff_data = { + NULL, /* supers */ + 0, /* inode_counter */ + 0, /* rdev */ + NULL, /* logfile */ + + NULL, /* init_inode */ + NULL, /* free_inode */ + NULL, /* init_entry */ + + diff_super_check, /* archive_check */ + diff_super_same, /* archive_same */ + diff_open_archive, + diff_free_archive, + + diff_fh_open, + NULL, /* fh_close */ + + vfs_s_find_entry_tree, + NULL, /* dir_load */ + NULL /* file_store */ +}; + +vfs vfs_difffs_ops = { + NULL, /* next */ + "difffs", + 0, /* flags */ + "udiff", + &diff_data, + 0, /* errno */ + NULL, /* init */ + NULL, /* done */ + vfs_s_fill_names, + NULL, /* which */ + + vfs_s_open, + vfs_s_close, + diff_read, + NULL, /* write */ + + vfs_s_opendir, + vfs_s_readdir, + vfs_s_closedir, + vfs_s_telldir, + vfs_s_seekdir, + + vfs_s_stat, + vfs_s_lstat, + vfs_s_fstat, + + NULL, /* chmod */ + NULL, /* chown */ + NULL, /* utime */ + + vfs_s_readlink, + NULL, /* symlink */ + NULL, /* link */ + NULL, /* unlink */ + NULL, /* rename */ + vfs_s_chdir, + vfs_s_ferrno, + vfs_s_lseek, + NULL, /* mknod */ + + vfs_s_getid, + vfs_s_nothingisopen, + vfs_s_free, + + vfs_s_getlocalcopy, + diff_ungetlocalcopy, + + NULL, /* mkdir */ + NULL, /* rmdir */ + NULL, /* ctl */ + NULL /* setctl */ + +MMAPNULL +}; diff -ruN mc-4.5.99a/vfs/vfs.h mc-4.5.99a-oskar/vfs/vfs.h --- mc-4.5.99a/vfs/vfs.h Sun Feb 10 03:26:19 2002 +++ mc-4.5.99a-oskar/vfs/vfs.h Fri Feb 22 23:12:07 2002 @@ -108,6 +108,7 @@ extern vfs vfs_nil_ops; extern vfs vfs_tarfs_ops; extern vfs vfs_cpiofs_ops; + extern vfs vfs_difffs_ops; extern vfs vfs_ftpfs_ops; extern vfs vfs_smbfs_ops; diff -ruN mc-4.5.99a/vfs/xdirentry.h mc-4.5.99a-oskar/vfs/xdirentry.h --- mc-4.5.99a/vfs/xdirentry.h Fri Aug 3 12:15:17 2001 +++ mc-4.5.99a-oskar/vfs/xdirentry.h Fri Feb 22 23:12:47 2002 @@ -88,6 +88,12 @@ struct stat tarstat; } tar; struct { + int fd; + struct stat tarstat; + int list_fd; + char *list_name; + } diff; + struct { int sockr, sockw; char *home, *cwdir; char *host, *user; diff -ruN mc-4.5.99a/vfs/vfs.c mc-4.5.99a-oskar/vfs/vfs.c --- mc-4.5.99a/vfs/vfs.c Sun Feb 10 03:26:19 2002 +++ mc-4.5.99a-oskar/vfs/vfs.c Fri Feb 22 23:19:20 2002 @@ -1275,6 +1275,7 @@ vfs_register (&vfs_sfs_ops); vfs_register (&vfs_tarfs_ops); vfs_register (&vfs_cpiofs_ops); + vfs_register (&vfs_difffs_ops); #ifdef USE_EXT2FSLIB vfs_register (&vfs_undelfs_ops); From proski at gnu.org Fri Feb 22 23:28:34 2002 From: proski at gnu.org (Pavel Roskin) Date: Fri, 22 Feb 2002 18:28:34 -0500 (EST) Subject: Spanish translations updated In-Reply-To: <20020220104509.B4E1C8AF1F@xprdmailfe.excite.com> Message-ID: Hi, David! Thank you, I've commited them. -- Regards, Pavel Roskin From rhkramer at fast.net Sat Feb 23 00:08:32 2002 From: rhkramer at fast.net (Randy Kramer) Date: Fri, 22 Feb 2002 19:08:32 -0500 Subject: Making the "Panel" Background White? Message-ID: <3C76DD80.69F7@fast.net> How do I make the background of the panels white? I try to set the colors, using, for example, xterm=normal=black,white:... in my ~/.mc/ini file, and it definitely affects the colors, but the best I can do is get a gray panel (black text on gray). There are some other color oddities too -- when I specify yellow as the background for "directory" it shows up as red (as does red). I am running GNU Midnight Commander 4.5.55 using S-lang library with terminfo database, on Mandrake 8.1, but I have the same problems with MC on Mandrake 7.2. Randy Kramer From avarakin00 at hotmail.com Sun Feb 24 04:00:49 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Sat, 23 Feb 2002 23:00:49 -0500 Subject: regex fix for cygwin References: <3C76DD80.69F7@fast.net> Message-ID: Hi, I fixed the problem with regex on cygwin. The reason of the problem is that definition of regexec() in regex.c is disabled using #if 0 (why?) , and It looks like the cygwin's implementation is not right (compatible?), so all this regex business fails. I fixed the problem by replacing "#if 0" by #ifdef __CYGWIN__, this is the safest approach, it shouldn't break any other platforms. But the better fix would be to remove those "#if 0" completely, this will make mc's regex code indpendent of system libary, but this may be risky. Now mc's find-file works, and viewer doesn't use "nm" for opening all files. Alex Index: eregex.h =================================================================== RCS file: /cvs/gnome/mc/src/eregex.h,v retrieving revision 1.2 diff -c -r1.2 eregex.h *** eregex.h 2000/08/22 22:50:14 1.2 --- eregex.h 2002/02/24 03:52:49 *************** *** 347,353 **** /* [[[end pattern_buffer]]] */ }; ! #if 0 typedef struct re_pattern_buffer regex_t; #endif --- 347,353 ---- /* [[[end pattern_buffer]]] */ }; ! #ifdef __CYGWIN__ typedef struct re_pattern_buffer regex_t; #endif *************** *** 373,379 **** #define RE_NREGS 30 #endif ! #if 0 /* POSIX specification for registers. Aside from the different names than `re_registers', POSIX uses an array of structures, instead of a structure of arrays. */ --- 373,379 ---- #define RE_NREGS 30 #endif ! #ifdef __CYGWIN__ /* POSIX specification for registers. Aside from the different names than `re_registers', POSIX uses an array of structures, instead of a structure of arrays. */ *************** *** 475,481 **** extern int re_exec _RE_ARGS ((const char *)); #endif ! #if 0 /* POSIX compatibility. */ extern int regcomp _RE_ARGS ((regex_t *preg, const char *pattern, int cflags)); extern int regexec --- 475,481 ---- extern int re_exec _RE_ARGS ((const char *)); #endif ! #ifdef __CYGWIN__ /* POSIX compatibility. */ extern int regcomp _RE_ARGS ((regex_t *preg, const char *pattern, int cflags)); extern int regexec Index: regex.c =================================================================== RCS file: /cvs/gnome/mc/src/regex.c,v retrieving revision 1.7 diff -c -r1.7 regex.c *** regex.c 2001/08/19 16:18:40 1.7 --- regex.c 2002/02/24 03:53:12 *************** *** 5176,5182 **** /* POSIX.2 functions. Don't define these for Emacs. */ ! #if 0 /* regcomp takes a regular expression as a string and compiles it. --- 5176,5182 ---- /* POSIX.2 functions. Don't define these for Emacs. */ ! #ifdef __CYGWIN__ /* regcomp takes a regular expression as a string and compiles it. From avarakin00 at hotmail.com Mon Feb 25 05:02:35 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Mon, 25 Feb 2002 00:02:35 -0500 Subject: regex fix for cygwin References: <3C76DD80.69F7@fast.net> Message-ID: Hi, I found another bug related to regex - there is inconsistent usage of regex.h and eregex.h in c files, and since they are very different in cygwin, we have all sort of weird problems. I just grepped all c files and replaced #include "regex.h" by #include "eregex.h", this fixed my problems. Alex ----- Original Message ----- From: "Alexander Varakin" To: Sent: Saturday, February 23, 2002 11:00 PM Subject: regex fix for cygwin > Hi, > > I fixed the problem with regex on cygwin. > The reason of the problem is that definition of regexec() in regex.c is > disabled using #if 0 (why?) , and It looks like the cygwin's implementation > is not > right (compatible?), so all this regex business fails. > I fixed the problem by replacing "#if 0" by #ifdef __CYGWIN__, this is the > safest approach, it shouldn't break any other platforms. > But the better fix would be to remove those "#if 0" completely, this will > make mc's regex code indpendent of system libary, but this may be risky. > Now mc's find-file works, and viewer doesn't use "nm" for opening all files. > > Alex > > > > Index: eregex.h > =================================================================== > RCS file: /cvs/gnome/mc/src/eregex.h,v > retrieving revision 1.2 > diff -c -r1.2 eregex.h > *** eregex.h 2000/08/22 22:50:14 1.2 > --- eregex.h 2002/02/24 03:52:49 > *************** > *** 347,353 **** > /* [[[end pattern_buffer]]] */ > }; > > ! #if 0 > typedef struct re_pattern_buffer regex_t; > #endif > > --- 347,353 ---- > /* [[[end pattern_buffer]]] */ > }; > > ! #ifdef __CYGWIN__ > typedef struct re_pattern_buffer regex_t; > #endif > > *************** > *** 373,379 **** > #define RE_NREGS 30 > #endif > > ! #if 0 > /* POSIX specification for registers. Aside from the different names than > `re_registers', POSIX uses an array of structures, instead of a > structure of arrays. */ > --- 373,379 ---- > #define RE_NREGS 30 > #endif > > ! #ifdef __CYGWIN__ > /* POSIX specification for registers. Aside from the different names than > `re_registers', POSIX uses an array of structures, instead of a > structure of arrays. */ > *************** > *** 475,481 **** > extern int re_exec _RE_ARGS ((const char *)); > #endif > > ! #if 0 > /* POSIX compatibility. */ > extern int regcomp _RE_ARGS ((regex_t *preg, const char *pattern, int > cflags)); > extern int regexec > --- 475,481 ---- > extern int re_exec _RE_ARGS ((const char *)); > #endif > > ! #ifdef __CYGWIN__ > /* POSIX compatibility. */ > extern int regcomp _RE_ARGS ((regex_t *preg, const char *pattern, int > cflags)); > extern int regexec > > > > > Index: regex.c > =================================================================== > RCS file: /cvs/gnome/mc/src/regex.c,v > retrieving revision 1.7 > diff -c -r1.7 regex.c > *** regex.c 2001/08/19 16:18:40 1.7 > --- regex.c 2002/02/24 03:53:12 > *************** > *** 5176,5182 **** > > /* POSIX.2 functions. Don't define these for Emacs. */ > > ! #if 0 > > /* regcomp takes a regular expression as a string and compiles it. > > --- 5176,5182 ---- > > /* POSIX.2 functions. Don't define these for Emacs. */ > > ! #ifdef __CYGWIN__ > > /* regcomp takes a regular expression as a string and compiles it. > > > > _______________________________________________ > Mc-devel mailing list > Mc-devel at gnome.org > http://mail.gnome.org/mailman/listinfo/mc-devel > From proski at gnu.org Mon Feb 25 06:01:50 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 25 Feb 2002 01:01:50 -0500 (EST) Subject: regex fix for cygwin In-Reply-To: Message-ID: Hi, Alexander! Thank you for fixing the problem on Cygwin. It is very important to fix this problem. My understanding is that MC uses some internal GNU regex functions. That's why it uses regex stripped of most other stuff that is supposed to be provided by libc. But there is no guarantee that both regex implementations don't conflict. I see two approaches how to fix the problem: 1) Rename all non-standard regex functions and global variables to avoid conflicts with regex from libc. 2) Always use complete GNU regex, either from libc if it's there or from the files included into the distribution. I prefer the later. I believe that your patch goes in that direction. > I found another bug related to regex - there is inconsistent usage of > regex.h and eregex.h in c files, and since they are very different in > cygwin, we have all sort of weird problems. > I just grepped all c files and replaced #include "regex.h" by #include > "eregex.h", this fixed my problems. Is it sufficient, or your patch from the previous message is still required? -- Regards, Pavel Roskin From avarakin00 at hotmail.com Mon Feb 25 18:59:06 2002 From: avarakin00 at hotmail.com (Alexander Varakin) Date: Mon, 25 Feb 2002 13:59:06 -0500 Subject: regex fix for cygwin References: Message-ID: Hi, I agree that we must use the second approach, i.e.: 1. Use the mc's regex code, i.e. src/regex.c and src/eregex.h. Maybe we should rename src/regex.c to src/eregex.c just to be consistent? 2. Reenable the mc's regex code for all platforms, i.e. remove those "#if 0" from src/regex.c and src/eregex.h 3. Replace all instances of #include "regex.h" by #include "eregex.h" 4. Unfortunately after this we must test it on all platforms, but I don't think we will have any problems ... This way we will be independent of the libc's or os's implementation of regex. > Is it sufficient, or your patch from the previous message is still > required? Yes, it is required, but instead of replacing "#if 0" by "ifdef __CYGWIN__" we must just remove them, or maybe replace them by "#if emacs" which is the original state of this code. If this is ok with maintainers, I can do all these changes and send a final patch. Alex ----- Original Message ----- From: Pavel Roskin To: Alexander Varakin Cc: Sent: Monday, February 25, 2002 1:01 AM Subject: Re: regex fix for cygwin > Hi, Alexander! > > Thank you for fixing the problem on Cygwin. It is very important to fix > this problem. > > My understanding is that MC uses some internal GNU regex functions. > That's why it uses regex stripped of most other stuff that is supposed to > be provided by libc. But there is no guarantee that both regex > implementations don't conflict. > > I see two approaches how to fix the problem: > > 1) Rename all non-standard regex functions and global variables to avoid > conflicts with regex from libc. > > 2) Always use complete GNU regex, either from libc if it's there or from > the files included into the distribution. > > I prefer the later. I believe that your patch goes in that direction. > > > I found another bug related to regex - there is inconsistent usage of > > regex.h and eregex.h in c files, and since they are very different in > > cygwin, we have all sort of weird problems. > > I just grepped all c files and replaced #include "regex.h" by #include > > "eregex.h", this fixed my problems. > > > -- > Regards, > Pavel Roskin > > _______________________________________________ > Mc-devel mailing list > Mc-devel at gnome.org > http://mail.gnome.org/mailman/listinfo/mc-devel > From nerijus at users.sourceforge.net Mon Feb 25 23:09:49 2002 From: nerijus at users.sourceforge.net (Nerijus Baliunas) Date: Tue, 26 Feb 2002 01:09:49 +0200 (EET) Subject: suggestion Message-ID: Hello, I have a small suggestion - menu item "Gzip or gunzip current file" to recognize also bzipped2 files. Regards, Nerijus From proski at gnu.org Mon Feb 25 23:16:35 2002 From: proski at gnu.org (Pavel Roskin) Date: Mon, 25 Feb 2002 18:16:35 -0500 (EST) Subject: suggestion In-Reply-To: Message-ID: Hi! > I have a small suggestion - menu item "Gzip or gunzip current file" to > recognize also bzipped2 files. Why not fix bzip2 and gzip to call each other if needed? Of course it can be done in MC, but the problem is deeper. -- Regards, Pavel Roskin From kai at cmail.ru Tue Feb 26 11:59:07 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Tue, 26 Feb 2002 13:59:07 +0200 Subject: Translated mc manual pages may be converted to mc.hlp format Message-ID: <3C7B788B.8060908@cmail.ru> Hi! I worked out a set of patches and now translated mc manual pages can be converted to mc.hlp format. Working example for Russian language can be downloaded as http://www.linux.zp.ua/mc/mc.hlp.ru.tgz There are doc/ru/mc.1.in, binary doc/ru/xnc.hlp and 3 patches for src/man2hlp.c src/gindex.pl ChangeLog: * doc/ru: New directory for Russian translations. * doc/ru/mc.1.in: New Russian translation of mc (1) manual page. * doc/ru/xnc.xlp: Translated lib/xnc.hlp. src/ChangeLog: * man2hlp.c (main): Don't crash if man2hlp without parameters called. (handle_command): New .\"NODE command added. Use in translated mc manual to specify original .SH * gindex.pl: Use [nodename] as user visible section name only if next line is empty. Elsewhere use this nonempty line. * Makefile.am (mc.hlp.ru): Add rule to compile mc.hlp.ru. From proski at gnu.org Tue Feb 26 20:43:29 2002 From: proski at gnu.org (Pavel Roskin) Date: Tue, 26 Feb 2002 15:43:29 -0500 (EST) Subject: regex fix for cygwin In-Reply-To: Message-ID: Hi! > I agree that we must use the second approach, i.e.: > > 1. Use the mc's regex code, i.e. src/regex.c and src/eregex.h. > Maybe we should rename src/regex.c to src/eregex.c just to be consistent? I would rather call them both regex.* unless it causes problems (it should not). > 2. Reenable the mc's regex code for all platforms, i.e. remove those "#if > 0" from src/regex.c and src/eregex.h Take the latest regex sources from gnu. It is Ok if all code is disabled when GNU libc is found - libc should provide the same functions, although I'm a bit worried if those internal functions can be used - if not, then the included regex should be used. Important is that either you disable all or you enable all. No mix of libc regex and included regex. > 3. Replace all instances of #include "regex.h" by #include "eregex.h" Or vice versa, but make sure that the included regex.h has preference. > 4. Unfortunately after this we must test it on all platforms, but I don't > think we will have any problems ... I think that it's sufficient to test on GNU/Linux, FreeBSD and Cygwin. > Yes, it is required, but instead of replacing "#if 0" by "ifdef __CYGWIN__" > we must just remove them, or maybe replace them by "#if emacs" which is the > original state of this code. It's better not to change those files to facilitate their upgrade. Maybe even "emacs" should be defined if needed. > If this is ok with maintainers, I can do all these changes and send a final > patch. Yes, please do. -- Regards, Pavel Roskin From despair at sama.ru Wed Feb 27 16:27:29 2002 From: despair at sama.ru (Walery Studennikov) Date: Wed, 27 Feb 2002 20:27:29 +0400 Subject: Problems with vfs / ftpfs Message-ID: <20020227202729.A6604@prog1> 1. Strange things happens when you try to upload file to ftp when the file with the same name already exists there. At first existing file (which must be overwritten) is DOWNLOADED to the local machine and only after that the local file is uploaded to ftp. So, WHY to download the remote file (increasing incomming traffic and wasting time) before owerwrite it? 2. Why when copying local files to ftp, those files are copied to /tmp at first and only after that they are copied to ftp. WHY do we do this unnecessary operation? 3. An ancient problem: Cannot chmod target file "/mnt/d/file.txt" Operation not permitted (1) Occures when copying to vfat filesystems, but not only. If we need to copy MANY files, we have to WASTE TIME and press OK many times. You can say "use cp -rf". Yes, but with "cp -rf" I can't use mc vfs. May be we will introduce a run-time option to disable whose annoying warnings? I mean to not disable them entirely, but just print those warnings on the hintbar. Also when we MOVE files and this warning occurs, the source file is not removed. Yes, it is wise in most cases, but maybe also provide an option to fix this? Thank you. -- Regards, Walery From sav at it.efp.com.ua Thu Feb 28 10:06:42 2002 From: sav at it.efp.com.ua (Andrew V. Samoilov) Date: Thu, 28 Feb 2002 12:06:42 +0200 Subject: Problems with vfs / ftpfs References: <20020227202729.A6604@prog1> Message-ID: <3C7E0132.7010603@it.efp.com.ua> Walery Studennikov wrote: > 1. > > Strange things happens when you try to upload file to > ftp when the file with the same name already exists there. > At first existing file (which must be overwritten) > is DOWNLOADED to the local machine and only after that > the local file is uploaded to ftp. > So, WHY to download the remote file (increasing incomming traffic > and wasting time) before owerwrite it? > 2. > > Why when copying local files to ftp, those files are copied > to /tmp at first and only after that they are copied to ftp. > WHY do we do this unnecessary operation? When file is opened there is no way to know, will the read() system call used, because O_RDONLY is 0. So, for performance reasons VFS layer makes local temporary copy of this file, and then all of data is read and written from/to this copy. And this file is uploaded only in mc_close(). Possible solutions are: 1) get local copy on first read call only (Brr) 2) provide something like O_LINEAR flag (As far as I remember there were some problems with this options and Pavel Machek disabled this one.) Another solution is an own flag for mc_open, but we need to be sure it and its value are used nowhere in known Universe for open system call. 3) use directly vfs_s_data.file_store in copy_file_file/move_file_file if destination is not on local filesystem. > 3. > > An ancient problem: > > Cannot chmod target file "/mnt/d/file.txt" > Operation not permitted (1) > > Occures when copying to vfat filesystems, but not only. > If we need to copy MANY files, we have to WASTE TIME > and press OK many times. > You can say "use cp -rf". Yes, but with "cp -rf" > I can't use mc vfs. > > May be we will introduce a run-time option > to disable whose annoying warnings? > I mean to not disable them entirely, > but just print those warnings on the hintbar. > > Also when we MOVE files and this warning occurs, > the source file is not removed. > Yes, it is wise in most cases, but maybe > also provide an option to fix this? > > You can unset "preserve Attributes" when copy. In January, 2002, I sent a patch to enable this feature for Move operation. Regards, Andrew V. Samoilov. From despair at sama.ru Thu Feb 28 13:43:42 2002 From: despair at sama.ru (Walery Studennikov) Date: Thu, 28 Feb 2002 17:43:42 +0400 Subject: Problems with vfs / ftpfs In-Reply-To: <3C7E0132.7010603@it.efp.com.ua> References: <20020227202729.A6604@prog1> <3C7E0132.7010603@it.efp.com.ua> Message-ID: <20020228174342.B3062@prog1> On Thu, Feb 28, 2002 at 12:06:42PM +0200, Andrew V. Samoilov wrote: > >Cannot chmod target file "/mnt/d/file.txt" > >Operation not permitted (1) > > You can unset "preserve Attributes" when copy. > In January, 2002, I sent a patch to enable this feature for Move operation. This doesn't work for me. I've tried several versions, now I'm using CVS version. -- Regards, Walery From kai at cmail.ru Thu Feb 28 15:18:48 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Thu, 28 Feb 2002 17:18:48 +0200 Subject: Problems with vfs / ftpfs References: <20020227202729.A6604@prog1> <3C7E0132.7010603@it.efp.com.ua> <20020228174342.B3062@prog1> Message-ID: <3C7E4A58.8090800@cmail.ru> Walery Studennikov wrote: > On Thu, Feb 28, 2002 at 12:06:42PM +0200, Andrew V. Samoilov wrote: > >>>Cannot chmod target file "/mnt/d/file.txt" >>>Operation not permitted (1) >>> >>You can unset "preserve Attributes" when copy. >>In January, 2002, I sent a patch to enable this feature for Move operation. >> > > This doesn't work for me. I've tried several versions, > now I'm using CVS version. Confirmed for root. It seems preserve_uidgid option is more powerful than 'preserve Attributes'. -- Regards, Andrew V. Samoilov. From despair at sama.ru Thu Feb 28 16:00:00 2002 From: despair at sama.ru (Walery Studennikov) Date: Thu, 28 Feb 2002 20:00:00 +0400 Subject: Problems with vfs / ftpfs In-Reply-To: <3C7E4A58.8090800@cmail.ru> References: <20020227202729.A6604@prog1> <3C7E0132.7010603@it.efp.com.ua> <20020228174342.B3062@prog1> <3C7E4A58.8090800@cmail.ru> Message-ID: <20020228200000.A1027@prog1> On Thu, Feb 28, 2002 at 05:18:48PM +0200, Andrew V. Samoilov wrote: > >>>Cannot chmod target file "/mnt/d/file.txt" > >>>Operation not permitted (1) > >>> > >>You can unset "preserve Attributes" when copy. > >>In January, 2002, I sent a patch to enable this feature for Move > >>operation. > >> > > > >This doesn't work for me. I've tried several versions, > >now I'm using CVS version. > > > Confirmed for root. It seems preserve_uidgid option is more powerful > than 'preserve Attributes'. Where is / what is "preserve_uidgid" option? So, how to solve / workaround this problem? -- Regards, Walery From kai at cmail.ru Thu Feb 28 16:19:53 2002 From: kai at cmail.ru (Andrew V. Samoilov) Date: Thu, 28 Feb 2002 18:19:53 +0200 Subject: Problems with vfs / ftpfs In-Reply-To: <20020228200000.A1027@prog1> References: <20020227202729.A6604@prog1> <3C7E0132.7010603@it.efp.com.ua> <20020228174342.B3062@prog1> <3C7E4A58.8090800@cmail.ru> <20020228200000.A1027@prog1> Message-ID: <20020228181953.A531@it.efp.com.ua> On Thu, Feb 28, 2002 at 08:00:00PM +0400, Walery Studennikov wrote: > On Thu, Feb 28, 2002 at 05:18:48PM +0200, Andrew V. Samoilov wrote: > > >>>Cannot chmod target file "/mnt/d/file.txt" > > >>>Operation not permitted (1) > > >>> > > >>You can unset "preserve Attributes" when copy. > > >>In January, 2002, I sent a patch to enable this feature for Move > > >>operation. > > >> > > > > > >This doesn't work for me. I've tried several versions, > > >now I'm using CVS version. > > > > > > Confirmed for root. It seems preserve_uidgid option is more powerful > > than 'preserve Attributes'. > > Where is / what is "preserve_uidgid" option? preserve_uidgid was wrong impression. You can find these lines in mc(1) manual: preserve_uidgid If this option is set (the default), when logged in as root the default will be to preserve the UID and the GID of files. Some users prefer to disable this option, so that's why it's configurable. > So, how to solve / workaround this problem? Sorry, I can't reproduce this now even for root. Can you test patch below? ChangeLog: * file.c (copy_file_file): Check ctx->preserve. --- mc-cvs/src/file.c Thu Oct 11 20:14:26 2001 +++ mc/src/file.c Thu Feb 28 17:43:05 2002 @@ -808,7 +787,7 @@ copy_file_file (FileOpContext *ctx, char * chmod can be invoked */ retry_dst_chmod: - if (!appending && mc_chmod (dst_path, src_mode & ctx->umask_kill)){ + if (!appending && ctx->preserve && mc_chmod (dst_path, src_mode & ctx->umask_kill)){ temp_status = file_error (_(" Cannot chmod target file \"%s\" \n %s "), dst_path); if (temp_status == FILE_RETRY) goto retry_dst_chmod;