Jump to content

Issue Information

  • #000003

  • 0 - None Assigned

  • Unfiled

  • -

  • -

Issue Confirmations

  • Yes (0)No (0)

SmartFTP don't read the extensions

Posted by Edtech on 09 August 2009 - 11:25 AM

When I drag & drop one or more files in SmartFTP since the Windows explore, it don't read correctly the extensions and drop it. Example with ASS files in SFTP (Windows 7 x64 build 7600), the files already exist in this directory and the option "hide extensions for known files" is enabled in the Windows explorer :

[13:13:19] Récupère les attributs de "/home/manga-france/Sources/K-On!/ASS/K-On! 01".
[13:13:19] 2 No such file
[13:13:19] Récupère les attributs de "/home/manga-france/Sources/K-On!/ASS/K-On! 02".
[13:13:19] 2 No such file
[13:13:19] Récupère les attributs de "/home/manga-france/Sources/K-On!/ASS/K-On! ED".
[13:13:19] 2 No such file
[13:13:19] Récupère les attributs de "/home/manga-france/Sources/K-On!/ASS/K-On! OP".
[13:13:19] 2 No such file
If the extension isn't known by the explorer, SmartFTP read correctly the extension and the detection taht the file already exist is correct.

I'm sorry but I do not understand the problem.

If you drag & drop the file "test.txt" since the explorer, SmartFTP create a file on the server with the name "test" without extension. If the file "test.txt" already exist, it doesn't detect it and create a new file. This bug appear only if the file extension is known by Windows (and hided in the explorer).

Updating System Information to: na

Please try it again with the new version we have just released:

Thank you.

The bug is still present. In the transfert list, I have correctly displayed "test.txt" but the file have the name "test" on the server, and detection of existing is wrong.

We are unable to reproduce it.
Please provide logs and screenshots.

Drag and drop of the file "acces.php" since the explorer of Windows 7 Ultimate x64 (french) build 7600. The known extensions of the files are hiden in the explorer.
The file already exist. The transfer use SFTP with key for authentification, but same problem in FTPES (not try other type of connections).

Posted Image

Log in SmartFTP :

[09:49:42] Récupère les attributs de "/home/sites/test/acces".
[09:49:42] 2 No such file
[09:49:42] L'opération a été ajoutée à la file de transfert. Vérifiez la file de transfert pour voir son état.
[09:49:43] Récupère les attributs de "/home/sites/test/acces".
[09:49:43] Attributs récupérés avec succès.

Result : Two file "acces" with and without extension.

Posted Image

Please post the system information from the menu: Help->About "System Information" dialog.

+- System -----------------------------
Microsoft Windows 7 Ultimate Edition
(Build 7600)

CPU Speed : 2400 MHz
Total Memory : 4094 MB
Free Memory : 2749 MB

+- SmartFTP ---------------------------
Version : 3.0.1036.0
Time Stamp : 2009-08-13 01:30:17
Platform : x64
Id : 400054498
Maintenance : 2011-06-30
Days in use : 9

+- Language ---------------------------

+- Internet Explorer ------------------
Version : 8.0.7600.16385

+- Winsock ----------------------------
Winsock : 2.2

Thank you.

We have the same test environment here but we are just not able to reproduce it :-(

We will further investigate it. If you have any other information that would be helpful please let us know.


Updating status to: Confirmed - Ongoing Research

Updating severity to: 3 - Medium

This bug is strange :

Posted Image

Only the PHP file (associated to Dreamweaver CS3 or CS4), isn't send correctly with his extension. I have also the problem with ASS files associated to Aegisub (but not with the iso file, no visible on this screenshot).
It's perhaps a problem with the method used to create the extension association and how SmartFTP read it ? The error is visible only in the Destination column. In others columns, SmartFTP display correctly the extensions.

Another bug in this screenshot, the negative value for the size of the iso file. The real size is 3 176 984 576. An 32bits integer signed ? I use the x64 version, it's perhaps possible to use an 64 bits integer and unsigned.

Edit : An idea perhaps for this bug : I use an user session and install with an admin session via the UAC. All the associations create during installation are correctly managed by SmartFTP, but not the associations create when the application start, also in the current session. If SmartFTP read only the associations for all user and not the associations for the current user, the problem is solve !

Edited by Edtech, 20 August 2009 - 06:40 PM.

Thank you for the update.

We don't know why this happens. Sorry.

Please try the latest version: http://www.smartftp.com/download/
I have added some checks in case the GetFileAttributesEx Windows API fails.

What do you mean exactly with associations?

The association is the link between the extension and the application to open the file. For example : PHP with Dreamweaver, png with the pictures viewer. I guess if the link is create for the current user and not for all users, the detection is incorrect. I'll try with the last build.

Edit : For the size of the file, it's ok with the build 1040. For the extensions, the bug still exist.

Edited by Edtech, 20 August 2009 - 09:14 PM.

Hm. SmartFTP does not create its own association it only reads them from the registry.
Do you mean when you double click the a file nothing happens instead of opening the default application?

Please go to the favorite properties and then check if you have any Auto Rename rules (Transfer->Auto Rename) set.

The auto rename rules is disabled.

Are you try from a user account ? Create a user account et try to transfert file with different extensions.

Yep. We tried to reproduce it on a fresh Windows 7 installation with a non administrator user account.

The problem is not reproducible.

I format my computer this week and I'll retry with a fresh installation directly with the french ISO. For now, I use Windows 7 Ultimate x64 with French MUI. Perhaps a problem with the language.

I reinstall my computer and test SmartFTP. I have sill the problem on my two computer, I don't understand.

0 user(s) are reading this issue

0 members, 0 guests, 0 anonymous users