"include symbolic links" not working - What I'm doing wrong?

[aura]

I have a directory "shareA" in PC A where I have only symbolics links to files distributed in many directories in the PC.
I have a remote PC B sharing his own directory "shareB"
PC B is a laptop and I want to get ALL THE FILES link to "shareA" loaded in "shareB"
At this moment, when I sync, the symbolics links are copied to "shareB"
then if I disconnect the share, I can not access the files from PC B.

I want FreeFileSync follow the links and copies the files to "sahreB".
I tried clicking ALL the options in the "include symbolic links" but nothing works.. the behaviour is always the same... only symbolics links.

What am I missing ? Thanks for any help.

[therube]

Did you take this into consideration?

Note:

Windows: Copying symbolic links requires FreeFileSync to be started with administrator rights.

[aura]

Thanks for the answer.
Yes I run FreeFileSync in administrator mode. But the behaviour is what I told before.
I have checked again just in case.. but nothing change.
I also made a test with a local directory (in case the problem is related with the remote connection) but same behaviour.. just copy the links, not the files.
Thanks for others ideas.

[therube]

In Comparison settings
Include symbolic links, you've checked Follow (rather then 'As link')?

---

I'm totally confused by (Windows) symlinks?

As in if

existing:
c:/real/a.TXT

mklink c:/sym/symA.TXT c:/real/a.TXT

DIR c:/sym/
08/28/2023 12:16 PM <SYMLINK> symA.TXT [c:\real\a.TXT]

Yet... clicking symA.TXT fails to open c:/real/a.TXT ("nothing" happens),
likewise, FFS gives an 'ERROR_FILE_NOT_FOUND' message?

Though, if i

c:/real/a.TXT

mklink c:/real/symA.TXT c:/real/a.TXT

with both the symlink (link) & the real file (target) - in the same directory, that will work.


If ? on Windows, the Link & the Target need to be in the same directory "to work", then other then being able to access the same file name, by a different name, what is the point?

Do note that FFS, when it copies symlinks - as Follow, & assuming the Link & Target need to be in the same directory, will duplicate the contents of the Target in FFS's target directory.

