FlashFXP Forums

FlashFXP Forums (https://www.flashfxp.com/forum/)
-   Bug Reports (https://www.flashfxp.com/forum/flashfxp/release-archive/flashfxp-v2-1-a/bug-reports/)
-   -   Resuming download of files of unknown size (https://www.flashfxp.com/forum/flashfxp/release-archive/flashfxp-v2-1-a/bug-reports/2025-resuming-download-files-unknown-size.html)

squonk 12-11-2002 05:24 AM

Resuming download of files of unknown size
 
Some FTP sites protect their files by preventing from listing their directories. I got one of this kind at work.
You can only get the files if you know their complete file and path name.
The problem with FlashFXP is that you can never resume file downloading when dealing with such files.
To retrieve such files, you use "manual get" but as the file listing is not allowed, FlashFXP doesn't know anything about the file size and arbitrarily sets it to zero.
So if you later try to resume such a download, the "file exists" rule applied is always "When Destination is larger". And in this case "Auto resume" is not available.

I think FlashFXP could set the file size to an "unknown" state instead of zero, and then apply by default the "When Destination is smaller" file exists rule. The size shown in the queue could be set to ?? for instance instead of 0 too.
Another solution (the best!) could be to add a combo box in the "file exists options" to allow the user to choose the behaviour of FlashFXP in such a case (which rule is to be used when the source file for downloading is of unknown size).


PS :
Don't forget the clipboard monitoring button in the toolbar after your holidays !
No this is not a private joke, it's a real need !;)

bigstar 12-13-2002 06:09 AM

The ftp server should support the SIZE command, even though the directory listing is denied. SIZE should give FlashFXP the exact size of the file.

If the ftp server doesn't support/allow the SIZE command you're out of luck. FlashFXP needs to know how big the file is in order for it to properly resume.

squonk 12-18-2002 05:59 AM

I thought that FlashFXP only needed to issue a REST command with the starting byte number to resume the file. Is the remote file size really necessary ?
I think the remote file size is only necessary to decide what file exists rule you're going to apply for your download.
If you create a new rule for remote file of unknown size and set it to "always resume" this should work.

At least, FlashFXP doesn't need to know the file size to download the file in one shot. This works very well on the same FTP site.

bigstar 12-18-2002 07:25 AM

If the size is unknown this becomes more complex. I attempted to test this problem on my local ftp servers but they all allow SIZE if listing is disabled and resume correctly.

The only way for me to truely understand the problem more closely is to duplicate it. Any chance you could set me up a test ftp?

squonk 12-19-2002 08:50 AM

Sorry I can't give you access to my work ftp. And I have not a permanent web access at home.
If I come across a public one with that feature I'll let you know.

bigbras36 01-02-2003 03:48 PM

Can't you just issue the REST command without knowing the file size? Its not a problem for you to do so, if anything its a damn site easier.

If something went tits up, you'll just get an error back when you try. Maybe implement it as an option?


bigbras36

bigstar 01-02-2003 05:30 PM

Some ftp servers will corrupt the download if you try to resume past the end of the file.

bigbras36 01-02-2003 07:28 PM

I understand. But it is a safe assumption that the file you've been downloading has not been replaced by a file which is smaller.

Would you not consider it as an option surely?


bigbras36

bigstar 01-03-2003 04:05 AM

I don't know, more testing would be required.

sUpps 06-11-2003 09:17 AM

Hi,

I have this exact problem in 2.1 build 924 (Evaluation Copy). Is there anyway for FlashFXP (as an option maybe) to use the size specified in the local queue window instead of using SIZE command? The exact size of the file should already be stored there.


All times are GMT -5. The time now is 10:46 AM.

Powered by vBulletin® Version 3.8.11 Alpha 3
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Parts of this site powered by vBulletin Mods & Addons from DragonByte Technologies Ltd. (Details)