Opened 17 years ago
Last modified 9 years ago
#1171 closed Bug report
|Reported by:||kogger||Owned by:||Tim Kosse|
|Keywords:||Cc:||kogger, Tim Kosse, Alexander Schuch|
|Component version:||Operating system type:|
|Operating system version:|
It seems that Filezilla is not able to rename a file
twice that is located on an Mac OS XSan (1.3) Volume.
It also seems that filezilla cannot delete a file after
it has been renamed.
Initial file name was test.php. After renaming it once
to test2.php any further attempts to rename or delete
the file errored out. I tries closing the restarting
the application but the results were the same. Seems
like there is some strange file name caching happening
somewhere in the interaction.(please note that I have
shortened the paths for read-ability)
Command: RENAME test.php test2.php
Response: File moved / renamed successfully
Command: RENAME test2.php test.php
Response: Move/Rename test.php test.php: no such file
Command: DELE test2.php
Response: rm test.php: no such file or directory
Tests with other sftp clients (Winscp382 and Tunnelier)
seem to indicate that this is an Xsan-Filezilla
specific issue. Rename and Delete operations worked
normally on other non-Xsan volumes on the server
(i.e:/var/tmp/). I will try to update Xsan today
(version 1.4) to see if it resolves the issue. Just
thought you might want a heads up.
Change History (13)
comment:1 by , 17 years ago
comment:2 by , 17 years ago
Can you delete the file after restarting FileZilla?
comment:3 by , 17 years ago
I just tried it and no. Even after restarting FileZilla I
still cannot erase the file. It seems that there is a
certain amount of cache time involved on the Xsan side of
things. I know for sure that after an extended amount of
time has elepsed that I can alter the same file. I will try
to perform a change on the smae file at regular intervals to
determine exactly after how much time the file becomes
editable again. I'll report back with my findings.
comment:4 by , 17 years ago
Well it's been 8 hours since I renamed a file and it still
won't let me rename it gain or delete it. I should mention
that I am using sftp (ssh2) to access the remote Xsan
Volume. As a earlier I also logged in and performed a
simple touch command on a problem file. That seemed to have
fixed the issue for that particular file at that time.
However any attempts to rename the file again produced the
I would tend to point the finger at Xsan of it wasn't for
the fact that filezilla seems to be the only software to
experience this problem.
comment:5 by , 17 years ago
Does the problem also exists if you try to rename a file
using psftp.exe from PuTTY?
In any case, this is a problem with Xsan, triggered by the
unique behaviour of fzsftp (and possibly psftp on which it
comment:6 by , 17 years ago
Yes the problem does occur when using psftp.exe from putty.
Exact same behavior. I will notify the Apple people and the
developper of Putty.
Thanks for your input.
comment:7 by , 16 years ago
Is there any feedback on this? Does it maybe got solved already?
comment:8 by , 16 years ago
I don't beleive that the issue is resolved yet. I have
submitted to issue to Apple support, the putty development
team and here. No one has gotten back to me about any
possible fix yet. In the meantime I am recommending other
sftp clients to my users.
comment:9 by , 16 years ago
Does it work with the latest snapshot release of psftp.exe?
I spotted an bug in its canonify function a few weeks ago.
Maybe it was related to this issue in some way.
Otherwise, would it be possible to get a temporary test
account on your server? Maybe I can fing the reason, if it's
comment:10 by , 16 years ago
Tried with the latest snapshot and tyhe bug still shows up.
Seems like it's really a problem with psftp. I can craete
an account for you on our servers. How can we get in touch
to coordinate it?
Here is a cat & paste of the session:
psftp file version 0.58.6889.0
psftp> open sftp.hexagram.ca
login as: user1
Using keyboard-interactive authentication.
Using keyboard-interactive authentication.
Remote working directory is
psftp> put test.txt
psftp> ren test.txt test2.txt
psftp> ren test2.txt test.txt
/Volumes/Storage/Data/Homes/user1/test.txt: no such file or
comment:11 by , 16 years ago
My email address is tim.kosse@…
comment:12 by , 16 years ago
Thanks for the account.
The problem is definitely caused by the remote site. In
order to resolve things like symlings, PuTTY (and as such
FileZilla) sends an SSH2_FXP_REALPATH packet to find out,
what's the full path. The server calles the system function
"realpath" if receiving an SSH2_FXP_REALPATH packet.
Unfortunately, realpath returns the wrong directory.
I've attached a minimal C program which shows the problem. I
expect the program to print a filename ending on /bar, yet
it prints a filename ending on /foo
I think it is a bug in the used filesystem driver. Please
contact the Xsan developers and refer them to this thread
and in particular the sample program.
by , 16 years ago
Minimal sample to reproduce problem
Updated Xsan to version 1.4 with no change for this bug.