creating a 7zip gives error

Thank you for your bug. Does it happen if you compress one file? I don't confirm the issue on my gutsy installation. What filesystem do you use?

It was happening every time I compressed files in 7zip with any assortment of file types and groups. But, it seems to work fine now. It must have been fixed when something else was fixed.

My guess is that we can close this bug. And just in case, I am using EXT3.

closing the bug then, feel free to reopen if you get the issue again

Unfortunately, I do still encounter this bug in Ubuntu Gutsy with either p7zip or p7zip-full installed.

The output in my case is logically the same as shown in the initial bug description. file-roller first creates the archive and adds the files and then tries to do this update that produces the message-box with the text "System error: E_NOTIMPL". The archive file, however, is complete.

Reinstalling file-roller or the p7-related packages does not solve this problem.

It may have something to do with the number of files to be added to an archive. Some of directories ALWAYS produce this message-box when compressed to 7z using file-roller, others NEVER produce this message-box.

I wonder if either file-roller or 7z work in a different way for few or many files. Anyway, this message-box never appeared when I was using Feisty.

could you describe easy steps to trigger the issue or attach an example?

Unfortunately, the folder that reliably leads to this error message contains business data so I cannot attach it here, but I am still trying to find/setup a folder with arbitrary data that leads to this error message, too.

It seems to have something to do with the number of files and the directory structure of the folder to be compressed. I am using file-roller in conjunction with 7z to archive folders that contain Java projects. Java projects naturally do have a deep nested directory strucure with many short files. One folder contains ~1500 files, another one contains ~2500 files. Both result in that error message when compressed. A folder with just 1000 text files and no subdirs, on the other hand, works fine.

Okay, I have finally managed to create a test case.

The attached 7z-archive contains a folder called "files" with three sub-folders called "folder-1", "folder-2" and "folder-3". Each of those folders contain 1500 short text files. That is a total of 4500 text files.

To produce the mentioned message box, please make sure that either "p7zip" or "p7zip-full" is installed. Then, download the attached 7z-archive to any folder, e.g. the desktop, and uncompress it using the context-menu and the respective "extract here" menu item. This will result in the folder "files" to be created on the desktop.

Next, use the context-menu and the respective "create archive" menu item on that folder to compress it again. Choose a different name and ".7z" for the archive's type. The expected but irritating message box should appear after archive creation.

The attached screen-shot shows the message box on an Ubuntu/gutsy (de) after the re-creation of the 7z-archive.

I just tried CKX's test, and it gives me the same error. Re-Re-Re-Confirmed

reproduced here, using the command line utils works fine. will forward upstream, thanks.

I've sent this upstream at: http://bugzilla.gnome.org/show_bug.cgi?id=500494

confirm again, using 7z in bash, same error.

this error has some connection with "some sort of" file.
THE file can't be update, but if you extract it & re-7z it again, it works, but still can't update it.

Is there any word on this? It's been nearly 7 months since the initial bug report here, over 5 months since the bug was added to bugzilla.gnome.org, a whole new release of Gnome and Ubuntu, and yet it's still listed as "unconfirmed" and has had no activity whatsoever.

Has this really not been fixed or even looked at in all this time or is there activity happening elsewhere and the bug report itself has merely been forgotten?

there is way too many bugs for the number of people working on those so the work has to be prioritized and this one is a small issue so it's likely nobody has been interested to work on that yet

I confirm this bug. I am getting file-roller stalled with error "Incorrect command line" when I tried to make 7z-archives from files in the folder named like this - "text text 123". I am thinking, those spaces between words make such effect. It is concerned to Russian file names and English too. In console everything goes fine, all spaces there in console are prefixing with \ (backslash) as usual.

same problem here, I have the same issue in console and file-roller

Confirm. (8.04.1 64-bit)

Confirmed for Ubuntu 8.04.1 32-Bit, and as for Sebastien Bacher, I consider your answer pretty arrogant.

Generally I would say, If an implemented feature does not work, leave it out until it works, but do no not put it into a so-called "long term support" version - unless you wish to say that "long term support" means you will need support for a long term.

Please give us a precise reasoning why you think this a "small issue" which deserves low priority only - something with an understandable reason beyond your personal opinion.

the bug is low priority because that's only one compression format and users have lot of other alternatives they can use, that's not the most used format and few users complained about the issue

