[BUG][1.0.0B5]

[oriuskhan 0]

Hello all,

I have three different bugs to report here. I'm running on WinXP, but I don't think it matters since none of them are crash-related, just unintentional program behavior.

The first one I already mentioned in the Client Discussion forum here, and somebody said they would look into it, but I thought I'd list it here too since it appears to in fact be a bug. Basically the issue is that files that you download into a folder that is NOT supposed to be shared still remain searchable & uploadable, altho they don't appear in your File List.

Second & third one are kind of similar, but still separate sections of the code I'd think. Both involve the Download Queue window. If I mark some files to be downloaded into a folder (the default d/l folder for instance, but not necessarily), and then later decide to "Move/Rename" them to a different folder after some portion of the file has already been d/l'd (whether currently in progress or not), it will create a new Download Queue entry in the new folder, but the one in the original location will remain there. Eventually when the file finishes d/l'ing, the entry in the new/correct location will (correctly) disappear, the actual file will be moved to the correct location on the disk, but the original D/l Q entry remains there, showing 100% d/l'd. It still shows how many users are online, and still tries to connect to them to d/l that file, but it never actually connects, sits on "Connecting..."

The thing is, I can't get rid of these entries. Selecting them and hitting Delete key does nothing. Right-clicking on them doesn't even bring up the context menu. And since they were set to Auto priority handling, they're all set to Highest priority (since 100% is really really close to being done), so I can't d/l anything else from those users b/c it gets stuck trying to get these files. (The issue of it creating duplicate D/l Q entries when trying to Move files existed in the previous beta version too, but since they were rather large files I don't believe any of them finished d/l'ing under that version, so I don't know if the 'zombie' entries problem existed back then or not.)

The last bug I've only seen once so far. Here's the scenario: I select several folders containing about 10-20 files each to all be downloaded from the same user. It d/l's most of them fine, but then for some reason it gets stuck on this one file. It has already successfully d/'d the file, as well as all of the other files in that folder, but in the Transfers window it shows that it's still trying to d/l it. (FYI- The only remaining files that it needs to d/l from that user were marked as Lowest priority. I think this may have something to do with it.) The kicker is, that not only does the file that it's trying to d/l not show up at all in the D/L Q, the folder that it's supposedly trying to d/l to doesn't show up either! There is no reference to this file anywhere in the D/L Q, yet it has dilligently tried to d/l it for several days.

Whenever I checked it, the status of that xfer was always "No slots available", I'm not sure what status/error it would have said on the times when it actually got a slot, and I can't find any kind of "Misc Log" file that keeps track of that kind of stuff. The "Close Connection" and "Search for Alternates" cmds had no effect on that xfer when I clicked them. "Force Connection" would only change the status to "Connecting (forced)...", but got no further. Changing the remaining files' Priority to Highest and Forcing connect again appeared to do nothing either. I attempted to "Remove User From Queue", which it did from the remaining files on the Queue, but did not remove this xfer.

That was a day or two ago. Today I tried it again, this time I set all the remaining files to Paused priority, then "Remove User from Queue". It seems to have worked b/c that user disappeared from the xfer window entirely. Then, re-adding that user to those files made him re-appear, trying to d/l the first file on the list (but of course still no slots available). Changing them all to Paused made him disappear again, so it seems to have fixed the problem, but it was quite annoying to figure out how.

[Satan 1]

The first one I already mentioned in the Client Discussion forum here, and somebody said they would look into it, but I thought I'd list it here too since it appears to in fact be a bug. Basically the issue is that files that you download into a folder that is NOT supposed to be shared still remain searchable & uploadable, altho they don't appear in your File List.

This is to do with the partial sharing code. Partial sharing retains all files as active for partial sharing within the current session. If you restart Apex, these files will disappear again. It's part of the code inherited from SDC.

Second & third one are kind of similar, but still separate sections of the code I'd think. Both involve the Download Queue window. If I mark some files to be downloaded into a folder (the default d/l folder for instance, but not necessarily), and then later decide to "Move/Rename" them to a different folder after some portion of the file has already been d/l'd (whether currently in progress or not), it will create a new Download Queue entry in the new folder, but the one in the original location will remain there. Eventually when the file finishes d/l'ing, the entry in the new/correct location will (correctly) disappear, the actual file will be moved to the correct location on the disk, but the original D/l Q entry remains there, showing 100% d/l'd. It still shows how many users are online, and still tries to connect to them to d/l that file, but it never actually connects, sits on "Connecting..."

The thing is, I can't get rid of these entries. Selecting them and hitting Delete key does nothing. Right-clicking on them doesn't even bring up the context menu. And since they were set to Auto priority handling, they're all set to Highest priority (since 100% is really really close to being done), so I can't d/l anything else from those users b/c it gets stuck trying to get these files. (The issue of it creating duplicate D/l Q entries when trying to Move files existed in the previous beta version too, but since they were rather large files I don't believe any of them finished d/l'ing under that version, so I don't know if the 'zombie' entries problem existed back then or not.)

I too, have seen this, it must be something in Crise's code, as it does not present itself in SDC. One way to 'work-around' the problem, which is 99% successful afaik, is to pause the file first, let the download stop, THEN move the file, seems to work most of the time.

The last bug I've only seen once so far. Here's the scenario: I select several folders containing about 10-20 files each to all be downloaded from the same user. It d/l's most of them fine, but then for some reason it gets stuck on this one file. It has already successfully d/'d the file, as well as all of the other files in that folder, but in the Transfers window it shows that it's still trying to d/l it. (FYI- The only remaining files that it needs to d/l from that user were marked as Lowest priority. I think this may have something to do with it.) The kicker is, that not only does the file that it's trying to d/l not show up at all in the D/L Q, the folder that it's supposedly trying to d/l to doesn't show up either! There is no reference to this file anywhere in the D/L Q, yet it has dilligently tried to d/l it for several days.

Whenever I checked it, the status of that xfer was always "No slots available", I'm not sure what status/error it would have said on the times when it actually got a slot, and I can't find any kind of "Misc Log" file that keeps track of that kind of stuff. The "Close Connection" and "Search for Alternates" cmds had no effect on that xfer when I clicked them. "Force Connection" would only change the status to "Connecting (forced)...", but got no further. Changing the remaining files' Priority to Highest and Forcing connect again appeared to do nothing either. I attempted to "Remove User From Queue", which it did from the remaining files on the Queue, but did not remove this xfer.

That was a day or two ago. Today I tried it again, this time I set all the remaining files to Paused priority, then "Remove User from Queue". It seems to have worked b/c that user disappeared from the xfer window entirely. Then, re-adding that user to those files made him re-appear, trying to d/l the first file on the list (but of course still no slots available). Changing them all to Paused made him disappear again, so it seems to have fixed the problem, but it was quite annoying to figure out how.

I have seen this one also, but it does correct itself, so I have doesn't seem to bother me.

Are you on Vista BTW? Possibly these problems are presented by vista, I use vista also.

[oriuskhan 0]

This is to do with the partial sharing code. Partial sharing retains all files as active for partial sharing within the current session. If you restart Apex, these files will disappear again. It's part of the code inherited from SDC.

Thing is tho, they don't disappear after restarting Apex. I've had files start u/l'ing that were finished d/l'ing before I restarted the whole computer before.

I too, have seen this, it must be something in Crise's code, as it does not present itself in SDC. One way to 'work-around' the problem, which is 99% successful afaik, is to pause the file first, let the download stop, THEN move the file, seems to work most of the time.

Thanks, I'll give that a try & see what happens. Of course once they hit 100% it's not possible to do so anymore. I'm going to reboot tonight & see if they go away.

I have seen this one also, but it does correct itself, so I have doesn't seem to bother me.

Are you on Vista BTW? Possibly these problems are presented by vista, I use vista also.

It may have corrected itself eventually, but at the time that I tried fixing it, it had been stuck that way for DAYS, so I still consider it a bug...

And I'm running XP SP2.

[oriuskhan 0]

I too, have seen this, it must be something in Crise's code, as it does not present itself in SDC. One way to 'work-around' the problem, which is 99% successful afaik, is to pause the file first, let the download stop, THEN move the file, seems to work most of the time.

Didn't seem to work. I tried d/l'ing some files from a user's list who was offline. The transfers never started (b/c he was offline), but I Paused them anyway. Then tried moving them to a new folder (sub-folder of the folder they were currently set to d/l to). It did the same thing where it created duplicate entries.

I then tried to remove the original files, but it deleted the NEW folder from the tree view instead. When I checked the file path of the remaining entries, they showed up as being in the ORIGINAL folder, but their individual file paths were set to the NEW folder..... (ie. they were not showing up in the D/L Q dir tree where they were supposed to be)

I tried deleting these files too, but they were now 'zombies' too, not responding to Delete key nor giving context menu when right-clicked...