64-bit math support for large disks

BSzili
2014-02-26
2014-05-27
<< < 1 .. 7 8 9 10 11 .. 14 > >> (Page 9 of 14)
  • BSzili
    BSzili
    2014-04-16

    @kas1e
    That sounds like a really bad idea, unless you wish to trash the 8 bytes after FIB in the memory. struct FileInfoBlocks are cast to FileInfoBlock64, you can't just add fileds larger than the original FIB.

     
  • kas1e
    kas1e
    2014-04-16

    @BSzili
    Probably better to wait xenic, maybe he can deal with. I tryly suck with such low-level stuff, and can only borks everything.

     
  • BSzili
    BSzili
    2014-04-16

    @kas1e
    Trashing the memory after a stack allocated structure is guaranteed to result in an unstable program, which fails randomly. I'll leave solving this the way you think it's the best (ie. copying examinedata, or creating a brand new structure, etc.). I'll comment out the fib_Reserved usage, and temporarily disable the 64-bit DOS support to leave the program in a consistent state.

     
  • BSzili
    BSzili
    2014-04-16

    @all
    Or a third method: putting the high 32-bits of the size into fib_EntryType. This is an unused legacy field (discussed in great detail before, verified by the OS4 devs, and so forth). This requires the least changes, and it's backward compatible. I might still do this so I don't leave a mess behind me. This FIB trickery was my idea after all.

     
  • kas1e
    kas1e
    2014-04-16

    @BSzili
    If you have still motivation for it, then yep plz, let's try third method.

     
  • xenic
    xenic
    2014-04-16

    @all
    Let's not panic and start rewriting code before we know the real problem. Colin is a really smart guy but he is totally focused on OS4 and will always advise that things need to be done the OS4 way only. There are some other things we need to consider:

    kas1e said the was double-clicking on the ram icon to get a lister. Then he posted "list" command output that showed the ram icon was a broken link. I'm clicking on the ram: device in a "name" lister; I don't use the icon display for my listers. It's possible that Dopus5 isn't handling icon links or broken icon links properly, which is screwing things up in other parts of the program.

    When kas1e posted his original debug output, the debug output size numbers for his Work: partition were bogus there too. However, he stated that listers were working correctly for normal partitions. If he is correct about that and seeing correct numbers in listers showing normal partitons then there must be another explanation for the bogus numbers in the debug output. It's possible that something has gone wrong in OS4 DebugPrintF() or the serial port output isn't handling 64bit numbers correctly. My debug output is in a Sashimi console window, not through the serial port to another computer.

    Let's start off by each of us describing how we are running Dopus5. I'm running Dopus5 on it's own screen with "name only" listers (no icons in listers). I am not using it in WorkBench replacement mode. kas1e stated that he was double-clicking on the "ram" icon. Since I have the makelink line commented out in my startup sequence, there is no "Disk.info" in my ram: and WorkBench is supplying the default ram icon on the Workbench screen. There is no ram icon on the Dopus5 screen.

    @kas1e
    I suggest that you comment out the line in your startup sequence that creates the link to def_Ram.info so we can debug this without links involved. You need to copy some normal files to ram: so we can see if Dopus5 is getting a good ram: lister without that icon link. In the meantime, I am going to uncomment my def_Ram.info makelink command in my startup-sequence to see if that makes any difference in my ram: lister display.

     
  • kas1e
    kas1e
    2014-04-16

    @xenic
    i also running dopus5 as you run it. i.e on its own screen,etc. i also tried to delete disk.info from ram (its not broken btw, its have link to envarc blabla defram.info), and still same problem. ie pure T and Clipboard dirs. i even post debug log previously where i remove that link. dunno what to think, but bogus numbers sure strange. they bogus even on working partitions. maybe some beta kernel .. what version of kernel you use now ?

     
  • BSzili
    BSzili
    2014-04-16

    @xenic
    Being focused on OS4 or not, if the fib_Reserved field is already used on OS4 to store some context, then it's not a really good idea to destroy part of it. I do not intend to rewrite anything, my change only affects a couple of places which directly access the fib_Size64 field (mainly 64bit.c), the rest is covered by the GETFIBSIZE macro.

     
  • xenic
    xenic
    2014-04-16

    @BSzili
    O.K. I'm not the one making the changes so do whatever you think is right.

     
  • xenic
    xenic
    2014-04-16

    @kas1e
    Version for my SYS:Kickstart/kernel is: kernel 53.58 (09/27/2013).
    You can compile this and see if your debug output is handling 64 but numbers:

    /* gcc bugout.c -o bugout -lauto */

    #include <proto/exec.h>
    #include <exec/types.h>

    int main(int argc, char**argv)
    {
    uint64 bignum = 5808611922LL;
    uint64 smallnum = 32123123LL;

    IExec->DebugPrintF("64 bit number in 64 bit variable is: %lld\n", bignum);
    IExec->DebugPrintF("32 bit number in 64 bit variable is: %lld\n", smallnum);
    }

    It prints the correct numbers in my Sashimi console window.

     
  • kas1e
    kas1e
    2014-04-17

    @Xenic

    There is output from your test-case on serial:

    64 bit number in 64 bit variable is: 5808611922
    32 bit number in 64 bit variable is: 32123123
    

    Looks right imho.

    I think the problem i get (i hope), can be related to that : fib_Reserved is used for holding context of emulation calls (Examine, ExNext, and all old legacy funcs). Once we reuse it for our needs, it got destroyed, and just (by some strange luck) , do not works on ram partition (as for ram there is another handler involved, which works closed with dos.library as well). You and BSZili probably did not have those bogus number and bug itself just because memory/stack layouts on all machines different. On your x1000 it for sure different. And, probably structure somehow didn't corrupted by luck on your setups, but did on my.

    Probably if BSzili will go his new way and reuse fib_EntryType instead of fib_Reserved all can be ok. But even if not, its still will be better to reuse fib_EntryType which are in no use , while for fib_Reserved Colin cleary says it used for holding dos emulation context.

    Imho of course.

     
    Last edit: kas1e 2014-04-17
  • kas1e
    kas1e
    2014-04-17

    @All
    I ask Colin if we could reuse that obsolete field (fib_EntryType), and he says that nope, because whatever is filling out the FIB will overwite your data. All additions have to be placed outside the V40 definition fields. He advice again that better go with "struct ExamineData" way to make all be 100% ok.

     
    Last edit: kas1e 2014-04-17
  • BSzili
    BSzili
    2014-04-17

    That is gobbledy gook. If you take a look at the sources, then you can see that we are the ones who are overwriting that field after it has been filled out by Examine.

     
  • kas1e
    kas1e
    2014-04-17

    That is gobbledy gook

    :))

    then you can see that we are the ones who are overwriting that field after it has been filled out by Examine.

    Oki, i just throw what he says just in case. I mostly ask if he use it for something else like fib_reserved, but he says nothing about, only that what i quote, so probably for us its only prove that its all ok to do what we want to do then.

     
    Last edit: kas1e 2014-04-17
  • BSzili
    BSzili
    2014-04-17

    @kas1e
    Since he didn't look at the source code, he cannot know what exactly are we doing.
    I ran into an interesting problem yesterday, for some reason the compiler decided to truncate the integer from 64-bit to 32 somewhere in the process. For this reason I can't commit my changes at the moment. Interestingly the same code works outside DOpus5, compiled with the same opmization flags.

     
  • BSzili
    BSzili
    2014-04-17

    @all
    I got a couple of hours at home, and committed part of my fix. I'm not done, so please be patient.

     
  • BSzili
    BSzili
    2014-04-17

    It looks like I was a too pessimistic about the change. The safeguards added in previous commits fixed the issues before they could happen. Feel free to test the new version if it breaks anyting.

     
  • xenic
    xenic
    2014-04-17

    @BSzili
    I'm not going to argue or disagree with your plan but feel compelled to add some comments. Now that kasle has informed Colin about our use of reserved and obsolete elements of the FIB structure, I think it's likely that Colin will make sure that our unorthodox methods won't work in the next release of AmigDOS library. Colin always insists that programmers obey the rules applying to OS4 AmigaDOS and could go out of his way to enforce the rules. To avoid that possibility, I suggest the following:

    #ifdef the FileInfoBlock64 structure so that for OS4 it's defined in the way Colin suggested (with the 64bit elements added to the bottom of the FileInfoBlock structure) and defined the way it currently is for other the other platforms. All FIB allocations or declarations in Dopus5 would be changed to "struct FiliInfoBlock64". Due to the #ifdef for FileInfoBlock64, all platorms except OS4 will be getting a FIB that is the same size as the AmigaDOS defined FIB, while the OS4 FIB will contain the added 64 bit elements.

    The only place that the above suggestion will not work is if the FIB is embedded in an AmigaDOS defined structure like "struct AnchorPath". Since the only embedded FIB I can find in Dopus5 is in AnchorPath, only MatchFirst64()/MatchNext64() will be negatively impacted by the above changes. As far as I can tell, the only place that files sizes are being accessed with MatchFirst64()/MatchNext64() is in function_files.c function_get_entry(). The are only 3 GETFIBSIZE uses in that function and we can find somewhere else to stick the 64 bit size for OS4 (possibly the currently unused handle->recurse_entry->size element?).

    it's up to you how you do it and my suggestion is just that; a suggestion. Do it however you want.

     
  • BSzili
    BSzili
    2014-04-17

    @xenic
    If you read what Collin actually said about fib_EntryType (fib_Obsolete), then all he stated was that it's going to be overwritten by the filesystem handler to match fib_DirEntryType or zeroed. This in no way affects us, because we are overwriting this field after Examine was called. You have nothing to worry about.

     
  • xenic
    xenic
    2014-04-17

    @Xenic
    I think reasons to split 64bit macro, its just to avoid on os3 to call new functions at all. I.e. to avoid even that small unnceessary overhead. Because for os3 if we wil not disable 64bit dos files support, then we will call functions in dopus5.library, as well as those called functions will have some additional checks and copy of few bytes, and only then call original os function. Of course is not that important, but then classic hw is pretty slow, so maybe worth to have it ? I mean why it make slower than original, if there is no needs for.

    I.e. 64bit disk support are fine and need, but enabling 64bit file dos support for os3 will only add a little overhead without needs.

    I mean, original: just call Examine()
    Our now: call dopus5.library's ExaminLock64(), which do checks, copy, and call original Examine() -> overhead which is not need it.

    @BSZili
    Tried yesterday, but there also was some tricks with allocation of fibs, which i also rewrite, but in end all what i got, is that after dos-patches do refresh of lister, instead of randomsize i have "empty". Probably miss something trivial..

     
    Last edit: kas1e 2014-05-01
    • Although I am absolutely not involved with the development of DOpus5 and I am full with other
      projects I still try to follow the discussion here as far as possible.

      Why are you trying to put a load on a structure which cannot carry the weight for all systems? Since
      you IIRC decided already to drop support for old plugins, why don't you just design a new common
      directory scanning API for all systems as a kind of new frontend, rather than bending the API of one
      system beyond its limits until it fits all other systems? The backend then uses the most appropriate
      native implementation for each system. A system like AmigaOS3 cannot provide 64bit file sizes at
      all, nor can it handle files of that size at all. But it can cast its 32bit file size values from
      the known old FIB structure to a 64bit value in a new common structure. The same applied for
      AmigaOS4 and MorphOS. That way you don't have to abuse any system private fields but start with a
      clean API from scratch.

      Thus for AmigaOS3 you use the old FileInfoBlock structure, for AmigaOS4 you use the new ExamineData
      structure and for MorphOS (AROS as well?) you use the extended FileInfoBlock structure. Just extract
      all the necessary data and place it in the common structure of the new API. That way you hide the
      specialities of each system in a private backend.

      Just my two cents...

      --
      Thore Böckelmann
      Rehmerloh, Germany

       
  • BSzili
    BSzili
    2014-04-17

    The answer is really simple: I choose the solution that required the least amount modifications and OS-specific code. Anybody who is bothered by this, is free to write separate directory scanning code for AmigaOS4 (including all the recursive functions), and modify every single structure in DOPus5 which uses FIBs internally (believe me, there are plenty of them). BTW, SFS2 for AmigaOS3 does support 64-bit file sizes using the AmigaOS4-style packets.

     
  • kas1e
    kas1e
    2014-04-18

    @All

    Good news: i grab build from dopus5.org, tested and ram: partition opens fine now! No eating of memory, yeah !

    Through, my output still looks like this:

    RAM:

    [64bit.c:236 L_ExamineLock64] Got 64-bit size for def_ram.info: 1013612281856
    

    TEST_LABEL: (some fat32 stick):

    [64bit.c:282 L_ExamineNext64] Got 64-bit size for aaa: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for aaaa.txt: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for muimplayer_beta006.lha: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for 02_run.jpg: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for muimplayer_beta007.lha: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for muimplayer_beta008.lha: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for Grab.png: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for 01_url_prefs.jpg: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for muimplayer_beta009.lha: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for dopus5_68k.c: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for dopus_68k.c: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for Odyssey: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for dos-54.4.lha.pgp: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for stackuse_53_7.lha: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for stackuse_output.txt: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for stackuse_output_few_commands_run.txt: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for 54_5_stackuse_after_reboot.txt: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for 54_5_stackuse_after_use_snoopy_and_yam.txt: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for odyssey_fastfix_001.lha: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for good_notify.jpg: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for graphics_lib-54.62.lha.pgp: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for NotePad-53.11.lha.pgp: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for graphics_lib-54.63.lha.pgp: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for kernel-53.61.lha.pgp: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for mplayer: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for LiveForIt_mplayer_beta3.lha: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for LiveForIt_mplayer_Beta2.lha: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for 1: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for uae: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for testa: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for mplayer.c: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for smokinguns.lha: 1211180777472
    [64bit.c:282 L_ExamineNext64] Got 64-bit size for dos-53.139.lha.pgp: 1211180777472
    

    I.e. everything works , but in output have those strange numbers (for all partitions i test).

    In listers itsel, for pure small files all looks fine , but now, i just do perform "getsize" on some big directory, and it show me size: 3.006.812.241 , while, when i perform getsize on that directory in dopus4, it give me: 4.853.966.835. On serial for getsize i have that:

    [links.c:84 ReadSoftLinkDopus] couldn't resolve link guidep: object not found
    [links.c:84 ReadSoftLinkDopus] couldn't resolve link joydep: object not found
    [links.c:84 ReadSoftLinkDopus] couldn't resolve link threaddep: object not found
    [links.c:84 ReadSoftLinkDopus] couldn't resolve link sounddep: object not found
    [links.c:84 ReadSoftLinkDopus] couldn't resolve link gfxdep: object not found
    [links.c:84 ReadSoftLinkDopus] couldn't resolve link osdep: object not found
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for fpp-ieee.h: 1013612281856
    [links.c:84 ReadSoftLinkDopus] couldn't resolve link machdep: object not found
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for t-amiga.h: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for genlinetoscr.c: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for blitops.c: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for genblitter.c: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for gencomp.c: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for gencpu.c: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for build68k.c: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for readcpu.c: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for writelog.c: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for missing.c: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for libaldmb.la: 1013612281856
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for libdumb.la: 1013612281856
    [64bit.c:381 L_MatchNext64] Got 64-bit size for 1.c: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for btanks.lha: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for epiar.txt: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for epiar: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for exult: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for exult.txt: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for exult: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for masters.cfg: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for teeworlds.info: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for settings.cfg: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for masters.cfg: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for teeworlds_new: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for teeworlds.info: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for teeworlds: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for masters.cfg: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for settings.cfg: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for teeworlds.info: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for teeworlds: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for settings.cfg: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for masters.cfg: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for fillets-ng-1.0.0.tar.gz: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for PGP5GUI: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for Duke3dw: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for Duke3dw: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for Duke3dw: 1640677507071
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for libWildMidi.la: 1013612281856
    [64bit.c:381 L_MatchNext64] Got 64-bit size for old-games.nfo: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for diskspeed: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for SFSundelete: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for DragonMemory.info: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for graphx2.txt: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for OpenJazz: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for libtool-2.4.tar.gz: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for config.cache: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for chocolatecastle-0.6.lha: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for egoo.txt: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for ZuneView.info: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for ZuneView: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for ZuneView.info: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for 1: 1636382539776
    [64bit.c:236 L_ExamineLock64] Got 64-bit size for libptp2.la: 1013612281856
    [64bit.c:381 L_MatchNext64] Got 64-bit size for teeworlds: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for settings.cfg: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for new14.!!!.info: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for nce-trilobyte12.lha: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for settings.cfg: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for old-games.nfo: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for tractor.tar.gz: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for config.cache: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for config.cache: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for demo: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for caph: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for caph: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for caph: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for caph: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for ZUnZip: 1640677507071
    [64bit.c:381 L_MatchNext64] Got 64-bit size for jcalc.lha: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for 2: 1636382539776
    [links.c:84 ReadSoftLinkDopus] couldn't resolve link awk: object not found
    [64bit.c:381 L_MatchNext64] Got 64-bit size for 7kaa-source-2.14.1.tar.bz2: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for plib-1.8.5.tar.gz: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for new10.!!!.info: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for skunks-os4.lha: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for plib_morphos.lha: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for lode_speed.txt: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for Dune_2.rar: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for plib-1.8.5.lha: 1636382539776
    [64bit.c:381 L_MatchNext64] Got 64-bit size for plib_examples-1.8.5.tar.gz: 1636382539776
    

    Even if we will take in account that links are skipped somehow, still size is lot smaller than in dopus4. While (imho), its should be the same when links skips, and bigger when links counts.

    @Xenic
    What you think about adding environment variable called "calculate_links" yes/no , or something ? So, we can test without taken them in account, and with them (and can compare with dopus4 too, etc).

     
    Last edit: kas1e 2014-04-18
  • kas1e
    kas1e
    2014-04-18

    @All
    I can tell that GetSize also wrong randomly from directory to directory (which even didn't contain any links).

     
  • BSzili
    BSzili
    2014-04-18

    @kas1e
    Are you sure you have recompiled everything? The sizes in the debug window suggests that the high and the low longs are swapped. Just type them into a calculator, and you will see values like this in hex: 0x11A00000000

     
<< < 1 .. 7 8 9 10 11 .. 14 > >> (Page 9 of 14)