Please tell us which are the alternatives users can use. zip presently cannot handle large files (see https://bugs.launchpad.net/fileroller/+bug/70846), .tar.gz is considered rather unsafe and outdated (see wikipedia), and various other formats have issues, too (see https://bugs.launchpad.net/ubuntu/+source/file-roller). To my present state of knowledge, Ubuntu features not modern, reliable archiving method at all.

Apart from that, I consider it pretty arrogant to just say "go use something else". According this method, you could just tell every bug filer to go use another operating system, right? Your method of constantly telling users that bugs are actually none or not important (see other projects) is something I would consider rather inadaequate.

Also see https://bugs.launchpad.net/ubuntu/+source/file-roller/+bug/90328 - apparently errors during the package process can lead to other major problems.

Please reconsider your priority settings. Thank you.

don't specify the version in the title, that creates confusion and it not useful and stop calling people arrogant that's not really a constructive behaviour there

could you also stop discussing settings, what difference would it make if this bug was changed to medium for example? there is some thousand desktop bugs open in launchpad and a bunch of people working on those, that's not bad willing but there is just no way to work on everything immediatly

nobody told you to go use something else, but a bug which prevent doing a task will be consider higher priority than one which is annoying but can be worked around easily

you have valid points that file-roller is buggy but the ubuntu team doesn't write the software and doesn't have the ressources to fix all the bugs in all the available software, do you have a better software suggestion?

what about trying to be constructive there? nobody denies there is a bug there and it's annoying, bugs just have to be triaged and prioritized so the focus can be given to bugs which annoy lot of users or make some machines not usuable

you can also read https://wiki.ubuntu.com/Bugs/Importance about the importance setting, this bug has a moderate impact and can be workaround, the settings used are those recommended

I just had the error popup on my desktop...I was using file-roller to make a .7z archive and as others have said it make the archive just fine until it checked it:
I'm using ubuntu 8.04 Hardy Heron with gnome
Here is what I got -

Everything is Ok
7-Zip (A) 4.57 Copyright (c) 1999-2007 Igor Pavlov 2007-12-06
p7zip Version 4.57 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,1 CPU)

Scanning

Updating archive /home/r00t/r00t.7z
System error:
E_NOTIMPL

Until this issue is fixed, I've been using Nautilus Actions (available in Synaptic) and a simple action that uses 7z directly, available at <http://www.grumz.net/?q=node/337>.

Be aware that this "Add to 7z" action creates a 7z archive named after the first file selected, and if you subsequently make another 7z archive with the same name in the same directory, the first archive will be overwritten.

In addition, I use another action that tests 7z archives to ensure they don't have errors. This action is available at <http://www.grumz.net/?q=node/338>.

I debated whether to make this available here or not because, while it no doubt will help people who run into this bug, it may make this bug's priority even lower than it already is; I'm hoping it won't.

1) - Has there been any progress on this issue?
2) - Is there an automatic connection between Launchpad and Bugzilla, or are these discussions here all in vain unless someone once more forwards this?

there is no automatic comments forwarding no, if upstream doesn't read the launchpad bug it'll not get those new comment, that's why it's better to discuss upstream bugs on bugzilla.gnome.org directly

How does one know wether an issue is an "upstream" issue or an Ubuntu issue?

there is no trivial way, you need to figure if the issue is due to an ubuntu specific change or to upstream code, usually the ubuntu packages have little code changes over upstream and the vast majority of bugs are upstream ones, if the bug has been sent to the upstream bug tracker you can assume that's because that's an upstream one

I get following error, while trying to create any .7z archive. but it's not a bug in the p7zip packet, because I can create working .7z archives with the command line tools. So I think the file-roller uses the tools somehow wrong, because of maybe api changes.

7-Zip (A) 4.57 Copyright (c) 1999-2007 Igor Pavlov 2007-12-06
p7zip Version 4.57 (locale=de_CH.UTF-8,Utf16=on,HugeFiles=on,1 CPU)

Error:
Incorrect command line

1) - Has there been any progress on this issue?
2) - Is anyone going to deliver this to the developers?

no need to copy the same question on several bugs, you have the upstream task listed on launchpad

Sorry, didn't see that.

I am not able to create 7zip archives with file roller if the path containing the file to compress has one or more spaces in it.
Does this issue have to do with my problem, or I have to report a new bug? Other archive formats work well in this case.

ramas:

On jaunty, I tried compressing a path(with spaces in it) using the file roller(to 7zip), and got no error.

I had a same problem on hardy with p7zip 4.57 when compressing large amount of small files. After upgrading p7zip to 9.04beta bug has gone.

I'm getting the same error in Jaunty that the original poster described (System error: E_NOTIMPL). I'm using an ext3 filesystem (if that matters) and I just ran a check, this does not occur for me with p7zip installed, only when p7zip-full is installed. It only happens when I am editing a text file that is zipped, save the file in the word processor and then update the archive when prompted. Hope this helped somehow, but it seems the error is a little different for everyone based on the posts here.

Works fine with latest file-roller, are you still getting this issue?

Closing the bug as no further information has been provided.

Cannot reproduce on Lucid nor Maverick. Everything works as expected. Compared to previous releases, Lucid and Maverick use newer release of p7zip, compared to Hardy and earlier where the bug was first observed.

Therefore I'll mark this as fixed.

Bug is still present in natty when using -so. Try this with the test files:

7zr a dummy -so files/ > /dev/null

7-Zip (A) 9.04 beta Copyright (c) 1999-2009 Igor Pavlov 2009-05-30
p7zip Version 9.04 (locale=es_ES.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)

Scanning

Updating archive stdout

System error:
E_NOTIMPL

Still present in cosmic.