#34 Another file contents list issue

closed-fixed
nobody
file scan (7)
5
2012-02-17
2012-02-07
LBob
No

First of all, thanks for your prompt response to my previous bug report and fixing the bug mentioned here: https://sourceforge.net/tracker/?func=detail&aid=3484430&group_id=89530&atid=590426

Now, unless I'm very much mistaken, I think that I've found another bug.

I am talking about the version 1.6, but this time I made tests both on an WinXP SP3 and a 64-bit Debian Sid Installation (note: I didn't compile it myself but rather used the provided 64-bit linux binaries).

After creating a brand new catalog and scanning a test DVD (mostly filled with various archive formats), everything seems to be allright regarding the contents of the archives displayed.

But after I save the catalog, then close the program, open it again and load the previously saved file, all items on the archive file contents list are somehow corrupt (for all archives) - all file sizes are displayed as zeros, and there are no file names, just slashes (/).

I repeated this test several times both on Windows and Linux, with the same result.

Screenshots:

Windows XP:
http://www.imagebam.com/image/0d3e7c173630553
http://www.imagebam.com/image/716be0173630558
http://www.imagebam.com/image/9e54d8173630567
http://www.imagebam.com/image/0ce577173630571

Debian Sid:
http://www.imagebam.com/image/4c6327173630579
http://www.imagebam.com/image/c17928173630587
http://www.imagebam.com/image/1c4da1173630591
http://www.imagebam.com/image/e0cf48173630597

Cheers,

Bob

Discussion

  • Ch. Thielecke
    Ch. Thielecke
    2012-02-08

    • status: open --> open-works-for-me
     
  • LBob
    LBob
    2012-02-08

    "Please try it latest trunk builds:..."

    Will do, thanks for the answer.

    Cheers,

    Bob

     
  • Ch. Thielecke
    Ch. Thielecke
    2012-02-12

    Did you have tried? I cant reproduce here and want to push next version out...

     
  • LBob
    LBob
    2012-02-12

    Yes, I have, and although it still didn't work, I might be onto something. I'm in a bit of a hurry at the moment, but I'll post the results later today (sunday, CET).

    Cheers,

    Bob

     
  • LBob
    LBob
    2012-02-12

    Allright, here we go.

    This time I made a couple of tests (only on a Windows XP SP3 system) which were slightly different. First of all I tried to scan my test DVD, this time using both provided options - first as a DVD medium, than as a CD.

    Both test ended with the same, negative result (by using this description, 'negative', I am referring to the problem I mentioned in my first post within this bug report thread).

    After that I also tried to scan contents of a HDD directory (into which I copied files from one of my test DVDs) - again with the same, negative result.

    Just as a note: during these tests I also noticed the problem which I mentioned in my previous bug report, regarding the archives in subdirectories (https://sourceforge.net/tracker/?func=detail&aid=3484430&group_id=89530&atid=590426), which I characterized as a "regression".

    And then... I noticed something strange about a couple of archives to which I hadn't paid attention earlier - both of them were "gzipped tarballs" (.tar.gz) archives, CREATED ON a LINUX system.

    I was surprised to see that for those archives (all burned within a subdirectory btw.) everything was fine - the contents was displayed correctly, both before and after "saving-closing-opening-reloading" procedure.

    All other archives, "problematic" for me (7-zip, rar, zip, and even some "tgz" archives) were created on a Windows system.

    After that I took another look and noticed something that I had missed before: the column "Rights" in the "archive contents" section.

    I must admit that, during my previous tests I tended to uncheck all program options not particularly useful for me:
    [URL=http://www.imagebam.com/image/64a2ef174436503][IMG]http://thumbnails46.imagebam.com/17444/64a2ef174436503.jpg[/IMG][/URL]

    For that reason I didn't notice this, maybe important detail(s):

    [URL=http://www.imagebam.com/image/0e0b75174434262][IMG]http://thumbnails43.imagebam.com/17444/0e0b75174434262.jpg[/IMG][/URL]
    [URL=http://www.imagebam.com/image/fff616174433370][IMG]http://thumbnails52.imagebam.com/17444/fff616174433370.jpg[/IMG][/URL]

    As you can see in the first picture, everything, regarding archive contents, is displayed correctly EXCEPT for the data in the "Rights" column (this should be related to 'permissions' on linux I assume) with 'question marks'.
    In the second picture, everything (again regarding archive contents) is somehow corrupt or mixed up, EXCEPT for the "Rights" column, which contains newly created information.

    Could the explanation perhaps be that the program tries to retrieve some permissions-related data from the archives, which those of them created on windows do not contain (at least not in "linux terms"),
    and those archives (.tar.gz) created on a linux box do (afaik one of the features of TAR archive format is keeping or storing information related to permissions):
    [URL=http://www.imagebam.com/image/c23ef9174433372][IMG]http://thumbnails64.imagebam.com/17444/c23ef9174433372.jpg[/IMG][/URL]

    Anyway could you look into it, perhaps by making a kind of test I just described - using a compilation of various archive formats, some created in a windows box (zip, rar, 7z) and some on a linux box (.tar.gz) ?

    Cheers,

    Bob

     
  • LBob
    LBob
    2012-02-12

    Hmmm... I scr***d up imagebam links, and don't know how to edit my post.

     
  • Ch. Thielecke
    Ch. Thielecke
    2012-02-14

    I examinited the case again and did as you say. Finally I fixed the bug (r284). The reason was a string calculation problem on lib7zip scanning (tar, tar.gz and tar.bz2 are scanned using libtar).

    Please try http://sourceforge.net/projects/cdcat/files/cdcat/testing/cdcat-svnr285.exe/download it should be working now. You have to scan the archives again, because there is no content in the old created catalog for the broken archive files list.

     
  • LBob
    LBob
    2012-02-14

    Thanks, I'll try the new build later today hopefully or maybe tonight (CET).

    Cheers,

    Bob

     
  • LBob
    LBob
    2012-02-14

    I just made a quick test (WinXP sp3 box, new CdCat install, new catalog), but the problem is still there (except for previously mentioned .tar.gz archives, created ona linux box).

    Just to make things clear:

    - I downloaded and unpacked v1.6 archive into a new folder,
    - downloaded and renamed 'cdcat-svnr285.exe' to 'cdcat.exe' (couldn't find r284 ??),
    - replaced the original '.exe' (from v1.6 archive) with it,
    - created a new catalog,
    - scanned contents of a test folder (from hdd),
    - saved the catalog file,
    - closed the program,
    - opened the program again,
    - loaded previously saved catalog file....

    I am not sure whether I should have done something about the lib7zip library you mentioned (maybe to get a new version) ??

    Today (or better tonight) I don't have time to do a test on a linux box, but I could do it within a couple of days, if necessary.

    Cheers,

    Bob

     
  • LBob
    LBob
    2012-02-15

    Thanks, I hope I'll manage to test the new build this evening.

    Cheers,

    Bob

     
  • LBob
    LBob
    2012-02-16

    I finally managed to grab some time to make a quick test (winxp sp3, build svnr288, hdd directory scan) and everything seems to be allright - the bug appears to be fixed ! Thanks again !

    I hope I'll make a test on a linux box tomorrow or the day after (no promises though).

    Cheers,

    Bob

     
  • Ch. Thielecke
    Ch. Thielecke
    2012-02-17

    • status: open-works-for-me --> closed-fixed