Handling of linux hard/soft links while copying to a Window's system

I have a linux share mapped to a Window's "drive letter". I use dopus to copy directories/files from linux mapped drive to a local Window's drive. But directories/files accessed through linux mapped drive have soft links as well as hard links defined within that environment.

My question: how dopus handles such links while copying directories/files, referred by these links in the linux environment, to a Windows directory/file system? And, conversely, if these links are "preserved" during the copy process, how dopus will handle such links while copying from the Windows environment back to the linux system?

You would get individual copies of each thing.

Sorry Leo... don't understand.

In a linux filesystem, given an existing file/directory, if one sets a "hard link" to this file, an inode will be inserted in the file's "container" which holds content + inode when file was created. And if one sets a "soft link" to this file, the "soft link" will hold a string referring to the location of file in filesystem.

So, when dopus copies hard or soft link file/directory to a window's file system, will the destination copied file hold content of inode and/or string or dopus will duplicate the content of the original file?

Each file in the destination would be an individual copy of the data from the source file/link.

You'll probably see the same using almost any tool on the Windows side, especially for Linux filesystems that most Windows software has no in-depth knowledge of.

If you're still unsure, why not try it and see what happens? That's the easiest way to find out exactly how things work.


Which means that, for every link (soft or hard) on the linux filesystem, the content of the "file being linked to" would be copied to the destination window's file system... which would increase size of files on destination window's hard disk... Will make some test to see what's going on exactly...BTW doesn't Windows have a similar "file link mechanism" as the one available in linux filesystem?

If so, couldn't this mechanism be used not to copy content of linked files but only pointers to the destination file?

Very few tools will recreate links of any kind, and those that do need to be told explicitly how you want them to do so, since there is no configuration which makes sense in all situations. For example:

  • If you're copying a link to a USB HDD to send to someone else, turning that into a softlink pointing to the original would not make sense; similarly if you intend to wipe the original drive; but it might make sense in other situations.

  • Even if we're only considering links between files within the destination copy, and not between destination and source, if two hardlinks in completely different source folders point to the same file, no software I know of will check if both links are included in what's being copied overall so that they can only create one copy of the file in the destination. The overhead and complexity of that, for something that almost never matters, and may not even be what the user wants, just does not make sense for general-purpose file copying operations. (Especially in tools that can apply copy filters and copy things from completely arbitrary collections of paths that need not be related to each other, or even be on the same drive.)

Opus can create individual links via explicit commands (they're in the Copy Files > Create Advanced Links menu) but few tools other than RoboCopy (when explicitly told to) will create them as part of copying selected folders between places. Some backup tools will recreate them, but typically only when backing up an entire drive.

This is also assuming you've mounted the Linux filesystem in a way that exposes the fact the links exist to the Windows API, which depends on the mounting method.

It has something similar, yes.

1 Like

Hi Leo,

Thanks for the reply. I will try using rsync on linux server to copy files/links on other linux stations on same local network. Hope this will solve my problem and we can close this ticket.