Filezilla.xml~ Couldn't Be Removed

[flatlinebb]

Daily build same issue



FileZilla Client
----------------

Version: 3.9.0.2-nightly

Build information:
Compiled for: i686-w64-mingw32
Compiled on: x86_64-unknown-linux-gnu
Build date: 2014-08-07
Compiled with: i686-w64-mingw32-gcc (GCC) 4.9.1
Compiler flags: -g -O2 -Wall -g -fexceptions -std=gnu++11

Linked against:
wxWidgets: 3.0.2
GnuTLS: 3.2.16
SQLite: 3.8.4.3

Operating system:
Name: Windows 7 (build 7601, Service Pack 1), 64-bit edition
Version: 6.1
Platform: 64 bit system

[hedera]

I am having this identical problem on my Win7 Pro 64-bit laptop, it began when I installed FileZilla 3.9.0.2. I actually came to the forum to ask if there is somewhere I can download the previous stable version until this gets fixed; I filed a bug report the other day.

My home directory is on my c:\ drive, but I do have a 3rd party program indexing files (we use CrashPlan), and I can try excluding the FileZilla folder - but we've been using CrashPlan for over a year and I never had this error until FileZilla 3.9.0.2. I just excluded the \AppData\Roaming\FileZilla folder from the CrashPlan backup and restarted the backup, I'll report back if this helps.

If it doesn't help I'd still like to know where I can download the last stable version of FileZilla 3.8.

[csilver]

I happen to have 3.8.1 for win32. I put it on DropBox for the time being:

https://download.filezilla-project.org/ ... exe?nowrap&

Turns out I also use CrashPlan. Odd that it would have a problem only now. Please let me know whether excluding that path worked for you.

[hedera]

csilver, thanks for the DropBox link, but in fact excluding the FileZilla directory from the CrashPlan backup did eliminate the popup. I even have a test case - I excluded the directory on my laptop but not on my desktop, and the desktop still gets the popup window but the laptop doesn't. I agree, no good reason why this should turn up after all these months. But that's development.

[csilver]

OK, I'll use that workaround for now. Thanks for testing and for posting back.

[K9BM]

So the big question is whether the bug is in Filezilla, or in Crashplan, right??

[csilver]

Good point. I actually switched from Carbonite to CrashPlan, in part because I found Carbonite to hang on to files and disrupt other processes when I felt it should use a lower priority approach.

Is anyone on the FileZilla dev team listening? FYI, it's is possible to sign up with CrashPlan for free for a month, if you would like to test.

[botg]

Third-party programs are not supposed to fiddle around in FileZilla's settings directory. They should use their own settings directory.

[csilver]

I would agree that usually, third party programs are not supposed to fiddle around with FileZilla's settings directory but CrashPlan, being a backup program, has every right to be at least reading files from FileZilla's settings directory, no?

[botg]

Yes. And it can do that is it sets the proper share modes, it must not block other programs from reading, writing or deleting files.

[boco]

A backup program, when used on volumes with open files, is supposed to use shadow files and volume snapshots. Does yours do do that?

[csilver]

I believe it does.

As K9BM pointed out, it's a question of whether the problem lies with FileZilla or with CrashPlan. I guess the finger points more to CrashPlan.

I might open a ticket with CrashPlan when I get the chance.

[boco]

Usage of the aforementioned methods would prevent that problem, therefore I think it doesn't use them and tries to backup the original files.

[guaycuru]

I have the same problem, and I don't think it's related to another process locking the file, and I say that for 3 reasons:

1) The only process that could be locking the file in my PC is Crashplan, and it uses VSS to backup.
2) The error message clearly says "Error 0: The operation completed successfully", so really there was no error, just filezilla thinks there was...
3) The problem started when I upgraded to 3.9, but I've been using Crashplan and Filezilla together for a looong time...

So I'm pretty confident it's a Filezilla issue...

[MisterNeutron]

I have the same problem, and I am NOT using Crashplan. I use Carbonite for backup, but I'm getting the error even when Carbonite has been disabled, and isn't running. When I get the error, I can manually delete the filezilla.xml~ file, so it's not locked by any other process.

Edit: The error most often occurs when exiting FileZilla following any upload or download. It occurs much less often if I connect and just browse files on the server, or if I delete a file somewhere.

This certainly looks like a FileZilla problem, having nothing to do with any backup software.

FileZilla 3.9.0.3, Win7/64, nothing strange in the configuration.

Further experimentation: I take it all back. The error seems to be occurring because of some sort of collision with Carbonite. If I terminate all Carbonite processes, rather than just suspending the backups, the error stops. In short, the error appears to be occurring not because Carbonite is actually trying to back up the file, but because Carbonite is trying to mark the file as one that needs to be backed up. How it accomplishes this task, I don't know. What remains clear, however, is that there was no problem before FileZilla 3.9, so it's a FileZilla change that has triggered the problem.

I can reduce the problem by telling Carbonite not to back up the entire C:\Users\MisterNeutron\AppData\Roaming\FileZilla directory, but telling to back up only selected files within it (the standard xml files that are always there). But it still pops up periodically.