If symlink, in Windows, allowed (& maybe I'm doing it wrong?) Link / Target in different directories (per my first description, & as you seemingly have) then when you were to backup the "Symlink" directory, it would "Follow" to the Target location & copy that data to FFS's target directory, as expected.

So... ?


(I've always found Windows "links" braindead, compared to Unix, so have generally ignored them.)

[therube]

If you had "hard" links, that works.
Do note that a "hard" link *IS* the very same, *IS*, the file it is linked to.
(So anything you do to either end affects "both" [as they are the very same file].)

Problem with hard links, is that Windows gives you very little "guidance" to know that a file is a hard link, rather then "just some separate file".
(A program like Link Shell Extension (LSE) may help.)


(I've always found Windows "links" braindead, compared to Unix, so have generally ignored them.)

[Zenju]

mklink c:/sym/symA.TXT c:/real/a.TXT

You need to use backslash, not slash to make it work properly.

[xCSxXenon]

More info from Microsoft:
https://learn.microsoft.com/en-us/windows/win32/fileio/hard-links-and-junctions
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/mklink

[therube]

(

You need to use backslash

Oops, sorry about that.

I find it far more difficult to type \ compared to /.
So when I typed, above, I used /.
When I created, which was successful, I used \.

Though getting anything meaningful out of that, is a different matter.

Win7, should that matter.

Now, when particular programs allow either, both, or a combination of \/, I always use / ;-).
)

[therube]

Win7, should that matter.

And oddly, using ln (as opposed to mklink), the same type of links I created originally, do work as expected (in FFS).

C:\TMP\BRU\real1>ln -s c symbolic/CCC
ln 2.933
c
1 file linked

C:\TMP\BRU\real1>ln -s c symbolic/CCC.TXT
ln 2.933
c
1 file linked

C:\TMP\BRU\real1>ln -s c symbolic/CCC.lnk
ln 2.933
c
1 file linked


Note DIR & how the links are shown.
With the newer created CCC's having "relative" linkages where (some of) the mklink created links do not.

a.sym "linked to" [a]
- but "a" is not in the current directory, so I suppose if it is looking for "a" in the current directory, that would be a good reason why it fails.

& yet, Properties on a.sym shows:
> Target: C:\TMP\BRU\real1\symbolic\a
AH! That is wrong, isn't it. It should show:
> Target: C:\TMP\BRU\real1\a

08/28/2023  12:00 PM    <SYMLINK>      a.sym [a]
08/28/2023  12:06 PM    <SYMLINK>      a.TXT [a.TXT]
08/28/2023  12:03 PM    <SYMLINK>      a.TXT.sym [a.TXT]
08/28/2023  02:58 PM    <SYMLINK>      abc [xyz]
08/28/2023  02:59 PM    <SYMLINK>      abc.TXT [xyz.TXT]
08/28/2023  11:59 AM    <SYMLINK>      c.sym [c]
08/28/2023  02:59 PM    <SYMLINK>      CCC [..\c]
08/28/2023  03:00 PM    <SYMLINK>      CCC.lnk [..\c]
08/28/2023  03:00 PM    <SYMLINK>      CCC.TXT [..\c]
08/28/2023  12:13 PM               601 new.TXT
08/28/2023  12:15 PM               711 new2
08/18/2023  12:49 PM               328 symhardnew2.TXT
08/28/2023  12:16 PM    <SYMLINK>      symnew2.TXT [c:\tmp\bru\real1\new2.TXT]
08/28/2023  12:13 PM    <SYMLINK>      synnew.TXT [new.TXT]
08/28/2023  12:00 PM    <SYMLINK>      x.sym [x]
08/28/2023  02:58 PM               891 xyz.TXT


[therube]

First case, I used full paths for both Link & Target.
Second case, I used full path for Link, but a relative link for Target.

Both links are created, though the First case is valid, Second case fails.

C:\TMP\BRU\real1>mklink c:\tmp\bru\real1\symbolic\CCC-mklink+path c:\tmp\bru\real1\c
symbolic link created for c:\tmp\bru\real1\symbolic\CCC-mklink+path <<===>> c:\tmp\bru\real1\c

C:\TMP\BRU\real1>mklink c:\tmp\bru\real1\symbolic\CCC-mklink+pathless c
symbolic link created for c:\tmp\bru\real1\symbolic\CCC-mklink+pathless <<===>> c


So the Second case is creating a Target: (in Properties) relative to the Link's path.
And that is why it is creating something that fails. (Did I mention, braindead.)

On the ln end, it is fine; relative or full path(s), on Link or Target ends - work:

C:\TMP\BRU\real1>ln -s c:/tmp/bru/real1/c symbolic/CCC-full-target-path
ln 2.933
c:/tmp/bru/real1/c
1 file linked

C:\TMP\BRU\real1>ln -s c symbolic/CCC-full-target-pathLESS
ln 2.933
c
1 file linked


[therube]

Picture31.png, here, https://blogs.windows.com/windowsdeveloper/2016/12/02/symlinks-windows-10/
shows correctly what should be happening
- though it does not, from what I can see, in Win7 (at least with mklink.exe).

[therube]

@aura,

shareA

Open shareA on "PC A".
Click on a link. Does the file "open" (or do what it should do)?
IOW, is the link actually valid?

I have a remote PC B sharing his own directory "shareB"
PC B is a laptop and I want to get ALL THE FILES link to "shareA" loaded in "shareB"

Ah, can you "remotely" share a link to PC B from PC A, or more aptly, will FFS 'Follow' a link from PC A & copy it to PC B/shareB?

(Seemingly that answer should be, Yes. Heh, or maybe not.)

However, if c:\alias is created as a symbolic link, a request to \\remote\c$\alias will likely result in an error, as the link will be resolved to c:\target on the local computer (which may not exist).

[aura]

Thank you for so much information. I have to make many tests to check all your options.
From all your comments I note these points:
- I know Linux/Unix is much more powerfull with links than windows.. but my systems are windows ;-(
- I understand the difference between Hard and Soft links. I have to use Soft links. I can not use Hard to link.
- I see many of your suggestions are based on commands. I will test them like this. But my usage is based on the graphical interface. I generate the symbolics links copying and pasting symbolic link.
Anyway, thank you for all the info. I will keep in touch as soon as I can make all the tests.