You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
(3) |
Apr
(10) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(5) |
Oct
(2) |
Nov
|
Dec
(2) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(3) |
Feb
(4) |
Mar
(9) |
Apr
(4) |
May
|
Jun
(7) |
Jul
|
Aug
(15) |
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
2005 |
Jan
(2) |
Feb
(21) |
Mar
(11) |
Apr
(1) |
May
(3) |
Jun
(26) |
Jul
(4) |
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(4) |
Dec
(1) |
2006 |
Jan
(7) |
Feb
(23) |
Mar
(17) |
Apr
(3) |
May
(27) |
Jun
(12) |
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
(5) |
Dec
(20) |
2007 |
Jan
(14) |
Feb
(8) |
Mar
|
Apr
|
May
(16) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2008 |
Jan
(4) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(1) |
Oct
(6) |
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2012 |
Jan
|
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2013 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
(1) |
Dec
|
2016 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2023 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Linlin Y. <yan...@gm...> - 2015-10-31 03:00:19
|
what's your file system? On Fri, Oct 30, 2015 at 6:44 PM, Jonathan Bower <jon...@gm...> wrote: > Hi, > I'm having problems with rar archives larger than 2048M. Any way to solve > this? > > Steps to reproduce: > dd if=/dev/zero of=./file.img bs=1M count=2049 && rar a -m0 ./file.rar > ./file.img > > ls file.rar# does not produce any output. > > The step with 2048M works as expected. > > Thanks > Jonathan > > ------------------------------------------------------------------------------ > > _______________________________________________ > Avf-user mailing list > Avf...@li... > https://lists.sourceforge.net/lists/listinfo/avf-user > |
From: Jonathan B. <jon...@gm...> - 2015-10-30 10:44:36
|
Hi, I'm having problems with rar archives larger than 2048M. Any way to solve this? Steps to reproduce: dd if=/dev/zero of=./file.img bs=1M count=2049 && rar a -m0 ./file.rar ./file.img ls file.rar# does not produce any output. The step with 2048M works as expected. Thanks Jonathan |
From: Ralf H. <ra...@bo...> - 2015-06-13 14:13:19
|
Hi, I have uploaded a new minor release of AVFS: https://sourceforge.net/projects/avf/files/avfs/1.0.3/ It fixes a rare assertion triggered by some zip files, and brings a new uextrar module for rar version 5. There are also some small configure changes to fix detection of some dependencies. Best Regards, Ralf -- Ralf Hoffmann <ra...@bo...> Homepage: http://www.boomerangsworld.de |
From: Ralf H. <ra...@bo...> - 2015-03-02 21:19:37
|
Hi, On 2015-03-02 10:20, Artem Pylypchuk wrote: > Hi! I've been using avfs for a while, but recently I built a new Gentoo, and when extracting from rar it doesn't work: > > [341006.628386] rar[16227]: segfault at 28 ip b74e8cc0 sp bf9642e0 error 4 in libc-2.18.so[b7486000+196000] > [341006.645071] unrar[16262]: segfault at 7b ip b74c3f51 sp bfd0ac00 error 4 in libc-2.18.so[b7455000+196000] > > I have no idea why - is it because of "shared library hack" nature of avfs? Rar/unrar work perfectly on their own. That seems indeed weird. Do you use avfs via fuse or as a regular library? Both methods don't use any hacks. Maybe you mean the preload method by transparently redirecting the file system calls to AVFS, but I'm not sure if this actually still works. Problem could also be the specific options used to extract a single file from a rar archive. You can see them in the file "modules/urar.c" in function "get_rar_file". Basically rar is called like this: rar p -c- -ierr <archive> <file to extract> You can check if this also works when running rar separately. Best Regards, Ralf -- Ralf Hoffmann <ra...@bo...> Homepage: http://www.boomerangsworld.de |
From: Artem P. <art...@ua...> - 2015-03-02 09:49:15
|
Hi! I've been using avfs for a while, but recently I built a new Gentoo, and when extracting from rar it doesn't work: [341006.628386] rar[16227]: segfault at 28 ip b74e8cc0 sp bf9642e0 error 4 in libc-2.18.so[b7486000+196000] [341006.645071] unrar[16262]: segfault at 7b ip b74c3f51 sp bfd0ac00 error 4 in libc-2.18.so[b7455000+196000] I have no idea why - is it because of "shared library hack" nature of avfs? Rar/unrar work perfectly on their own. I have rar-5.0.0 and avfs-1.0.1 and glibc-2.18-r1. -- реклама ----------------------------------------------------------- Поторопись зарегистрировать самый короткий почтовый адрес @i.ua http://mail.i.ua/reg - и получи 1Gb для хранения писем |
From: Ralf H. <ra...@bo...> - 2014-06-29 09:15:05
|
Hi, I have uploaded a new release of AVFS: https://sourceforge.net/projects/avf/files/avfs/1.0.2/ It brings support for zip64 and extended headers in tar archives (no more PaxHeaders entries) as well as improved support for files larger than 4/8 GiB for many archive handlers. Best Regards, Ralf Hoffmann -- Ralf Hoffmann <ra...@bo...> Homepage: http://www.boomerangsworld.de |
From: Ralf H. <ra...@bo...> - 2014-06-19 18:48:32
|
Hi, I just pushed some patches to the master branch which adds zip64 support for the uzip module. Missing support was reason for the file limitation. Now more than 64k files and files larger than 4 GiB are supported. Can you please check the current master and tell me if everything works as expected? If so, I will prepare a new release 1.0.2 soon. Best Regards, Ralf Hoffmann -- Ralf Hoffmann <ra...@bo...> Homepage: http://www.boomerangsworld.de |
From: Dan M. <da...@gm...> - 2014-06-17 18:51:02
|
> thanks for the report. I can reproduce it and will look into that. Thanks! > For the external handler, every single file is extracted separately from > each other which often introduces a significant performance penalty, > especially if the extracting tool cannot randomly access files inside > the archive. The internal handlers try to avoid that by storing seek > offsets for fast random access. So, .zip is my best bet until the bug is fixed, with some loss of speed (compared to the internal handler) because unzip must look at the archive table each time a new file is accessed Best, Dan |
From: Ralf H. <ra...@bo...> - 2014-06-16 19:25:33
|
Hi, On 2014-06-09 22:23, Dan Muresan wrote: > Ubuntu 14.04 here, avfs == 1.0.1-2:amd64. The internal uzip.c handler > seems broken for zips with many files: > > # hint: use a tmpfs working directory for faster tests > tst$ find . -delete > tst$ perl -wle 'for (1..50000) { mkdir "$_$_"; open (my $f, ">", > "$_$_/$_"); close $f; }' > tst$ mountavfs > ls ~/.avfs/tmp/x.zip# > ls: cannot access /home/user/.avfs/tmp/x.zip#: No such file or directory > > A strace shows > 30384 sendto(5, "<14>Jun 9 21:22:01 avfs[26671]: UZIP: Broken > archive", 53, MSG_NOSIGNAL, NULL, 0) = 53 > > With x.zip#ext-uzip (on Ubuntu) it works. Also, for fewer zip entries > (e.g. 1..10000) the internal handler works too thanks for the report. I can reproduce it and will look into that. > BTW, what is the performance impact of using the external handler? I > really need to transparently mount archives, and need an archive > format with a central entry table for fast random access (zip and rar > are the most obvious choices I guess). For the external handler, every single file is extracted separately from each other which often introduces a significant performance penalty, especially if the extracting tool cannot randomly access files inside the archive. The internal handlers try to avoid that by storing seek offsets for fast random access. Best Regards, Ralf Hoffmann -- Ralf Hoffmann <ra...@bo...> Homepage: http://www.boomerangsworld.de |
From: Dan M. <da...@gm...> - 2014-06-09 20:24:04
|
Ubuntu 14.04 here, avfs == 1.0.1-2:amd64. The internal uzip.c handler seems broken for zips with many files: # hint: use a tmpfs working directory for faster tests tst$ find . -delete tst$ perl -wle 'for (1..50000) { mkdir "$_$_"; open (my $f, ">", "$_$_/$_"); close $f; }' tst$ mountavfs ls ~/.avfs/tmp/x.zip# ls: cannot access /home/user/.avfs/tmp/x.zip#: No such file or directory A strace shows 30384 sendto(5, "<14>Jun 9 21:22:01 avfs[26671]: UZIP: Broken archive", 53, MSG_NOSIGNAL, NULL, 0) = 53 With x.zip#ext-uzip (on Ubuntu) it works. Also, for fewer zip entries (e.g. 1..10000) the internal handler works too BTW, what is the performance impact of using the external handler? I really need to transparently mount archives, and need an archive format with a central entry table for fast random access (zip and rar are the most obvious choices I guess). |
From: dE <de....@gm...> - 2013-05-13 03:24:19
|
On 05/09/13 18:04, Ralf Hoffmann wrote: > Hi, > > On 2013-03-21 16:04, dE . wrote: >> I've been using avfs to browse tar archives which're burnt directly to >> DVDs. It's been working great except for a bugs I've found out recently. >> >> If there's a large file in a tar archive (no compression), like 5.5G+; then >> on opening this archive via avfs, the large file shows weird behaviour. >> >> For e.g. in one case it was corrupt, in the other (~9 GB file), it's size >> was shown as 16EB. > Thanks for this report. This bug is because of internal variables that > are still 32-bit large thus overflowing for such large files. I'm > looking into it to find a solution. > > Best Regards, > > Ralf Hoffmann > Thanks! |
From: Ralf H. <ra...@bo...> - 2013-05-12 20:23:13
|
Hi, On 2013-03-21 16:04, dE . wrote: > I've been using avfs to browse tar archives which're burnt directly to > DVDs. It's been working great except for a bugs I've found out recently. > > If there's a large file in a tar archive (no compression), like 5.5G+; then > on opening this archive via avfs, the large file shows weird behaviour. > > For e.g. in one case it was corrupt, in the other (~9 GB file), it's size > was shown as 16EB. I have committed a fix for large files in archives. I did not run extensive tests but only for some few but big files and it works so far. Please test the latest git master and report whether or not it works for your files as well. Best Regards, Ralf Hoffmann -- Ralf Hoffmann <ra...@bo...> Homepage: http://www.boomerangsworld.de |
From: Ralf H. <ra...@bo...> - 2013-05-09 18:16:01
|
Hi again, On 2013-03-21 16:04, dE . wrote: > I've been using avfs to browse tar archives which're burnt directly to > DVDs. It's been working great except for a bugs I've found out recently. > > If there's a large file in a tar archive (no compression), like 5.5G+; then > on opening this archive via avfs, the large file shows weird behaviour. > > For e.g. in one case it was corrupt, in the other (~9 GB file), it's size > was shown as 16EB. > > I've tried these tests on a hard drive. I have pushed some patches to fix some of these problems. The corruption came from an overflow problem so reading a file stopped in the middle. That is fixed now. Files in tar archives larger than 8GB needs a slightly different handling, and support for that must be added. I will do this next, but until that, those files are no longer shown as 16EB but zero bytes large. If you want, you can try the git master branch. Best Regards, Ralf Hoffmann -- Ralf Hoffmann <ra...@bo...> Homepage: http://www.boomerangsworld.de |
From: Ralf H. <ra...@bo...> - 2013-05-09 12:39:03
|
Hi, On 2013-03-21 16:04, dE . wrote: > I've been using avfs to browse tar archives which're burnt directly to > DVDs. It's been working great except for a bugs I've found out recently. > > If there's a large file in a tar archive (no compression), like 5.5G+; then > on opening this archive via avfs, the large file shows weird behaviour. > > For e.g. in one case it was corrupt, in the other (~9 GB file), it's size > was shown as 16EB. Thanks for this report. This bug is because of internal variables that are still 32-bit large thus overflowing for such large files. I'm looking into it to find a solution. Best Regards, Ralf Hoffmann -- Ralf Hoffmann <ra...@bo...> Homepage: http://www.boomerangsworld.de |
From: dE . <de....@gm...> - 2013-04-19 17:45:28
|
Hello? |
From: dE . <de....@gm...> - 2013-03-21 15:04:38
|
Hi! I've been using avfs to browse tar archives which're burnt directly to DVDs. It's been working great except for a bugs I've found out recently. If there's a large file in a tar archive (no compression), like 5.5G+; then on opening this archive via avfs, the large file shows weird behaviour. For e.g. in one case it was corrupt, in the other (~9 GB file), it's size was shown as 16EB. I've tried these tests on a hard drive. |
From: Daniel C. <dc...@po...> - 2012-10-02 04:17:59
|
The doc has this as an example for using the http functionality of avfs: /#http:www.inf.bme.hu|~mszeredi|avfs| However when one actually tries to use it, eg: cat $HOME/.avfs/#http:www.inf.bme.hu|~mszeredi|avfs| One gets to the problem that the shell interprets | as the pipe character; and any escaping I've tried doing doesn't help. Doing just: cat $HOME/.avfs/#http:www.inf.bme.hu works fine, so I'm sure that both avfs and the http function are actually working. What's the right syntax to do this? |
From: Serg M. <ser...@gm...> - 2012-06-14 20:12:07
|
This error with configure option --enable-dav -- |
From: Serg M. <ser...@gm...> - 2012-06-14 19:42:52
|
configure error found expat library but could not find xmlparse.h expat installed, slackware 13.37 ------------------------------- xmlparse.h is not a part of Expat anymore. You should get the most recent version of Expat, i.e. the current version from CVS. http://mail.libexpat.org/pipermail/expat-bugs/2002-July/000980.html |
From: Ralf H. <ra...@bo...> - 2012-06-12 20:43:40
|
Hi all, it was quite some time after the last release so I thought of releasing a small update release of AVFS. In this release the xz handler supports more file suffixes and the extfs scripts have been updated to use bash. The hard link count for extfs directories has been fixed as well as compilation for Mac Os. Best Regards, Ralf Hoffmann -- Ralf Hoffmann <ra...@bo...> Homepage: http://www.boomerangsworld.de |
From: Oliver B. <oli...@go...> - 2012-03-01 20:03:36
|
Am 01.03.2012 20:27, schrieb Miklos Szeredi: > Ralf Hoffmann<ra...@bo...> writes: > >> Hi, >> >> On 2012-02-14 13:14, Miklos Szeredi wrote: >>>> Hi there, >>>> >>>> could you look at the two patches attached to this mail? I needed them to build >>>> an avfs package on Mageia. >>>> One of them is actually stolen from Debian, the other one is done by me, but >>>> Debian do have the same one. >>> >>> Thanks for the patches. Committed to CVS. >> >> The CVS is not in sync with GIT so I have committed these patches into >> git as well. > > Thanks! > > I forgot it was already converted to git. Now I've checked out the git > version. > By the way fyi: I submitted avfs to the Mageia repos. It will be available in the upcoming release in may. Oliver |
From: Miklos S. <mi...@sz...> - 2012-03-01 19:27:59
|
Ralf Hoffmann <ra...@bo...> writes: > Hi, > > On 2012-02-14 13:14, Miklos Szeredi wrote: >>> Hi there, >>> >>> could you look at the two patches attached to this mail? I needed them to build >>> an avfs package on Mageia. >>> One of them is actually stolen from Debian, the other one is done by me, but >>> Debian do have the same one. >> >> Thanks for the patches. Committed to CVS. > > The CVS is not in sync with GIT so I have committed these patches into > git as well. Thanks! I forgot it was already converted to git. Now I've checked out the git version. Miklos |
From: Ralf H. <ra...@bo...> - 2012-02-14 20:43:08
|
Hi, On 2012-02-14 13:14, Miklos Szeredi wrote: >> Hi there, >> >> could you look at the two patches attached to this mail? I needed them to build >> an avfs package on Mageia. >> One of them is actually stolen from Debian, the other one is done by me, but >> Debian do have the same one. > > Thanks for the patches. Committed to CVS. The CVS is not in sync with GIT so I have committed these patches into git as well. Best Regards, Ralf Hoffmann -- Ralf Hoffmann <ra...@bo...> Homepage: http://www.boomerangsworld.de |
From: Miklos S. <mi...@sz...> - 2012-02-14 12:14:47
|
Oliver Burger <obg...@ma...> writes: > Hi there, > > could you look at the two patches attached to this mail? I needed them to build > an avfs package on Mageia. > One of them is actually stolen from Debian, the other one is done by me, but > Debian do have the same one. Thanks for the patches. Committed to CVS. Miklos |
From: Oliver B. <obg...@ma...> - 2012-02-08 09:41:52
|
Hi there, could you look at the two patches attached to this mail? I needed them to build an avfs package on Mageia. One of them is actually stolen from Debian, the other one is done by me, but Debian do have the same one. Thanks, Oliver |