Re: Trouble working with archives when login name has backslash in it

2010-09-20 Thread Yury V. Zaytsev
On Fri, 2010-09-17 at 21:05 +0400, Ivan Balashov wrote:
> 
> I looked over the net trying to find a way to set temp folder with
> static value (without backslash), but could not find a remedy.

Probably the best remedy is to patch the code responsible for temp
folder name generation.

> Can anyone suggest a workaround for this problem? Should I raise a
> bug?

Yes, please. 

There seems to be a number of other problems with temp path (see
Ubuntu / Debian bug tracker), so maybe they can also be solved in this
ticket.

-- 
Sincerely yours,
Yury V. Zaytsev

___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Trouble working with archives when login name has backslash in it

2010-09-20 Thread Ivan Balashov
Hey guys,

Let me report an issue with mc that I've run recently on a new integration
box.

Our company uses windows domain for authentication, and on all linux boxes
users authorize as 'DOMAIN\username'.

The problem with such name is that mc loses the ability to work with
archives (extract files from archives, edit files inside archives), since
the temp folder it creates contains back slashes, and thus becomes
unaccessible.

I looked over the net trying to find a way to set temp folder with static
value (without backslash), but could not find a remedy.

Can anyone suggest a workaround for this problem? Should I raise a bug?

Thanks!

-- 
Kind Regards
 Ivan
___
mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [Midnight Commander] #34: [FtReq] DAR archive support (was: savannah: Feature request, please add support for dar archives)

2009-01-11 Thread Ticket System
#34: [FtReq] DAR archive support
--+-
  Reporter:  slavazanko   |   Owner: 
  Type:  enhancement  |  Status:  new
  Priority:  minor|   Milestone: 
 Component:  vfs  | Version: 
Resolution:   |Keywords: 
  Blocking:   |   Blockedby: 
--+-
Changes (by metux):

  * priority:  trivial => minor
  * type:  task => enhancement


-- 
Ticket URL: 
Midnight Commander 
Midnight Development Center
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: archives

2007-03-09 Thread Pavel Tsekov
Hello,

On Fri, 9 Mar 2007, [EMAIL PROTECTED] wrote:

> I tried MC snapshot. It works! It shows correct archive layout.
> Thank you. I'm sorry for wasting your time and bandwidth.

Certain changes were made to the tar handling code with regards
to the POSIX tar format. I guess your .tar file was created with
the pax utility or with tar which output posix format .tar files
and thus it didn't display properly.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: archives

2007-03-09 Thread applecom
Pavel Tsekov <[EMAIL PROTECTED]> wrote:

> Hello,
>
> I've just fetched the compressed ports tree from:
>
> ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports-current/ports.tar.gz
>
> I've extracted the archive contents into a temporary directory
> and cd-ed into it with MC. In the other panel I've pressed Enter
> on the archive. The output in both panels is the same. I am
> using MC from CVS. I suggest you to try a MC snapshot and if
> that doesn't help report the exact commands that you've used
> to create the archive which fools MC.

I tried MC snapshot. It works! It shows correct archive layout.
Thank you. I'm sorry for wasting your time and bandwidth.
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: archives

2007-03-08 Thread Pavel Tsekov
Hello,

I've just fetched the compressed ports tree from:

ftp://ftp.freebsd.org/pub/FreeBSD/ports/ports-current/ports.tar.gz

I've extracted the archive contents into a temporary directory
and cd-ed into it with MC. In the other panel I've pressed Enter
on the archive. The output in both panels is the same. I am
using MC from CVS. I suggest you to try a MC snapshot and if
that doesn't help report the exact commands that you've used
to create the archive which fools MC.

___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: archives

2007-03-08 Thread Pavel Tsekov
Hello,

On Thu, 8 Mar 2007, [EMAIL PROTECTED] wrote:

