cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 9

Problem with Windows shortcuts

Jump to solution

I am testing a few FTP servers, before I buy, and I encountered an issue that is presumably only affecting Serv-U.

I'm using a program (SyncBackPro) to sync files on a server with files on a laptop via FTP. There are some Windows shortcuts in the directories that are to be synced. The problem is Serv-U does not appear to be providing any size or time/date info for the shortcuts so SyncBackPro thinks they do not exist on the server even though they do. As a result, SyncBackPro wants to copy the shortcuts from the laptop to the server, even though they already exist on the server, and also copy the executable files, that the shortcuts point to, to the laptop.

I have already tried adding the 'Interpret Windows shortcuts and links' rule with a "no" value in the directory listings settings. This did not solve the problem. With this set to "no", SyncBackPro no longer wants to copy the executables to the laptop but it still wants to copy the shortcuts to the server.

Here's what happens with each sync with the rule set to a "no" value:

  1. First time a sync is run: Serv-U does not seem to serv a time/date or size for the shortcut on the server so SyncBackPro thinks it does not exist on the server so the file is copied to the server.
  2. Second time a sync is run: SyncBackPro deletes the shortcut on the laptop because it thinks it does not exist on the server.

As you can see, the result is the shortcut is ultimately deleted from both computers. This does not happen with any of the other FTP servers I've tested.

I also tried adding the 'Treat Windows shortcuts as target in listings' rule with a "no" value but this did not seem to make any difference.

I really like Serv-U but this makes it unusable for me. Is there a way to fix this behavior?

0 Kudos
1 Solution

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.

View solution in original post

0 Kudos
6 Replies
Level 11

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

0 Kudos

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.

0 Kudos

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

0 Kudos

"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?

0 Kudos

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.

View solution in original post

0 Kudos

Thanks Doug for all of the info. Very helpful

0 Kudos