Rename errors

[kogger]

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)

Log
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
or directory

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.

[kogger]

Updated Xsan to version 1.4 with no change for this bug.

[Tim Kosse]

Can you delete the file after restarting FileZilla?

[kogger]

Hi,

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.

[kogger]

hello again,

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
same bug.

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.

[Tim Kosse]

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
is based)

[kogger]

Hi codesquid,

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.

[Alexander Schuch]

Is there any feedback on this? Does it maybe got solved already?

[kogger]

Hi ci-dev,

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.

[Tim Kosse]

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
clientside.

[kogger]

Hey codesquid,

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.

Password:

Access denied

Using keyboard-interactive authentication.

Password:

Remote working directory is
/Volumes/Storage/Data/Homes/user1
psftp> put test.txt

local:test.txt =>
remote:/Volumes/Storage/Data/Homes/user1/test.txt
psftp> ren test.txt test2.txt

/Volumes/Storage/Data/Homes/user1/test.txt ->
/Volumes/Storage/Data/Homes/user1/test2.txt

psftp> ren test2.txt test.txt

mv /Volumes/Storage/Data/Homes/user1/test.txt
/Volumes/Storage/Data/Homes/user1/test.txt: no such file or
directory
psftp>

[Tim Kosse]

My email address is tim.kosse@…

[Tim Kosse]

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.

[Tim Kosse]

Minimal sample to reproduce problem