Some files are impossible to delete, rename or ...

Hi ...

Please look at this zipped movie:

http://io2o.com/DeletingFilesFolders.zip

As You can see, I can not delete some files (which has non standard chars in their names).
This case also relates to renaming files or downloading them from remote server.

Files which corresponds to above movie are:
"Elementy usunięte.dbx"
"Elementy wysłane.dbx"

There for sure are probs with encoding of files and/or taking their names?
You schould know that better.

Regards and Respect

Btw. As I promised I have just today made an upgrade from Home to Pro.

Thank you for purchasing the upgrade.

I think the bug is with the server. Does it even return the correct file names in the directory listing? Check the raw directory listing.
Is your FTP server compatible with UTF8?

It would always help if you post the complete log of your FTP session.

Regards,
Mat

I do not know if there is any difference for this case, but it was SFTP session and I have not tryed that by FTP.

In fact, yes. Some chars in file's names was recoded incorrectly from cp1250 to iso2 and that was the main reason I would like to delete those files.
But I think there schould be no problems with that, becouse in real, there are many other possible cases like that. But there are.

How I received this case:
Under Windows I have zipped some folder and then move it to Linux.
Then I have unzipped this folder under Linux and file's names was incorrectly recoded.

Becouse non standard chars encoded by cp1250 on Windows are incorrectly reading on Linux there are some probs (becouse linux use here iso2 encoding for file's names).

I had to do this by WinSCP, sorry, I had no choice

Session log I will sent to You by e-mail. I would not like to publish this file here. Please confirm receive of it.

Regards and Respect

Hmm ... which mail use for contact with You directly?

Hello ..

We need a test account on the SFTP server with the problem. But it's very liklely a bug with the SFTP server.

Regards,
Mat

Hello ..

We need a test account on the SFTP server with the problem. But it's very liklely a bug with the SFTP server.

Regards,
Mat

This is for sure not a bug with sftp server. There is a difference in unix and windows file's names encoding.
Simple test, where You do not need test account:

1. Create file eg. ńswóng.txt
2. Zip this file on Windows, move to the sftp account
3. Unpack this file under Linux (directly from cmd or by any desktop)
4. Connect to sftp by SmartFTP and try to remove this file.

For sure, I know that unpacked file on Linux with name encoded in WINDOWS-1250 will be displaying incorrectly on Linux where file's names encoding is ISO-8859-2. But in fact and in other way it schould work.

And eg. WinSCP has never probs like that and this case I meet often, becouse sometimes is really simplier unpack some zipped archive file (zipped earlier on Windows) than transfering it whole when I need one small file quickly.

Regards and Respect

I'm always surprised what information your statements are based on? Did you run a packet sniffer? Did you read the SFTP draft?

The version of OpenSSH ("SSH-2.0-OpenSSH_4.7") I tested here does not encode the filename correctly. It does not UTF8 encode ń as it should. The RFC says it needs to be UTF8 encoded but this is not the case for this server. You are probably running the same product and therefore experience the same problem. I recommend you to contact the developers of OpenSSH and ask them to fix this bug.

References
- RFC http://www.tools.ietf.org/html/draft-ie ... ilexfer-03
See page 26
The SSH_FXP_NAME response has the following format:
uint32 id
uint32 count
repeats count times:
string filename [UTF-8]
ATTRS attrs

Regards,
Mat
SmartFTP

Hello,

MT, I use this: "SSH-2.0-OpenSSH_5.0" and I still not agreed that this is a server bug. For fact, this case not relates to server.

Let me say again. There is no possible probs with utf8.
There are the probs with difference in encoding on Win and Linux of file names. Becouse Linux when has iso-8859-2 as encoding for file names then it will open incorrectly the cp1250 encoding. That is the point.
But anyhow SmartFTP can not delete those files while other softwares can (eg. I have tested other sftp tools and has no probs).

Again:
1. Try to create some file under Windows (eg. filename ałńóć.txt)
2. Zip (or rar) this file under Windows as eg. file.zip
3. Move the file.zip to the some place under Linux.
4. Unzip the file.zip there and then connect to this unzipped folder by SmartFTP via ftp or sftp.
5. Try to rename or delete this file.

Those are very simple steps and this has nothing in relation with server.

Please look at this image (its a screen from kde under Linux):
http://io2o.com/underLinux.png

And please look at this image (its a screen from SmartFTP connected to sftp):
http://io2o.com/underWinBySmartFTP.png

Same as above second screen will show WinSCP.

Those files under Windows before zipping has had names:
"Elementy usunięte.dbx" and "Elementy wysłane.dbx"

And please member that after copying this zip again into Windows and unzipping it again under Windows will show correct file names (becouse encoding is cp1250). File'snames are not broken in fact.

Regards, ML

OpenSSH doesnt UTF8 encode the file names. It means if your computer has a different locale than the server you won't be able to display file names correctly. The RFC for protocol version 3 (draft 2 from 2001) doesn't specify whether the filenames should be UTF8 encoded or not. However all drafts (11 of them) released after draft-2 specify that the filenames must be UTF8 encoded.
The next build of SmartFTP will now detect servers that do not use UTF8 for protocol version 3 and the file names will be sent back to the server non UTF8 encoded as well. Again this only works if both the server and client use the same locale.

Regards,
Mat

Hello intro ..

Please try it again with the latest version. It also comes with a new code page setting which allows you to force ANSI or UTF8. By default it is set to Auto.

Regards,
Mat

As I said, SmartFTP schould allow to work with cases like that and now, as other sftp clients I have tested, SmartFTP works correctly in that point. So I can now back to use SmartFTP again. Thanks and Regards.