FileZilla Forums

In the case of a database, I can't see how:
1) You would even set FileZilla to upload from there. Doesn't FileZilla set that the file is saved in a temporary folder and opened with a text editor? Thus, you would have to:
(a) Have the database program as your default text editor for some reason, or
(b) Point your database program to use the newly created temporary file to store things,
neither of which seem very likely to happen.
2) In addition, the timing would still have to be exactly perfect, so the database would be unused for a full second, then used at exactly the right moment. Different settings would further decrease the likelihood.

I also don't understand why if a file is locked to be uploaded, you can write to it at all (such to cause data loss).

Finally, I question the claim that it's impossible to tell if a file is being written to in Windows. Didn't you say that files being written to could not be renamed, and thus you can at the very least tell it's being written to because it can't be renamed.

What would be interesting to see is if you can copy the file, then upload it. In this way, the original file is never locked.

In the case of a database, I can't see how:
1) You would even set FileZilla to upload from there. Doesn't FileZilla set that the file is saved in a temporary folder and opened with a text editor? Thus, you would have to:
(a) Have the database program as your default text editor for some reason, or
(b) Point your database program to use the newly created temporary file to store things,
neither of which seem very likely to happen.

I know of several business applications which make use SQLite as database storage, with one database file per "project", whatever project means for your job of choice. These files have a special extension, say .BAPrDb which is associated with the application.

Workflow goes like this: User connects to server where files are stored, right-clicks a specific project file, clicks Edit. File gets downloaded. Local copy gets opened in said business application. User works with the project, his every change resulting in a write to the file. User is done, tabs back into FileZilla and tells FZ that yes, he's done with the editing and wants to re-upload it.

2) In addition, the timing would still have to be exactly perfect, so the database would be unused for a full second, then used at exactly the right moment. Different settings would further decrease the likelihood.

Imagine there would be auto-upload. User clicks something in his program, the database file changes, FileZilla auto-uploads. Since the file is big, it takes a minute. After half of that time, user clicks somewhere else in his program. File changes again. Result: The file on the server is inconsistent, part of it from the old version, part from the new.

I also don't understand why if a file is locked to be uploaded, you can write to it at all (such to cause data loss).

Because on some systems there just is no mandatory file locking, only advisory file locking. Also, file locking does not work reliably on network resources.

Finally, I question the claim that it's impossible to tell if a file is being written to in Windows. Didn't you say that files being written to could not be renamed, and thus you can at the very least tell it's being written to because it can't be renamed.

Actually you can in some situations rename files that are being written to even under Windows, resulting in some really weird behavior. If you rename foo.txt into bar.txt and then try to creat a new foo.txt it fails if there's still writing into bar.txt going on.

All Windows OS using NT kernels lock files using handles, not file names. Thus you can rename locked files freely. Most of the time you can even create a new file with the old name right away (that's how some system file replacing tools work).

Can be very impractical with larger files.

My files (PHP scripts) are all under 30Kb. The dialog would be fine for larger files.

It's been about a week. I don't want to rush anything, but FileZilla is really a great tool and since the administration is quite open to discuss their issues and work towards resolving them I have no doubt it can be the single best choice for FTP software. I have this feature on FireFTP, but I really like keeping it separate from the browser, and the FireFTP one crashes some of the time (for the reasons you mentioned). If you can build it so it wont crash, then this is making history - something that no other FTP client can do. You have to understand that a lot of web developers use FTP like I do, editing many remote files - and when you make so many edits that prompt takes away so much time and productivity.

botg wrote:That's one extremely dangerous change. It will result in FileZilla uploading (and thus locking a file) while it may still be written to by another program.

The result? Simple: Local file corrupt, remote file corrupt and you likely not having done backups.

Why not make it optional? Make the alert enabled by default but add an option on preferences dialog to disable it if I want.
It is extremely frustrating & time wasting and I have even created some AutoIt script to "fight" this dialog. Never had any kind of loss from that.

Any updates on this? I have been a fireftp user for 10+ years and am now forced to use another ftp client. I have dabbled with every other major client (including winscp), filezilla is my second choice. This prompting is the only thing holding me back from using it all time time.

I believe there should be a setting to disable the prompt after file change but default to the current state with prompting. Most developers have one file open in only one instance of a text editor (for me notepad++). When they save, they would like to immediately check the changes instead of having to switch windows back to click yes. It is annoying and the stability doesn't outweigh the hassle.