> Pavel Tsekov <[EMAIL PROTECTED]> wrote:
>
>> Ok then. I guess you can at least supply the names of those
>> ports and links to them. So I can fetch them off the FreeBSD
>> site - is that ok ?
>
> I doubt whether an effect is reproducible with small number of directories 
> and files. For example, partial FreeBSD doc tree archive (which is about 3.5 
> MB) is handled by MC fully correctly.
> I can list the real directory structure and the one which MC shows.
>
> Contents of /usr/ports/:

[...]

> When entering archive with ports tree (excluding distfiles and packages) I 
> see in the panel:
>
> /editors
> /gnome-splashscreen-manager
> /lang
> /net-p2p
> /openoffice.org-1.1-devel
> /ports
> /sysutils
> /usr
> /x11-themes
>
> Under all directories, except 'usr' some partial content is shown. Under 
> 'usr' everything is correct: 'ports', then listing above. If you really want, 
> you can receive FreeBSD ports or src trees via cvs or cvsup. Instructions 
> exist at
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/anoncvs.html
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/cvsup.html
>
> I asked about 'tar tvf' using for contents showing. Why not to use it instead 
> of full archive decompressing?

Ok, now. What I want to know is the exact steps to build an
archive like the one that you have so I can see what's wrong.
Even if I fetch the ports tree using the instructions above,
I'll need to know what commands did you use to create the
tar file. Having the same file as yours would help me to
debug the problem. If you really care to know why "tar tvf"
is not used you can have a look at the source tree. If you
want me to try the bug you have to help me a bit...

Btw have you tried using a snapshot MC to see if it behaves
better ? You can get a snapshot source from:

http://www.ibiblio.org/pub/Linux/utils/file/managers/mc/snapshots/

P.S. Do not reply to my personal address but rather use
the mailing list address instead.

Thanks!
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: archives

2007-03-08 Thread Pavel Tsekov
Hello,

On Thu, 8 Mar 2007, [EMAIL PROTECTED] wrote:

> Pavel Tsekov <[EMAIL PROTECTED]> wrote:
>
>>> MC shows list of files in large (a few tens of MB) gzipped/bzip2'ed tar
>>> archives with multi-level directory structure incorrectly. When archive
>>> contains only one root folder, MC shows directories from other levels, as
>>> it were to be root folders. It doesn't affect other archive operations.
>>> File list in real root folder is shown correctly. File list of non-root
>>> folders, been accessed from root list, is shown incorrectly too (only part
>>> of its contents).
>> 
>> Please, put some of those files that you speak of on some place where
>> I can download them and see what's wrong. What version of MC are you using
>> ?

Ok then. I guess you can at least supply the names of those
ports and links to them. So I can fetch them off the FreeBSD
site - is that ok ?

___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: archives

2007-03-07 Thread Pavel Tsekov
Hello,

On Wed, 7 Mar 2007, [EMAIL PROTECTED] wrote:

> MC shows list of files in large (a few tens of MB) gzipped/bzip2'ed tar
> archives with multi-level directory structure incorrectly. When archive
> contains only one root folder, MC shows directories from other levels, as
> it were to be root folders. It doesn't affect other archive operations.
> File list in real root folder is shown correctly. File list of non-root
> folders, been accessed from root list, is shown incorrectly too (only part
> of its contents).

Please, put some of those files that you speak of on some place where
I can download them and see what's wrong. What version of MC are you using 
?

___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


archives

2007-03-07 Thread applecom
MC shows list of files in large (a few tens of MB) gzipped/bzip2'ed tar  
archives with multi-level directory structure incorrectly. When archive  
contains only one root folder, MC shows directories from other levels, as  
it were to be root folders. It doesn't affect other archive operations.  
File list in real root folder is shown correctly. File list of non-root  
folders, been accessed from root list, is shown incorrectly too (only part  
of its contents).

Besides that, in fact, when entering to archives, MC just decompress it  
into temporary file. Therefore, if uncompressed size of files is more than  
/tmp space, operation is ended with an error. 'tar tvf' is much faster. Is  
it possible to use it when entering to archives instead of decompressing?
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


