Smugness regarding the blatant UX failure with auto-upload

[davidsl]

I felt compelled to register for this forum for one purpose... simply to report that due to the smug nature of botg's responses to this matter, I have been urged to find a better solution for myself, and for my entire company, which has 40 developers.

Corrupt files are a great reason to leave out a feature... but it's silly to say there is not a solution. What is stopping a user from clicking "Upload" before the file is done saving in the exterior program? Isn't that the equivalent of why you've decided to dig your heels in the sand on this topic? You have the exact same problem regardless of whether a user chooses to upload the file or the program does. FZ has caused corrupt files for me for that exact reason. So you built it to have the confirmation so that it takes longer for the user to confirm the upload and it will likely be done saving by that time? Just have the program wait a few seconds or something. Don't act like it's somehow impossible. You can do MANY things, like file versions, or doing file comparisons until the files stop changing, and things like that. There are just so many options, I can't believe how ridiculous this is getting... after like 8 years of requests. For a developer who is capable of putting together a great piece of software like FZ, I find it very odd that your stance on this topic is so rigid and unwilling to help. How can you, personally, not feel like it's a gigantic waste of time to require a confirmation upon every single upload? I imagine that you, yourself, prefer another FTP program to this because of this issue alone. Anyone who has used FZ for any meaningful amount of time would see that it's a big effing waste of time for no reason.

My company has used FZ as a standard for YEARS, but I will be migrating us away from FZ next week due to this gigantic hindrance to productivity, and the dev's failure to care about doing something that thousands of people want... regardless of how they personally feel about it. It's asinine for you to treat the biggest failure in FZ's UX as if you know better than EVERY SINGLE OTHER FTP PROGRAM OUT THERE.

This is basically the equivalent on Google's help forums, where Google employees act as if people are effing idiots for looking for features that EVERY OTHER COMPETING PRODUCT HAS. To bury your head in the sand, without any sort of willingness to give people what they want does nothing but makes people go elsewhere for their software solutions. I will be migrating my entire company away from FZ for this reason. This was something I just dealt with for a long time, but because other programs, namely, Notepad++ with the NppFTP plugin, already have this built in functionality, I see no reason not to get away from FZ completely at this point. It's not like you're willing to actually listen to what people want... you know, try to find an actual solution instead of just acting like you know better.

I understand that this is open-source, and I could just jump in and fork it... but that's silly. All that would happen is, botg would write my version off as unstable and then continue to not include it in the main fork. You'd end up with ONE VERSION with the right functionality, and then the main fork missing it.

So botg (and those of you who try to act like you are somehow superior in intellect to others), I bid you adieu. Just tell us the real reason you don't want to add in the option... because you want to feel like you know better. You don't. Go look at any competing FTP program and tell me I'm somehow wrong. If anything, FZ has caused more corrupt/blank files and things like that than competing FTP solutions because it still allows you to upload a file still being saved.

[botg]

due to the smug nature of botg's responses to this matter, I have been urged to find a better solution

You confuse smugness with weariness. I'm tired of explaining the same things over and over again.

What is stopping a user from clicking "Upload" before the file is done saving in the exterior program?

Nothing stops the user from clicking Upload at the wrong time, just as nothing stops the user from just deleting every file or from changing all filenames to expletives. The user is king, the user's word is the program's command.

You have the exact same problem regardless of whether a user chooses to upload the file or the program does.

No, you do not have the exact same problem. The symptom of the corrupt file is the same, but in one case the problem is caused by the user and in the other case the problem is caused by the program.

FZ has caused corrupt files for me for that exact reason.

User have cause the corrupt files, not the program, it has only acted as told to by the user.

Just have the program wait a few seconds or something.

It can take a lot of time saving a file. Consider for example a large .zip file written to in-place: The change to the file is detected instantly, but it can take many minutes until the writing program is done writing to it.

Don't act like it's somehow impossible.

Unfortunately it is, especially on Windows which has exclusive file access modes enforced by the operating system (cf. *nix systems which only have advisory locking)

How can you, personally, not feel like it's a gigantic waste of time to require a confirmation upon every single upload?

Alt+Tab followed by Alt+Y is hardly a gigantic waste of time. Personally I gladly accept a tiny delay on an upload to get the guarantee that the file won't become corrupted.

This is basically the equivalent on Google's help forums, where Google employees act as if people are effing idiots for looking for features that EVERY OTHER COMPETING PRODUCT HAS.

Such as? Without details it sounds like a hyperbole. Frankly this seems like the kind of argument you hear from adolescents: "But mom, everybody else is allowed to stay at the party as long as they want"

other programs, namely, Notepad++ with the NppFTP plugin, already have this built in functionality

That's a different scenario. In this case, the editor and the FTP client are the same program. In this case the editor knows when it has finished saving the file and can trigger the upload. Unfortunately this isn't a generic solution, there simply is no API for some FTP client to query when some editor has finished writing to a file.