Suport for Site xdupe

It would be very handy to have support for xdupe added.

Both glftpd and drftpd sites support it, but FlashFXP doesnt.

Prevents u from trying to upload a file that has already been
uploaded (after u added/started your que)

[R] site xdupe 3
[R] 200 Activated extended dupe mode 3.

Example :

U send file1 , and when u start for file2
user2 has already upped that one, and u get a failed file
with error "file already exists" and use time on that,
+ u get failed files in que.

Would speedup and prevent more failed files with xdupe suport.

This command is supported, you simply need to send it to the ftp server to activate it.

The best way to automate this task is via the Site Maanger > Advanced Tab > The following commands will be performed after login..

Then simply add
SITE XDUPE 3

Cool.

May i ask from what version that is implemented ? doesnt seen to work at my good old 3.2.1080

My bad, xdupe seemed to be implemented. But it STILL fails
even though it lists the file as there. is it suposed to do that ?
I figured it should perform a normal skip then.

[R] STOR edited.r05
[R] 553- X-DUPE: edited.nfo
[R] 553- X-DUPE: edited.r05
[R] 553- X-DUPE: edited.r06
[R] 553- X-DUPE: edited.r07
[R] 553- X-DUPE: edited.r08
[R] 553- X-DUPE: edited.r09
[R] 553- X-DUPE: edited.r10
[R] 553- X-DUPE: edited.r11
[R] 553- X-DUPE: edited.r12
[R] 553- X-DUPE: edited.r13
[R] 553- X-DUPE: edited.r14
[R] 553- X-DUPE: edited.r15
[R] 553- X-DUPE: edited.r16
[R] 553- X-DUPE: edited.r17
[R] 553- X-DUPE: edited.r18
[R] 553- X-DUPE: edited.r19
[R] 553- X-DUPE: edited.r20
[R] 553- X-DUPE: edited.r21
[R] 553- X-DUPE: edited.r22
[R] 553- X-DUPE: edited.r36
[R] 553- X-DUPE: edited.r37
[R] 553- X-DUPE: edited.r38
[R] 553- X-DUPE: edited.r47
[R] 553- X-DUPE: edited.sfv
[R] 553 Requested action not taken. File exists.
[R] Transfer Failed!

Cool.

May i ask from what version that is implemented ? doesnt seen to work at my good old 3.2.1080

more warez kiddies asking for feature request based on 5 year old version...good job

I'm not entirely sure when it was added. 3.2 may or may not support it properly.

This feature was added with limited knowledge and without direct testing on the feature as I don't have access to a ftp server with this feature.

When the feature was added users were satisfied with the results, although I never questioned the behavior until now.. The behavior is to mark them as failed and keep them in the queue.

X-DUPE works based purely on filename and it's possible that the files you intend to transfer are not the same size, so we mark them as failed and keep them in the queue.

I'm not entirely sure if skipping them is the best solution?

In the future please edit the any offensive filenames before posting on our website.

Perhaps a setting in preferences is best, 'mark failed' or 'skip'. In the event of skipping the appropriate message would be logged for each file, eg 'Skip [xdupe]: somef.ile'.

Generally if you want to perform any other action on the file (such as resume or overwrite) then its often best to turn xdupe off and obey file exists rules, so most likely the majority would set it to skip rather than mark failed. Although i have a few web servers where i like them marked failed and use xdupe just for the inproved speed when uploading a mixture of new and updated content.

This feature is a supported but as an unsupported feature, what that means is that the user is required to setup a raw command to enable the option on the server and FlashFXP will handle the output but there are specific options for this feature.

Making an GUI option for this isn't really an option without officially supporting X-DUPE.

Personally I think the X-DUPE feature is flawed by design and it is very unlikely that we will officially support it anytime soon.

I do not see any reason not to officially support XDUPE, Flawed or not (at least in your opinion, i dont really concider something flawed just because it could be better).

It is such a simple server side mechanism and so simple for a client to support it.

IMO, the arguement over it removing files that may need to be resumed later is somewhat mute. This is because people wouldn't use XDUPE in the first place if they wanted to explicitely obey the file exists rules (the two basically rule each other out, although if you really wanted you could have flashfxp check the file size and obey the fer's for each file listed in an xdupe reply). Aside from that you should also note that almost all ftpd's that support XDUPE also support zipscripts of some sort for handling file integrity, so although there is a chance it will report a file that you would actually need to perform further action on, it is unlikely.

Regardless of it being 'official' or not, flashfxp has already implemented almost everything neccersary to fully support xdupe, with the small exception of an actual per site option that sends the xdupe command internally, and the current suggestion of if it should mark failed or just skip.

There are a number of other mechanisms/features that flashfxp supports that are much less widely used, or supported by ftp daemons. (such as CC's)

Flawed or not this mechanism does was it was designed to do, speed things up.

Should also probably note that the raw command sending it not always needed, some ftpd's have xdupe enabled for clients by default, officially supporting xdupe and giving the per site option to use xdupe would also allow flashfxp to check/turn off or just ignore the replies when its disabled (probably better to ignore due to some servers forcing its use and not allowing the client to change the method or turn it off).

Anyway, just my thoughts, obviously im pro improved xdupe support.

I came across a X-DUPE document explaining the specific expected behavior of X-DUPE and it says that matching files should be removed from queue.

Perhaps this should be the behavior of X-DUPE in FlashFXP.

Are there many ftp servers that support X-DUPE? I did some research and the only servers I could find were glFTPD and raidenFTPD.


As far as also doing a size compare that would kind of defeat the purpose of X-DUPE, otherwise X-DUPE wouldn't really be needed at all.

Originally Posted by bigstar

As far as also doing a size compare that would kind of defeat the purpose of X-DUPE, otherwise X-DUPE wouldn't really be needed at all.

Indeed it would, that was kind of an after thought in response to previous concerns over simply removing the files.

DrFTPd & ioFTPd also support xdupe that i know of (though patches as the next stable/final versions of both are yet to be released)

Edit: looks like pftp also supports xdupe, and a number of others are planning to add it (wzdftp, proftpd, xftpd, etc)

It is certainly not widely used yet but definately growing in popularity.

Starting with 3.6 RC2 the behavior of X-DUPE will be to remove matching files from queue.