New downloads lost with each restart

[dradams]

I'm running Shareaza 2.6 (64-bit version) under Windows 7 64-bit and seem to have shot myself in the foot. If I add a new file to be downloaded it works fine until I exit Shareaza; on restart the download is gone from the Transfers window (though vestiges are left in the Incomplete directory). Downloads that have been in progress for a long time are still there after a restart. Unfortunately I don't know quite when this started -- possibly after upgrading from 2.5.5, but just not sure.

I installed in other than the default location. I selected the Z: drive. The Downloads and Incomplete directories are EFS encrypted (even though that prevents completed downloads from being shared). That still left vestiges in C: so I tried manually setting the directories to point into Z. Suspecting that configuration to be the problem I cleaned the executables and registries out using both "Shareaza Easy Clean Install Script v1.3.bat" and manually finding and deleting entries in the registry (including the WOW6432 parts of the hierarchy,and re-installed. Still no joy.

UPDATE: Problem seems to be related to 2.6. I downgraded to 2.5.5 x64 and am once again able to add new downloads to the queue. If I re-up to 2.6 it remembers what I just added but again forgets anything added using the 2.6 client.

Any suggestions on where I should look for configuration problems that would explain why 2.6 remembers and continues old downloads but forgets new ones?

[ailurophobe]

IIRC the sd files in the partials folder contain a path to the partial file. If that stored path got corrupted that could cause the symptoms you describe. Basically Shareaza would open the Incompletes folder scan the sd files, fail to open the path to the partial files (because the corrupted path does not exist) and ignore the download as corrupted. You could try opening the sd files for a download that works and one that doesn't in a text editor and seeing if there are file paths in them and if they are different.

[nigerija]

Got same problem here.
first to inform I've rebuild shareaza from source code of 2.6.0.0 as debug win32 project settings
Installed original 2.6.0.0 and only replaced exe file with my own (this worked in earlier versions).

notices 2 errors, one not that big, just annoying:
settings>uploads>queue list keeps accumulating on each saving - default list is loaded if I erase all items, and that solves it.

And HUGE problem with restart
I've got out of power few minutes ago, and you can imagine my face when I realized all my downloads are gone.
this happened for the second time (two restarts two times list got lost, I guess there is some bug).

mean while you try to fix this
can you please tell me how to regenerate the list, all partial files are still there (gigabytes, took me several days to download this far, wouldn't want to start over again).

And one big NOTICE: there is no more .SD extensions now there are .SAV ?
may this be the problem ???

thanks

EDIT: actually this is the problem
downloads.cpp: line: 1222
HANDLE hSearch = FindFirstFile( CString( _T("\\\\?\\") ) + Settings.Downloads.IncompletePath + _T("\\*.sd"), &pFind );

download.cpp: line: 698
if ( ! pFile.Open( m_sPath + _T(".sav"),

I see some disparities here, how nobody noticed this ???
checked other files and on few lines there is still ".sd", but most of code uses ".sav" now ???


mean while solution for NON DEVELOPERS:
- exit Shareaza
- rename all *.sav to *.sd
- start Shareaza
this will trick loading the download list properly.

[dradams]

I ran procmon so I could monitor file activity but I haven't been able to complete testing across both versions, so I don't have anything definitive yet. With 2.5.5 installed, when I start a new download procmon sees .sd.sav files created, written to, closed, and ultimately renamed (the call shown by procmon is SetRenameInformationFile) to .sd files. I suspect (this is the part I haven't tested) that the file rename is failing under 2.6.0. I'm not familiar with the Windows file system semantics so even if/when I verify this I'm not sure what I'll do with the information. But for now I'm sticking with 2.5.5 because it maintains state across failures and exits.

[flitox]

you might have notice that problem only occurs with files that have been queued using the 'download now' option!
there is no problem for files that have been added by clicking 'download'.

i've noticed that on the last files i've downloaded that way (download now). the files download entirely but when i get to my download folder, they end up behing under 1 mo in filesize while originally they were like 40 Mo and so they are not usable.

[ailurophobe]

If it is related to "Download Now" it has probably been fixed. Anyone still interested in the issue can install a debug build. The potential fix is in r9172 and newer.

[dradams]

I pulled down the 9181 development build and the problem I was having with vanishing downloads has gone away in that version. I had not noticed the dependence on Download Now vs Download that flitox noted, but I almost always use Download Now.

I had also observed the problem with file truncation/corruption under 2.6.0. I haven't seen with this debug version but I also haven't downloaded any files larger than a few hundred KB yet either so I don't know if it's still happening or not.

Thanks for the validation, additional problem characterization, and fixes provided here on the forum.