Filename extensions changed ??



  • Just used “PeaZip” to create a tar.gz, using the same path/folder to add, the filename extensions are valid.

    Also, just tried PACL, and it created the archive correctly.


  • conexware

    @peterr:

    I have sent a PM, with all the details needed to create the 2 files, plus replicate the same local directory structure I have.

    thanks - we will check it out and see if we have any questions.

    We didnt mean for you to send confidential data, you could have re-created same filename in same folder and that should have created same error… this will work too.

    thank you!



  • @spwolf:

    thanks - we will check it out and see if we have any questions.

    Okay thanks. I guess seeing the command line versions of PA work, I could use ‘pacomp’ and ‘paext’ in the interim period.

    Thanks. 🙂



  • Something else that PA is doing with archives I created, with the extension .tar.gz

    It makes additional paths in the archive, the paths are not on my local system at all, the archive has all these additional paths , named with a backslash ??

    There were 15 additional paths, in the last archive I created, unfortunately I didn’t see the ‘garbage’ until the archive was used to load part of a website.

    Of course when viewing an archive in ‘flat’ mode, only files are shown, so no pathnames appear. When viewing in Explorer mode, with the ‘2 window’ view, I could then see the additional paths.

    There were 1635 files and 172 folders in the path that was archived locally. However the archive added 1635 files, and 187 folders/paths, the extra 15 wouldn’t even display properly when viewing the archive, but they sure made a nice mess of the website. 😞



  • OK, just done a quick test.

    3 files with 100, 110 and 115 chars in filename.
    Each has “txt” extension (so length is 104, 114 and 119). Files are in sub-Folder with 16 char name.

    Create Tar with PA (no paths stored) - corruption occurs with all three filenames !!

    Create Tar with 7-Zip (relative path stored)- PA displays and extracts this correctly (including pathname).

    Note: no Gzip compression - this is simply TAR.



  • Thanks for doing that test. I also found if I used ZIP compression, the archive was okay.



  • Yes, the problem is with TAR compression.
    Further tests show that even 100 chars corrupt.
    The maximum length that TARs OK in PA 10 seems to be 99 chars (not 110 as suggested by other thread).



  • The 99 max seems to indicate a V7 version of TAR, from a few search results here


  • conexware

    With you guys doing all the work, there is nothing else for us to do…

    😉



  • @spwolf:

    With you guys doing all the work, there is nothing else for us to do…

    😃

    It seems the length limitations is the version of tar that PA must be using. Any chance of going to another version of the code that uses tar files ?? 😉



  • @spwolf:

    With you guys doing all the work, there is nothing else for us to do…

    😉

    Except, analyse why the decompression/extraction failed from the Cpanel backup - that bit has me 😕



  • @TBGBe:

    Except, analyse why the decompression/extraction failed from the Cpanel backup - that bit has me 😕

    I just used PAEXT to extract that Cpanel backup, and there were hundreds of filename extensions messed up, so …

    1. Both PA and PAEXT result in the same type of errors.

    2. Using “7-Zip” on the same archive, no strange filename extensions at all, all the files are okay.

    The code that is used in PA and PAEXT isn’t able to extract all the files correctly, whereas “7-Zip” is able to, … it’s a software thing. 🙂



  • Any idea when this bug will be fixed please ??


  • conexware

    we are working on PAOP beta 2 right now, and then we will move to PA 2007 10.02

    thanks!



  • @spwolf:

    we are working on PAOP beta 2 right now, and then we will move to PA 2007 10.02

    thanks!

    Okay thanks, I don’t know what PAOP is, I checked in my ‘PACL’ folder, but it isn’t there, I thought it must be a command line tool.

    Will version 10.02 include the fix for the ‘extra paths’ problem as well (compressing files for an archive of .tar.gz extension, there has been additional paths found in the archive, with a pathname of ‘backslash’) ?

    Thanks,

    Peter



  • PAOP (Power Archiver Outlook Plug-in)


  • conexware

    we have no idea what will it include until we start working on it :-).



  • @TBGBe:

    Yes, the problem is with TAR compression.
    Further tests show that even 100 chars corrupt.
    The maximum length that TARs OK in PA 10 seems to be 99 chars (not 110 as suggested by other thread).

    Testing with PA 10.10.08
    TAR (tarred)
    90 (including .txt extension) chars OK
    98 (including .txt extension) chars OK
    100 (including .txt extension) chars OK
    106 (including .txt extension) chars NOT OK

    • Displays OK but error when extracting


  • Sorry, that was misleading.
    There is something strange going on -
    Create a test Folder containing filenames of different lengths
    I used 7 files (98 chars to 105 chars).
    Length of 103 was correct.
    98 to 102 were corrupted to be 103 chars (4, 44, 444, 0444, 00444 was added to extension .txt)
    104 and 105 were corrupted by addition of the string “0000002” to the extension (both files).
    :eek:

    So the result was
    a) {longfilename}.txt00444
    b) {longfilename1}.txt0444


    c) {longer filename}.txt0000002
    d) {longer filename1}.txt0000002
    😕



  • @spwolf:

    we have no idea what will it include until we start working on it :-).

    I see 10.1 beta is out.

    At this stage, do you know if 10.1 final will include the bug fixes for …

    1. The filename extension problem as explained in this thread.

    2. The “additional pathnames” bug/problem.

    Also, thanks to Terry for doing some more testing. I was about to download a website backup toay, and then remembered about this filename extension problem with .tar.gz files. 😞



  • The website backup was uncompressed to a local path, and there was a ‘mix’ of file extensions that ended in …

    0000444
    0000644

    I went and checked on the website, and it does match the file permissions (Linux box as server), so if that is of any help ?

    In one path that was uncompressed/extracted, I can see where the ‘limit’ is. The pathname is 110 chars, including the volume number and all backslashes, and the filename extension has only been changed for 3 files in that path. Here is an example of one file that has no change to the extension, and one file that has the extension changed, as follows:

    daily_usage_200610.png –-> daily_usage_200610.png
    hourly_usage_200610.png --> hourly_usage_200610.png0000644

    The one extra character (the difference between ‘daily’ and hourly’) blew the limit.

    The total size, of the file, at the “max” (daily_usage_200610.png), including full pathname is 132 bytes.

    HTH



  • I just installed the latest PA, version 10.10.10 and this filename extension problem still exists. :mad:

    I didn’t restart after the install, there was no message to do so.


  • conexware

    @peterr:

    I just installed the latest PA, version 10.10.10 and this filename extension problem still exists. :mad:

    I didn’t restart after the install, there was no message to do so.

    yeah, this will take longer since we have to add support for longer file+path in tar files… we had some priority fixes for 10.1



  • @spwolf:

    yeah, this will take longer since we have to add support for longer file+path in tar files

    I wonder how 7-Zip does it, because from memory, it handled the longer file+path’s okay.

    @spwolf:

    … we had some priority fixes for 10.1

    … and here I was, thinking that I would be top of the list. 😃


  • conexware

    this will probably make it into 10.2, working on it now…



  • Thank you. 🙂


  • conexware

    And it did :-).

    Please check with Beta 4:
    http://www.powerarchiver.com/test/release10/powarc1020.exe

    Please let us know if this fixes this issue as soon as you can.

    thank you!



  • The filename extension problem still exists. 😞

    Also, when I extracted the archive, in addition to it creating the main pathname and all files and paths underneath that, it also created some other weird pathname, with 19 folders and no files when extracted.

    The archive was large, PA is reporting 5032 files, 625 directories and 13,476,762 bytes.


  • conexware

    can you send us the archive so we have it for testing? Just compress it with 7zip (tar file itself) and upload it to some free uploads site? Is that ok?

    That would be very helpful….

    thanks!



  • @spwolf:

    can you send us the archive so we have it for testing? Just compress it with 7zip (tar file itself) and upload it to some free uploads site? Is that ok?

    Sorry, no can do, it’s a website backup and has a lot of confidential files in it.

    I also used PACL to extract the same archive, guess what, same results, that is, lots of files created with the filename extension changed. This didn’t happen before with PACL, at least I don’t think so ??

    I did a binary compare on the PA extract compared with the PACL extact, all files matched, but PA didn’t create a number of paths where there were no files, … sound familiar.

    I may try some other archive tool tomorrow, on the archive.

    Once again, the ‘pattern’ of the filename extensions is that the (cmod) permissions from the website, has been appended to the fiename extension.

    Looking at one file that has had the extension changed, the pathname is 133 bytes, and the filename plus extension is 18 bytes, that makes 152 if we add the extra backslash.

    The filename, plus extension is meant to be 11 bytes (modinfo.php), and there is another file in the same path that is a total of 10 bytes (index.html), which hasn’t had the extension name changed.

    See attached screen dump of that path.

    Also when I open the archive, PA seems to be showing the file extensions incorrectly, that is, the same as the screen dump.
    attachment_p_12680_0_pasd001.jpg


  • conexware

    cant you compress non-confidential parts of the website and send them over? I am sure you can recreate same behaviour without using files that you dont want to send us… 1 file is enough.

    thanks!



  • The archive is automatically created from cPanel, I just hit the “create full backup” button.

    I will see about trying to create an archive of ‘parts’ of the site manually, but please don’t hold your breath. 😃


  • conexware

    what about just deleting parts of the archive that are confidential and leaving few files that are fine? you can send it to us at support so it wont be for public viewing…

    thanks



  • I’m not about to sort through 5032 files, and remove all the confidential ones.

    As I said, …. it will take a while.



  • Have sent you a test archive. 🙂



  • Installed version 10.20.17 , and unfortunately, this problem is now worse. 😕

    Instead of just a few files that had the filename extension changed. there are now over 80 files (same archive used for testing), and the ‘filename’ (including the extension) has now been truncated. I checked 5 files, and they are all truncated at 145 bytes (includes full pathname and extension).

    What is strange, is that when I shortened the length of the path used to extract, exactly the same problem occurred, that is, the same number of filenames are corrupt.

    I would have thought decreasing the size of the (full) pathname, would have resulted in less errors found in the filename.

    When I increased the size of the (full) pathname, and did the extract again, the filenames are now truncating at 151 bytes (145 + 6).

    There don’t appear to be any filename extensions changed this time, just the truncation problem, but the problem is not consistant with the pathname length, and the same filename results, irregardless of the pathname length.

    Here is an example, showing the correct filename, total size is 146 bytes …

    F:\temp\powerachiver…\class\smarty\internals\core.assemble_plugin_filepath.php

    ======
    When the full pathname is increased in size by 8 bytes, the filename is truncated at 145 bytes …

    F:\temp\powerachiver…\class\smarty\internals\core.assemble_plugin_fil

    When the full pathname is increased in size by 6 bytes, the filename is truncated at 151 bytes …

    F:\temp\powerachiver…\class\smarty\internals\core.assemble_plugin_fil

    When the full pathname is decreased in size by 22 bytes, the filename is truncated at 129 bytes …

    F:\temp\powerachiver\….\class\smarty\internals\core.assemble_plugin_fil

    In all cases, the same filename results, a truncated name, and in all extracts, exactly the same number of errors have occurred (approx. 80 files with filenames truncated).

    ‘spwolf’ has the same test archive, and will be able to see what the extract is doing.

    When the archive is being viewed, the filenames appear to be okay, it is just some weird problem with the extract. 😕


  • conexware

    Please try with .21 from our website and see what happens.

    thanks



  • Installed .21 , and ran the extract again, … same problems unfortunately.

    Just extract the test archive I sent, and you will see where filenames have been truncated. 😞



  • Has there been any progress on fixing this bug please ??


  • conexware

    Try 10.21 RC 1 from our site and see if it works.



  • @ivan:

    Try 10.21 RC 1 from our site and see if it works.

    Can you supply a link please.

    Also, this bug was reported over 6 months ago. I’d really expect it to be fixed by now, and not have to rely on “user testing” of new releases, especially when I went to the trouble of creating a website with various files, then created a website archive, and sent it to PA tech personnel, so they can test it.


  • conexware

    did you use RC1? (10.21.xx) or 10.20.21?

    🙂

    Check RC1 from download page please.



  • Have downloaded and installed the RC1, thanks.

    I have only checked a few files, especially the ones that were noted in the earlier post, and they are now okay.

    Will create a larger archive and extract that, and then advise.

    Thanks. 😃


  • conexware

    🙂



  • Well, the filename extensions seem okay, plus the filenames (and paths) look okay, but the modified time of the files don’t seem to reflect what the timestamps should be (I will have to look more into that).

    Also, for some reason, PA displayed a “ghost” folder, one that isn’t on the website, called “the.same.host.name;”, see screen dump.
    attachment_p_13176_0_pa_view1.jpg



  • Two other minor annoyances with the interface, is that when using the “2-pane” view, the folders are not sorted, makes it a real pain for navigation (see screen dump).

    Also, there needs to be a horizontal scroll bar added to the left hand pane/window, as often the 'folder depth" is more than the width of the left hand window, and therefore, folder/path names cannot be seen (see screen dump).
    attachment_p_13177_0_pa_view2.jpg
    attachment_p_13177_1_pa_view3.jpg



  • Yes, timestamps of the extracted archive are definitely a problem. Will have to look into it further, and then advise. 😞



  • Two apologies. :o

    @peterr:

    Also, for some reason, PA displayed a “ghost” folder, one that isn’t on the website, called “the.same.host.name;”, see screen dump.

    PA displayed that folder correctly, I ran the archive through “tar”, and the folder was there, fortunately on a PA extract, it just ignored the folder name.

    @peterr:

    Yes, timestamps of the extracted archive are definitely a problem. Will have to look into it further, and then advise. 😞

    I was baffled by the timestamps, because in some cases, the date (day) was different to the file date on the server.

    Took me a while to realise it was adjusting the timestamps of files, to reflect the timezone, even had to extract the archive on a *nix box and run “tar” to make sure it wasn’t a Windooze thing.

    There is a 15 hour difference in timezones, between here and the web server, and in many cases, the file date was the next day, … hence the confusion. 😕

    So, timestamps of the extracted archive are definitely NOT a problem.

    Please accept my apologies.


  • conexware

    we added scroll bar to the archive folders bar, so it should work fine now. Please check with RC2 from our download page.

    thanks!!!



  • Okay thanks, I’ll try it out.


Log in to reply