Problem with Windows shortcuts

Try "Interpret Windows shortcuts as links" -> Yes, and "Treat Windows shortcuts as target in listings" -> Yes.  This tells Serv-U to pretend that the shortcut file is actually the target it's pointing to.  In other words, the directory listing information returned by Serv-U will pretend that the target of the shortcut is actually present in the directory being listed rather than the shortcut file.  If "Treat Windows shortcuts as target in listings" is No, then Serv-U returns a "link" in the directory listing and the client software has to perform additional logic to learn more about the target file (which SyncBackPro apparently doesn't do).

Thank you for your reply but your suggesting that I use the default settings so of course I already tried those. It does not matter if one or both of those settings are set to "No" or "Yes", Serv-U still reports the shortcuts as being Unix file types. That's the reason why SyncBack ignores the shortcuts on the server.

Both Syncback and Serv-U tech support has been fantastic. Both companies went directly to their engineers and figured out what was causing the issue.

The SyncBack tech seems to think it's odd that Serv-U reports the shortcuts as Unix files since they are Windows shortcuts and the FTP server is installed on a Windows machine. He also said that's not normal behavior but the Serv-U tech said this is RFC-compliant behavior. So which company needs to make changes???? All I know is that I've used SynBack for many years and with many different FTP servers and Serv-U is the only server that I've encountered this issue with. That's not me finger pointing; just my experience.

Through further testing, I found out that this problem happens with FTP and FTPS connections. It does NOT happen when I use a SFTP connection. At any rate, SyncBack created a beta version that works around this issue.

The default value for "Treat Windows shortcuts as targets in listings" is "No", so you would need to modify this to "Yes" in order to test out my settings.

Serv-U reports the shortcut as a Unix style link because, for FTP, Serv-U uses "Unix style listings" for the LIST command and "Interpret Windows shortcuts as links" is "Yes".  Prior to the creation of the optional MLSD/MLST commands that standardized directory listings for FTP, FTP servers were free to report their directory listings in any format they chose.  Unix style listings was one of the more popular formats.  The following example shows how changing "Treat Windows shortcuts as targets in listings" affects the LIST command response issued by Serv-U:

LIST information for a shortcut file with "treat as target" -> No:

lrwxrwxrwx   1 user     group        1147 Jun 10 16:41:28 2013 shortcut-7z920-x64.msi

The 'l' at the beginning means link.  The size is for the .lnk file itself.  The file name on the end is for the shortcut itself.

LIST information for a shortcut file with "treat as target" -> Yes:

-rw-rw-rw-   1 user     group     1376768 Apr 11 12:56:20 2013 shortcut-7z920-x64.msi

I have listed the same file here after changing the setting in Serv-U and refreshing.  The 'l' is gone because Serv-U is treating the shortcut as if the target file existing in the directory being listed.  It also includes size information and modification date/time for the target file instead of the shortcut itself.  However, the file name is still for the shortcut itself.

This issue does not exist for SFTP because the format of the directory listing is already standardized.

Message was edited by: Doug Papenthien Corrected information about the file name in the listing of a shortcut/link

"The default value for "Treat Windows shortcuts as targets in listings" is "No", so you would need to modify this to "Yes" in order to test out my settings."  Sorry, I got my "Yes" and "No" mixed up in my previous post. Regardless, it does not matter if it's set to "No" or "Yes" with regards to SyncBack. It fails to see the shortcut on the server but I appreciate your explanation because it helps me better understand just what that setting does.

This is from the Serv-U engineer but I do not know what settings were used:

...

COMMAND>     MLSD                 150 Opening BINARY mode data connection for MLSD.                Type=OS.unix=slink:/change_remixes_the_war_within.zip;Size=979;Create=20130603145656.499;Modify=20130603145656.500;Perm=rwfad;Win32.ea=0x00000020; change_remixes_the_war_within.zip - Shortcut.lnk                 226 Transfer complete. 1,777 bytes (626 compressed to 35.23%) transferred. 0.61 actual KB/sec,  1.74 effective KB/sec. STATUS>              Transferred 1,777 bytes (626 compressed to 35.23%). 9.70 actual KB/sec, 27.55 effective KB/sec.

...

I'm assuming Serv-U reports the shortcut as a Unix file type regardless of that setting. That would explain why SyncBack ignores the shortcut as if it was not being reported by the server.

I was also told by Serv-U support that I could disable MLSD/MLST in the “Server Limits & Settings | FTP Settings” menu, then edit the “LIST” command parameters, and set the listing style to “IIS” or “DOS” but I did not try that because I did not know if that would have any adverse effects. Presumably, that would change Type=OS.unix to something SyncBack would not disregard.

"This issue does not exist for SFTP because the format of the directory listing is already standardized." Can you elaborate on this a little?

The suggestion to disable the MLSD command is a good one, if only to see if it starts working as expected.  I had assumed that SyncBack was using the older LIST command, which apparently it's not.  After disabling MLSD, I don't recommend changing the list style to IIS or DOS.  By default, it'll use the UNIX style listings I mentioned before (be sure you've got that setting for "treat shortcut as target" set to "yes" ).  At that point, the directory listings you see in the client will look like the ones I posted and not the "Type=OS.unix" style you just posted about (that's the standardized response for MLSD).

The SFTP specification was better thought out in terms of how directory listings are handled and it even includes specific attributes and commands that make working with symbolic links (shortcuts to Serv-U) easier and more straight-forward.  Because of this, it doesn't surprise me that SyncBack and Serv-U agree on how to handle the symbolic link when using SFTP.

Thanks Doug for all of the info. Very helpful