Opened 13 years ago

Last modified 5 years ago

#1171 closed Bug report

Rename errors

Reported by: kogger Owned by: Tim Kosse
Priority: normal Component: FileZilla Client
Keywords: Cc: kogger, Tim Kosse, Alexander Schuch
Component version: Operating system type:
Operating system version:

Description

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.

Attachments (1)

realpath_bug.c (257 bytes) - added by Tim Kosse 13 years ago.
Minimal sample to reproduce problem

Download all attachments as: .zip

Change History (13)

comment:1 Changed 13 years ago by kogger

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

comment:2 Changed 13 years ago by Tim Kosse

Can you delete the file after restarting FileZilla?

comment:3 Changed 13 years ago by 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.

comment:4 Changed 13 years ago by 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.

comment:5 Changed 13 years ago by 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)

comment:6 Changed 13 years ago by 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.

comment:7 Changed 13 years ago by Alexander Schuch

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

comment:8 Changed 13 years ago by 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.

comment:9 Changed 13 years ago by 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.

comment:10 Changed 13 years ago by 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>

comment:11 Changed 13 years ago by Tim Kosse

My email address is tim.kosse@…

comment:12 Changed 13 years ago by 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.

Changed 13 years ago by Tim Kosse

Attachment: realpath_bug.c added

Minimal sample to reproduce problem

Note: See TracTickets for help on using tickets.