par2 check deletes valid *.part01.rar file

[rmarsu]

altbinz 0.39.9

Settings:
PAR2 checking: yes
Delete par2 files if all ok: yes
PAR2 reparing: yes
Cleanup after PAR2 repair: yes
Autounrar: yes

1. Go to nzbclub.com, search for "dont trust s01e06 nfhd".
2. get nzb into altbinz: looks perfectly ok, the par2 nfo and part01.rar to part16.rar are all active, the srr and additional par2s are paused
3. start download: looks ok, all files are downloaded, including the *.part01.rar (note that the part01.rar file is actually there in the download folder)
4. in the PAR2 tab, all files are listed and when downloading is finished, all files are green
5. after download is finished, altbinz is checking files
6. the part01.rar file disappears from the download folder (is obviously deleted) !!
7. altbinz thinks file par check is ok and begins unrar, but unrar hangs because there is no part01.rar file anymore.

[Rdl]

I tried reproducing it and failed - everything went fine.

What I don't understand in your steps is nr.5 - why should altbinz be checking files if they were green in par2 tab as described in step4?
Also nr.6 - how can you be sure that altbinz is the one deleteing the file? Maybe try and log operations altbinz is doing with files? Can't remember name of the tool fro that.

[rmarsu]

I'm running the process again with Process Monitor from Sysinternals, logging the altbinz file operations. 
Btw, when going thru the log files of the last days, I saw out of memory conditions, but there is plenty of memory available.  C: system drive has 38GB free, D: destination drive has 44GB free, and there is a total of 5GB RAM with 59% usage and around 2GB available.  OS is 64bit Server 2008 R2.
The point is that Altbinz uses around 1940MB of memory, probably due my large download queue
So it seems you are at the 2GB memory limit, which should not happen on a 64bit OS.  The max process space for a 32bit application on a 32bit OS is 2GB, but on a 64bit OS it's 4GB, if you link your app with IMAGE_FILE_LARGE_ADDRESS_AWARE set (otherwise it defaults to 2GB only).
I guess being close to the 2GB process size is causing the problems I see here.  Please use IMAGE_FILE_LARGE_ADDRESS_AWARE for the next version of altbinz...

[rmarsu]

Process Monitor has found that altbinz deletes the part01.rar file:

"19:33:09,5172584","altbinz.exe","2132","CreateFile","D:\alt.binz\Apartment 23 S01E07 720p WEB DL DD5 1 H264 NFHD\dont.trust.the.bitch.in.apartment.23.s01e07.720p.web-dl.dd5.1.h264-nfhd.part01.rar","SUCCESS","Desired Access: Read Attributes, Delete, Disposition: Open, Options: Non-Directory File, Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, OpenResult: Opened"

"19:33:09,5173282","altbinz.exe","2132","QueryAttributeTagFile","D:\alt.binz\Apartment 23 S01E07 720p WEB DL DD5 1 H264 NFHD\dont.trust.the.bitch.in.apartment.23.s01e07.720p.web-dl.dd5.1.h264-nfhd.part01.rar","SUCCESS","Attributes: ANCI, ReparseTag: 0x0"

"19:33:09,5173747","altbinz.exe","2132","SetDispositionInformationFile","D:\alt.binz\Apartment 23 S01E07 720p WEB DL DD5 1 H264 NFHD\dont.trust.the.bitch.in.apartment.23.s01e07.720p.web-dl.dd5.1.h264-nfhd.part01.rar","SUCCESS","Delete: True"

"19:33:09,5174267","altbinz.exe","2132","CloseFile","D:\alt.binz\Apartment 23 S01E07 720p WEB DL DD5 1 H264 NFHD\dont.trust.the.bitch.in.apartment.23.s01e07.720p.web-dl.dd5.1.h264-nfhd.part01.rar","SUCCESS",""

[Rdl]

I'll need the whole process monitor log - from the start of downloading the last file to the end of failed unraring.
Upload it somewhere and send me the link via PM.

[rmarsu]

link sent by PM

This is a .csv logfile.  In this case there already was a folder in the target directory with all the files (from one of my earlier tries), and I reloaded the nzb file into altbinz.  So altbinz downloaded a second nfo and par2, and then continued with downloading the part01.rar.  Meanwhile, the par2 checker was testing the already existing files, and then deleted the existing part01.rar.
Basically this is a more complex version of what I saw before happening with straightforward downloads.

I now have deleted a considerable chunk of the download queue to resolve the alt.binz out of memory condition, and now this same nzb is downloading fine without deleting the part01.rar file.

Perhaps altbinz should check the memory status when files are added to the download queue, and at some point refuse to add more files.

There seem to be many more issues when the process is coming close to the 2GB limit.  For example, the logs show that altbinz has generated gigabytes of traffic without actually downloading something, because it has requested the same articles over and over again.

[Rdl]

Now I don't get you Is there a bug regarding deleting rar files or not?

Regarding memory, I've already added LAA flag. It will be available in next version.

[rmarsu]

Sorry, didn't want to confuse you

After some analysis, my conclusion is:
- yes, there is some kind of bug causing a rar file to be deleted by altbinz. 
- it always seems to be the first file of the rar set, i.e. the something.part01.rar in case of something.part??.rar, or the something.rar  in case of something.r??
- other rar files except the first one are not deleted
- it happens somewhere after the download of the file set is complete, during file checking or just before unraring
- and, most important: it happens _only_ when the altbinz process is close to the 2GB limit!  This is probably the reason why this problem does not occur more often in the field.

As I wanted to have a stable altbinz client, I deleted several entries in my download queue, and now the problem is gone.  The process working set memory is now at 1.8xx.xxxK.  When I saw the problems, it was around 1.940.000K.

Hope this helps.

[Rdl]

LAA flag is already added in 0.39.10

Can you confirm for me that it's working properly.