Version: 2.12 (using KDE 4.2.4) OS: Linux ark, compression is not as it should, sometimes certain folder that is in 5th position is reflected archive has position 1 Reproducible: Sometimes Steps to Reproduce: to reproduce the bug must unzip the file: zark-good.tar.gz which has been compressed with another program, and then compress the file with "ark" Actual Results: the folder alllll/fichiers/images(CHEZ.COM) alllll/fichiers/images(TRUC.COM) alllll/fichiers/(noftp)/google-photos has a position so that one should be in position 4 attach the file to work properly it has been compressed with "file roller", to see the bug must unzip the. tar.gz, and recompress it with "ark"
Created attachment 51112 [details] to see the bug must unzip is file attach the file to work properly it has been compressed with "file roller" , to see the bug must unzip the .tar.gz , and recompress it with "ark"
The order of the folders is incorrect only when you add the 'zark-bugg' folder in Ark, right? When you close Ark and reopen the archive the files and folders are listed in the right order, can you confirm that?
no, there is nothing to do this does not change, I do not if it is just the folder name is "(" ")" because this bug does not occur every time it may be the file contents so
Can you post a screenshot of your Ark window with the folders expanded right after you add the "zark-bugg" folder and after you close Ark and open your generated archive?
Created attachment 51144 [details] here is the exploration of the compress file here is the exploration of the compress file
then?
Then we haven't had time to look at it yet ;) The problem you've mentioned seems to be in the tar ioslave, not in Ark -- the screenshot you've posted is not from Ark. I'm still not sure where the problem is exactly, though.
Hello, and thank you for bringing this to my comment made on well yes I put a screenshot of "dolphin" kde browser, but I think it was what you asked, because I did what you told me I opened the archive with " ark "and" ark "works perfectly it does not delete my file or move a file, even after having unzip an archive that bug probably because of the browser, the archive is again as was originally so for me the problem is solved thank you
Hmm, I'd rather keep this report open, as we need to check whether the tar ioslave (what you used in Dolphin to view your archive) is really misbehaving here.
Let me comment here before I forget these notes somewhere else: the problems seems to be that the tar ioslave (actually, KTar itself) does not support tar files in the "ustar" (POSIX-1998) or "pax" (aka POSIX-2001) correctly. The original tar format only supported file name entries with at most 99 characters. GNU tar came up with some extensions for the file name length, such as the "././@LongLink" hack supported by KTar, which used areas in the tar header previously unused by the POSIX standards. However, when POSIX finally standardized the ustar and posix/pax formats later, all these headers ended up being used. Apparently, KTar only correctly supports tar archives compressed in the "v7" and "gnu" formats. Since file-roller simply invokes the command-line tar utility with the usual options, the archives it creates can be correctly read by KTar, as it seems that the format chosen for long file names by GNU tar is "gnu" in this case instead of "ustar" or "pax". Ark (and bsdtar) use libarchive, which behaves differently -- by default, a standard "ustar" file was created, and it wasn't read as expected by KTar because the archive from the original bug reporter contains file names which are too long. Long story short (no pun intended ;) -- KTar needs to support newer tar formats.
Created attachment 51301 [details] Opening with "ark" and "dolphin" ok I understand, I am at your disposal if you wish me to do tests, I'm not a software developer so I understand not much in it these bugs and technical explanations but on reflection I forget something because I rush to close the file, I did say that "file roller" was ok when I open the archive using "dolphin", but with "ark" to move back are the error is the same on "dolphin" and "konqueror"
Raphael: do you plan on fixing KTar? Otherwise, please post a sample TAR file which does not work with KTar, if you want me to have a look.
Created attachment 51841 [details] Sample file which shows the problem in the tar ioslave.
David: I can try to fix KTar, but that means either duplicating low-level code present in libarchive, GNU tar and other programs/libraries that read tar files, or start depending on one of those. Either way, I've attached a sample file that does not work with KTar, and we can hope one of us fixes this bug before the other :)
Just as an FYI, since I was poking at bug 252821... using the tartest command from the star package says the sample tar file is posix-compliant, at least... --------------------- robby@homebase:~> tartest < sample-file.tar tartest 1.12 (x86_64-suse-linux-gnu) Copyright (C) 2002 Jörg Schilling This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Testing for POSIX.1-1990 TAR compliance... Found 1st EOF block at 449 Found 2nd EOF block at 450 No deviations from POSIX.1-1990 TAR standard found.
Can anybody still reproduce this bug? As Raphael mentioned in comment 10, the ioslave would need to support newer tar formats, but I haven't been able to find any commits which would have done that so I expect that the issue does still exist. If that's the case, I'd need to move this over to kio-extras, because this product is now deprecated.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!