[bug #15057] Feature request, please add support for dar archives

2006-01-28 Thread Roland Illig

Update of bug #15057 (project mc):

Category:None => VFS


___

Reply to this item at:

  

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/

___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


[bug #15057] Feature request, please add support for dar archives

2005-11-24 Thread Martin Seifert

URL:
  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15057>

 Summary: Feature request, please add support for dar
archives
 Project: GNU Midnight Commander
Submitted by: puntarenas
Submitted on: Fr 25.11.2005 um 05:39
Category: None
Severity: 3 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.6.1
Platform Version: GNU/Linux

___

Details:

Disk ARchive from http://dar.linux.free.fr/ is a shell command that backs up
directory trees and files. I don`t know if it is possible to add support for
*.dar files, so one could "browse" them like it is already working for *.tar
archives.

Kind regards

Martin Seifert







___

Reply to this item at:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=15057>

___
  Nachricht geschickt von/durch Savannah
  http://savannah.gnu.org/

___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [EMAIL PROTECTED]: Bug#324755: mc: tar archives greater than 2GB not supported]

2005-08-25 Thread Leonard den Ottolander
Hi,

On Wed, 2005-08-24 at 06:36 +0200, Stefano Melchior wrote:
> +off_t result;

> +if (result == (off_t)-1)

Is this cast of -1 necessary as result already is an off_t?

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research


___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [Bug#324755: mc: tar archives greater than 2GB not supported] (fwd)

2005-08-25 Thread Pavel Tsekov
Hello,

Forwarding the message to mc-devel at gnome dot org where it belongs.
Please, keep the discussion public.

-- Forwarded message --
Date: Thu, 25 Aug 2005 14:54:55 +0200
From: Michael Mueller
To: Pavel Tsekov
Subject: Re: [Bug#324755: mc: tar archives greater than 2GB not supported]

Hi Pavel,

you wrote to Stefano Melchior:
>This seems to be a much needed patch indeed. I haven't applied it nor
>tested it - just took a look at it. I noticed something that might need
>to be fixed in the 3rd  hunk of tar.c patch:
>
>@@ -642,8 +642,9 @@
> int fd = FH_SUPER->u.arch.fd;
> struct vfs_class *me = FH_SUPER->me;
>
>-if (mc_lseek (fd, begin + FH->pos, SEEK_SET) !=
>-begin + FH->pos) ERRNOR (EIO, -1);
>+
>+off_t o = mc_lseek(fd, begin + FH->pos, SEEK_SET);
>+if ( o != begin + FH->pos) ERRNOR (EIO, -1);
>
> count = MIN(count, FH->ino->st.st_size - FH->pos);
>
>The type of FH->pos is not off_t but long. See struct vfs_s_fh in
>vfs/xdirentry.h .

Yes, I did notice this before. This should make it impossible to read
files bigger than 2GB from inside the archive. I simply stopped there
because now it is working for me, which is sufficient for a local patch ;)
However, from the findings in the code it seems to be sufficient to
change the definition of 'ofs' in the structs definition.

Btw, the chunk you quoted is not really needed, just used the temporary
variable ('o') for debugging purpose. The result of mc_lseek is off_t
with this patch and (begin + FH->pos) should give an integer the size of
off_t too. So comparing them directly - as was before - should give the
same code in result.


With best regards
Michael M?ller
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [EMAIL PROTECTED]: Bug#324755: mc: tar archives greater than 2GB not supported]

2005-08-24 Thread Pavel Tsekov
Hello,

On Wed, 24 Aug 2005, Stefano Melchior wrote:

> Hi Pavel,
> Michael, a Debian GNU/Linux user, reported this bug and suggested the
> following patch for the same.
> I soon would like to infor you and the `mc-devel` list about this.
> Thank you in advance

This seems to be a much needed patch indeed. I haven't applied it nor
tested it - just took a look at it. I noticed something that might need
to be fixed in the 3rd  hunk of tar.c patch:

@@ -642,8 +642,9 @@
 int fd = FH_SUPER->u.arch.fd;
 struct vfs_class *me = FH_SUPER->me;

-if (mc_lseek (fd, begin + FH->pos, SEEK_SET) !=
-begin + FH->pos) ERRNOR (EIO, -1);
+
+off_t o = mc_lseek(fd, begin + FH->pos, SEEK_SET);
+if ( o != begin + FH->pos) ERRNOR (EIO, -1);

 count = MIN(count, FH->ino->st.st_size - FH->pos);

The type of FH->pos is not off_t but long. See struct vfs_s_fh in
vfs/xdirentry.h .
___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


[EMAIL PROTECTED]: Bug#324755: mc: tar archives greater than 2GB not supported]

2005-08-23 Thread Stefano Melchior
Hi Pavel,
Michael, a Debian GNU/Linux user, reported this bug and suggested the
following patch for the same.
I soon would like to infor you and the `mc-devel` list about this.
Thank you in advance

Cheers

SteX

- Forwarded message from Michael Mueller <[EMAIL PROTECTED]> -

Date: Tue, 23 Aug 2005 21:50:35 +0200
From: Michael Mueller <[EMAIL PROTECTED]>
To: Stefano Melchior <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Subject: Bug#324755: mc: tar archives greater than 2GB not supported
Reply-To: Michael Mueller <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Resent-From: Michael Mueller <[EMAIL PROTECTED]>
Resent-To: debian-bugs-dist@lists.debian.org
Resent-Cc: Stefano Melchior <[EMAIL PROTECTED]>
Resent-Date: Tue, 23 Aug 2005 20:03:10 UTC
Resent-Message-ID: <[EMAIL PROTECTED]>
X-Debian-PR-Message: report 324755
X-Debian-PR-Package: mc
X-Debian-PR-Keywords: 
X-ID: TEOJF2ZOreDY-47VoI3b39kQg+akK-GT4Fbt0Cbg0aubvSIGkeH3rO
X-TOI-MSGID: dc04d4ea-64e3-4bab-bace-072c7e66b82e
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level: 
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Resent-Sender: Debian BTS <[EMAIL PROTECTED]>

Package: mc
Version: 4.6.0-4.6.1-pre4-2

Midnight Commander does handle tar archives bigger than the magic 2GB 
size incorrectly.

I appended a patch fixing the problem. Since it includes changes in the 
VFS of the Midnight Commander, changes made to other virtual filesystems 
are included too. Those however are not tested and mostly will not make 
them bypassing the limit.


With best regards
Michael M?ller

diff -N -r -u -x config.log mc-4.6.1-pre4.debian/vfs/cpio.c 
mc-4.6.1-pre4/vfs/cpio.c
--- mc-4.6.1-pre4.debian/vfs/cpio.c 2005-05-27 16:19:19.0 +0200
+++ mc-4.6.1-pre4/vfs/cpio.c2005-08-23 21:32:39.306219927 +0200
@@ -83,7 +83,7 @@
 struct vfs_s_inode *inode;
 };
 
-static int cpio_position;
+static off_t cpio_position;
 
 static int cpio_find_head(struct vfs_class *me, struct vfs_s_super *super);
 static int cpio_read_bin_head(struct vfs_class *me, struct vfs_s_super *super);
@@ -107,7 +107,7 @@
 return l;
 }
 
-static int cpio_skip_padding(struct vfs_s_super *super)
+static off_t cpio_skip_padding(struct vfs_s_super *super)
 {
 switch(super->u.arch.type) {
 case CPIO_BIN:
diff -N -r -u -x config.log mc-4.6.1-pre4.debian/vfs/direntry.c 
mc-4.6.1-pre4/vfs/direntry.c
--- mc-4.6.1-pre4.debian/vfs/direntry.c 2004-11-29 19:44:49.0 +0100
+++ mc-4.6.1-pre4/vfs/direntry.c2005-08-23 21:32:39.307219773 +0200
@@ -836,13 +836,13 @@
 return 0;
 }
 
-static int
+static off_t
 vfs_s_lseek (void *fh, off_t offset, int whence)
 {
 off_t size = FH->ino->st.st_size;
 
 if (FH->handle != -1){ /* If we have local file opened, we want to 
work with it */
-   int retval = lseek (FH->handle, offset, whence);
+   off_t retval = lseek (FH->handle, offset, whence);
if (retval == -1)
FH->ino->super->me->verrno = errno;
return retval;
diff -N -r -u -x config.log mc-4.6.1-pre4.debian/vfs/extfs.c 
mc-4.6.1-pre4/vfs/extfs.c
--- mc-4.6.1-pre4.debian/vfs/extfs.c2005-05-27 16:19:19.0 +0200
+++ mc-4.6.1-pre4/vfs/extfs.c   2005-08-23 21:32:39.309219464 +0200
@@ -1125,7 +1125,7 @@
 return 0;
 }
 
-static int extfs_lseek (void *data, off_t offset, int whence)
+static off_t extfs_lseek (void *data, off_t offset, int whence)
 {
 struct pseudofile *file = (struct pseudofile *) data;
 
diff -N -r -u -x config.log mc-4.6.1-pre4.debian/vfs/local.c 
mc-4.6.1-pre4/vfs/local.c
--- mc-4.6.1-pre4.debian/vfs/local.c2004-09-25 01:00:18.0 +0200
+++ mc-4.6.1-pre4/vfs/local.c   2005-08-23 21:32:39.310219310 +0200
@@ -197,7 +197,7 @@
 return chdir (path);
 }
 
-int
+off_t
 local_lseek (void *data, off_t offset, int whence)
 {
 int fd = * (int *) data;
diff -N -r -u -x config.log mc-4.6.1-pre4.debian/vfs/local.h 
mc-4.6.1-pre4/vfs/local.h
--- mc-4.6.1-pre4.debian/vfs/local.h2004-08-17 11:17:43.0 +0200
+++ mc-4.6.1-pre4/vfs/local.h   2005-08-23 21:32:39.318218076 +0200
@@ -11,7 +11,7 @@
 extern int local_read (void *data, char *buffer, int count);
 extern int local_fstat (void *data, struct stat *buf);
 extern int local_errno (struct vfs_class *me);
-extern int local_lseek (void *data, off_t offset, int whence);
+extern off_t local_lseek (void *data, off_t offset, int whence);
 #ifdef HAVE_MMAP
 extern caddr_t local_mmap (struct vfs_class *me, caddr_t addr, size_t len,
int prot, int flags, void *data, off_t offset);
diff -N -r -u -x config.log mc-4.6.1-pre4.debian/vfs/mcfs.c 
mc-4.6.1-pre4/vfs/mcfs.c
--- mc-4.6.1-pre4.debian/vfs/mcfs.c 2005-05-27 16:19:19.0 +0200
+++ mc-4.6.1-pre4/vfs/mcfs.c2005-08-23 21:32:39.31521

Re: What happened to the mail archives?

2005-02-01 Thread Leonard den Ottolander
Hi guys,

On Tue, 2005-02-01 at 21:15, Leonard den Ottolander wrote:
> What happened to the mail archives?
> http://mail.gnome.org/archives/mc/2004-November/date.html only shows 6
> messages, although there are hundreds in my mailbox for that month...

 I'm a silly bugger ;-) . Inadvertently put a link to the mc list in
Pavel's wiki where I wanted to put a reference for mc-devel. Duh!

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research


___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: What happened to the mail archives?

2005-02-01 Thread Pavel S. Shirshov
Hello Leonard,

Wednesday, February 2, 2005, 1:15:50 AM, you wrote:

LdO> What happened to the mail archives?
LdO> http://mail.gnome.org/archives/mc/2004-November/date.html only shows 6
LdO> messages, although there are hundreds in my mailbox for that month...

Bug ? :)




-- 
Best regards,
 Pavelmailto:[EMAIL PROTECTED]

___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


What happened to the mail archives?

2005-02-01 Thread Leonard den Ottolander
Hi,

What happened to the mail archives?
http://mail.gnome.org/archives/mc/2004-November/date.html only shows 6
messages, although there are hundreds in my mailbox for that month...

Leonard.

-- 
mount -t life -o ro /dev/dna /genetic/research


___
Mc-devel mailing list
http://mail.gnome.org/mailman/listinfo/mc-devel


[BUG] unpacking zip archives horribly slow

2003-09-01 Thread tux
When I press enter in zip archive, mark some files and press f5 (copy)
to extract them, it takes about 3 second for each file (well, on a
486DX4/100, but running "unzip archive.zip" is much faster, so it's not
caused just by slow cpu)
I think the reason is in extfs/uzip - when I try to run it alone, it takes about 2 
seconds to compile the script with perl and execute it. And since it is executed and 
terminated repeadedly for each extracted file, it's horribly slow (I read numbers like 
200 bytes/second on the progress indicator)
This is especially annoying for archives containing lot of small files,
running unzip takes few seconds, unpacking them with mc via F5(copy)
takes usually few minutes

Proposed solutions:

rewrite uzip in C, not i perl (should be quite easy, just use z-lib). This will be 
faster and I think someone have already done it (i can look on the web for it) but for 
extracting lot of small files this will fix the things only partially.
So I think that in addition to copyin/copyout in extfs protocol there should be added 
something like multicopyin/multicopyout, allowing to supply a list of files to be 
extracted, instead of calling the binary in extfs once for each file.

Or, even better, integrate .zip file support directly into mc (like it seems to be 
done with .tgz files) since .zip is quite popular format ...

Which solution would be the most preferable? I might help with coding it ...

Martin Petricek




___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel


Re: [BUG] extfs - rpm archives

2002-12-29 Thread Tomas Styblo
* Andrew V. Samoilov <[EMAIL PROTECTED]> [Sun, 29 Dec 2002]:
> Tomas Styblo wrote:
> >I finally installed pre2 and discovered that browsing of rpm
> >archives no longer works. This problem was not present in pre1.
> Fixed in CVS.  Thanks for reports.

Thanks. 

I tested the patch and it solved the problem.

-- 
Tomas Styblo <[EMAIL PROTECTED]>
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC97EA4B6
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel



Re: [BUG] extfs - rpm archives

2002-12-29 Thread Andrew V. Samoilov
Tomas Styblo wrote:


Hello.

I finally installed pre2 and discovered that browsing of rpm
archives no longer works. This problem was not present in pre1.

A short error message is displayed:

"Inconsistent extfs archive"

My rpm version is 4.0.4.

This problem happens every time.

The problem is somewhere in the /usr/local/share/mc/extfs/rpm
file. When I replaced it with the same file from pre1,
the problem disappeared.



Fixed in CVS.  Thanks for reports.


--
Regards,
Andrew V. Samoilov

Index: mc/vfs/extfs/rpm
diff -u mc/vfs/extfs/rpm:1.14 mc/vfs/extfs/rpm:1.15
--- mc/vfs/extfs/rpm:1.14   Mon Dec 16 19:32:39 2002
+++ mc/vfs/extfs/rpmSun Dec 29 04:19:39 2002
@@ -16,7 +16,11 @@
 LC_TIME=C
 export LC_TIME
 
-RPM="rpm --nosignature"
+if rpm --nosignature --version >/dev/null 2>&1; then
+  RPM="rpm --nosignature"
+else
+  RPM="rpm"
+fi
 RPM2CPIO="rpm2cpio"
 
 mcrpmfs_list ()



[BUG] extfs - rpm archives

2002-12-29 Thread Tomas Styblo


Hello.

I finally installed pre2 and discovered that browsing of rpm
archives no longer works. This problem was not present in pre1.

A short error message is displayed:

"Inconsistent extfs archive"

My rpm version is 4.0.4.

This problem happens every time.

The problem is somewhere in the /usr/local/share/mc/extfs/rpm
file. When I replaced it with the same file from pre1,
the problem disappeared.

-- 
Tomas Styblo <[EMAIL PROTECTED]>
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC97EA4B6
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel