Until to my final migration I use to mount a windows partition (NTFS).
There are many valuable windows links on it which assoziate files and folders.
When I access that partition with dolphin it doesn’t recognize/ follow
the links but asks with application to assoziate with that file type (*.lnk).
If I assoziate it with dolphin itself… it does not do.
There are different infos about this situation, some stating dolphin can,
other say it can’t.
Is it possible in any way to have dolphin follow windows links at a mounted
NTFS partition?
Moreover for the future I will transfer the data from NTFS partition
to Linux FS (probably ext4). The windows link files will be copied as is.
Is there are way to have all these links functional:
Either by enabling file manager to follow windows link files,
or by generating ext4 links from the windows links?
At first a read this only out of curiosity because have almost no knowledge about Microsoft Windows and this have no idea what “windows links” are.
But now you are talking about ext4 links and I assume it should become clear what these type of “links” are because you seem to imply that they exist on ext4 file systems and I have no idea.
The title is incorrect. It is not called “link”, it is called “shortcut” (Windows does support the real links - hard and symbolic and more). Shortcuts are just files with the name of the target (it has other information as well). While it is certainly possible to write a tool to parse this file (probably, there are such tools already), I have no idea how to integrate it in Dolphin. Also, the shortcut target can be anywhere, including network location. You need to somehow map these locations to what Linux understands, but there is no way to do it automatically (Linux does not know what drive the partition with your filesystem is assigned in Windows), and you need to decide what to do with shortcuts that point outside of the mounted filesystem.
My 1st scenario (Have Dolphin interpret the shortcuts):
If the windows link/ shortcut and its destination is at the same mounted NTFS partition,
all information is there to follow the link/ shortcut.
As I already said, some sources I found state Dolphin can,
but with some vague restrictions… (?).
So… is it possible to enable Dolphin follow that windows links/ shortcuts?
2nd scenario (Transfer (Copy) NTFS part (including windows link and its destination) to ext4):
Yes, I understand that connection shortcut to destination (probably) is lost then,
due to the arbitrary place where the NTFS subtree has been copied to at ext4.
But - if I get it right - then just after being transfered/ copied all copied windows shortcuts
could be unambigious used for creating a valid ext4 link, right?
By a tool of course (any hint?).
Beware to think this is just a windows problem, please.
As former windows users (like me) are welcome, aren’t they? .
And making them loose valuable information when changing to Linux
would be a unkind hurdle, don’t you think?
(I don’t know how much links are used in Linux filesystem,
but think about the situation of new say “ext5”,
and the devs would annouce:
“Well old ext4 links don’t work anymore, but you can build new ext5 ones - one by one”).
So, does anyone has a hint for me (and some few others) for hundreds++ of valuable shortcuts?
There is a bit exaggerated saying: when going to Linux, forget everything you learned while using Windows.
If I understand now from the above correct what these “shortcuts” are, then they do not exist in Unix/Linux.
What seems to cover it partly is what are called in Unix/Linux “symbolic links” or “soft links” (to differentiate them from “hard links”, that also exist). A symbolic does point to a path of a file on the system. And indeed the file does not have to be exist,although that is normally seen as an unwanted situation.
Hard links however can exist only inside a file system.
Soft links can point outside a file system, but the are not normal files (with or without a Windows file name extension), but they form their own file type .
And of course I encourage you to learn about those hard/soft links in Unix/Linux.
Both featurs are subject of the POSIX standard and thus should be implemented in all Linux file system types (not just ext4).
You really have no chance that something like this is implemented in Linux (Kernel and it’s file system modules) in the future.
Also, please be aware that, Linux is a UNIX® system and, therefore, the “good old” UNIX® rules apply:
Everything is a file.
In other words, a Linux (and UNIX® and, macOS (a BSD UNIX®)) user never, ever, “sees” a disk.
Everything begins at the top of the directory tree – “/” …
Mounting disks is a system administration issue – system administrators mount physical disks to a a “mount point” – a specific directory «which is a file anyway … » in the system’s directory tree – beginning at “/”.
Yes, yes, there is “FUSE” [Filesystem in Userspace] which automagically mounts devices such as USB drives for individual {normal – without system privileges} human users – for the case of GUI interfaces – KDE Plasma or GNOME for example – a graphical user window pops up to allow the user to mount and access the device.
Ditto, files and directories located somewhere in the network – regardless of where on this planet or, any on other planet in the universe, the files you wish to access are physically located.
Which is why, Linux and UNIX® systems usually have the system clock set to UTC – to coordinate the timestamps on the files – regardless of where the file is physically located …
The user, sees, on their graphical or, non-graphical, interface to the system, their local time as specified by their LOCALE user environment variable.
Bottom line, as a simple, normal, Linux/UNIX® user, forget about devices – you can only “see” and access files in the system’s directory tree.
I wonder if you actually read my post before replying.
No, it is not possible in general to unambiguously convert a Windows shortcut to a Linux (sym)link. If you are absolutely sure that all shortcuts inside this Windows filesystem always point inside the same Windows filesystem - it is relatively trivial to write a (shell) script to replace .lnk file with Linux link that points to the shortcut target.
First of all:
For me it seems not very polite to insunuate I haven’t read your post.
In a forum in general it will happen that it’s not easy to understand
what the other mean.
And insunating the other don’t read one’s post isn’t helpful at all,
but spoiling the atmosphere.
You don’t think it might be possible you don’t get what I really mean?
(Surely you will have read my short correction post above)
Well meanwhile I chatted with an open AI.
And it stated that
Dolphin very well can open/ follow windows shortcuts.
(But it doesn’t work for me. Maybe a plugin?)
there are tools to build linux links from windows shortcuts
(Wsh2Symlink, lnk2target, lnk2desktop. None of them I found anywhere).
> pip3.6 install pylnk3
Defaulting to user installation because normal site-packages is not writeable
Collecting pylnk3
Downloading pylnk3-0.4.2-py3-none-any.whl (21 kB)
Installing collected packages: pylnk3
Successfully installed pylnk3-0.4.2
> pylnk3
Tool for read or create .lnk files
usage: pylnk3.py [p]arse / [c]reate ...
Examples:
pylnk3 p filename.lnk
pylnk3 c c:\prog.exe shortcut.lnk
pylnk3 c \\192.168.1.1\share\file.doc doc.lnk
pylnk3 create c:\1.txt text.lnk -m Minimized -d "Description"
for more info use help for each action (ex.: "pylnk3 create -h")
With the output of this script and a few shell commands it should not be very difficult to create sym links for local files.
I try to sum it up - as it seems important to me for all the former windows users:
If you have a NTFS partition mounted,
as of today Dolphin can’t handle windows links (shortcuts) and *.url files.
It probably could be made possible by a plugin;
quite easy for *.url shortcuts;
and for interal shortcuts if they point within the mounted folder
(All information is available then and the shortcut could be traced).
If you have transfered NTFS contents to ext filesystem,
the connection NTFS - ext4 subdir will be lost in general.
I.e. you have to transfer the windows shortcuts to ext4 links.
This could be achieved by a tool/ script
that works on a folder (incl. subdirs): For every shortcut file
that points to within C:\Users\Bla\blub
creates an ext4 link to an appropriate subLink to within /mnt/mywindata/
For the shortcuts in the calling folder that point outside C:\Users\Bla\blub nothing can be done;
but to output them as broken (so they may be fixed in a 2nd run).
Internet shortcuts *.url are even simpler, as they don’t have the
subdir restriction.
It would be nice if all information stored in the *.lnk and *.url files
could be transfered.
Actually I’m really surprised why this issue had not been handled…
ChatGPT is not a subject matter expert. Any time you ask it to help, take the answer with a huge grain of salt. It may be right, but it probably isn’t. That’s probably why it told you about tools that build links from Windows shortcuts but you were unable to find any of them. The easy answer is “they don’t exist, and it made them up”.
As others noted, a WIndows .lnk file isn’t the same as a symlink in Linux. It knows about Windows paths, not Linux paths.
When you mount an NTFS filesystem somewhere (say /media/ntfs), if you have a .lnk file that points to D:\MyFiles\whatever.xlsx, there’s no way for the Linux system to know (a) that that’s what your Windows installation thinks of as the D: drive, and (b) that it should replace D:\MyFiles\whatever.xlsx with /media/ntfs/MyFiles/whatever.xlsx. The next time you mount that somewhere else (say /mnt/ntfs), anything that knew it was at /media/ntfs/ needs to be changed to /mnt/ntfs/.
What you’re asking for could probably be done programatically (probably a script if the .lnk file contains all the info needed in a text format - it’s been a long time since I looked at one to see how it works), but would be ephemeral, because there’s no guarantee that the filesystem will be mounted at the same place every time (I mean, you may decide to do that, but there’s no reason you must mount it the same place every time).
Come on, that is what relative symlinks are for. That is not a problem.
Apparently Windows supports relative paths as well although in my experience every shortcut always had the full path. Could be Windows Explorer limitation.
It is self-evident that I was referring to situations where the mount point was relevant, and that it didn’t apply to situations where the mount point wasn’t relevant.
Both possibilities are valid, and in the case that I was using, the full path would be absolutely relevant.
Please keep in mind I’m about 2 different scenarios about windows links/ shortcuts:
NTFS mounted
NTFS content already transfered/ copied to ext4
Both cases are important for former Windows users.
(Just image all your sym links would be lost by an upgrade/ fs change. Horrible).
For me meanwhile it’s obvious that the second scenario might be solved
by a clever script (as described above).
For the first scenario I’m unsure: Is Linux (a Dolphin plugin) capable to identify
the destination (in the linux fs) of a windows shortcut to the momentary mounted drive?
When you mount something lets say under /mnt , the Windows path C:\ is completely meaningless and unknown to linux. That means C:\blubblub gets mounted under /mnt/blubblub and the Windows filepath in the link points into the void as smth like C:\ does not exist in the linux world.
It’s important to remember that Linux isn’t Windows.
If you have files that are on an NTFS partition and you’re moving files to the ext4 filesystem, don’t move the Link, move the source file.
.lnk files are binary files (I verified this). That said, there are tools that can parse them - generally forensic tools, from what I’ve found - that can help you dereference the link.
But .lnk files can not be used by Linux. Could a plugin be created? Maybe. You’d have to tell it where the filesystem was mounted to use it “natively” or it wouldn’t be able to fully dereference the link if it crosses a filesystem “boundary”. There isn’t a way for it to know the Windows drive letter that your Windows installation assigns to a partition (even looking for things that are normally on the C: drive may not be reliable - after all, you could be mounting an older Windows installation’s partition as a data volume on a newer installation, for example).
I think ultimately, you’re asking the wrong question. You’re trying to use a Windows solution on Linux. The question you should probably be asking is how to migrate your files from Windows to Linux so you can use them - and leave out the Windows shortcut files entirely. They are a Windows-specific solution to a Windows-specific need.
Pardon. But no.
You are misunderstanding the problem.
It is not a windows problem.
It is a migration problem from windows to linux.
The windows links/ shortcuts are a valuable information; an association between different files/ folders etc. In linux these are the sym links.
It is important not to loose these association information (a semantic thing)
when migrating. (That’s why I - for 2 times - gave the example what you might think
if by a linux upgrade all you sym links would get lost).
My question (concering the 2nd scenario) is how to migrate that semantic links
from windows way to linux way. If at all, it is a task for linux.
I’ve to admit I’m kind of reel being misunderstand by you (and at least 2 more) after all these posts;
maybe I’m not good in explaining
.