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: www.midnight-commander.org/ticket/34#comment:2
Midnight Commander www.midnight-commander.org
Midnight Development Center
___
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-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-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-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,

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


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


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


[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:

  http://savannah.gnu.org/bugs/?func=detailitemitem_id=15057

___
  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=detailitemitem_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=detailitemitem_id=15057

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

___
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-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: [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.315218539 +0200
@@ -1037,7 +1037,7 @@
 return 0;
 }
 
-static int
+static off_t
 mcfs_lseek (void *data, off_t

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


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


[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=getsearch=0xC97EA4B6
___
Mc-devel mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/mc-devel