https://bugs.documentfoundation.org/show_bug.cgi?id=100137
[email protected] changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|NOTABUG |---
--- Comment #25 from [email protected] ---
https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/
This fault does exist on windows as describe exists. Ok latest Windows 10.
This fault is trigger-able on earlier versions of Windows but done slightly
differently.
http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/
You mklink the directory holding the ods file to another location and it
contains a relative path using ..
documents/test/calcdoc.ods
documents/linked.pdf
documents/test -> desktop/test mklink created link.
When you go to test on XP/7 desktop in this kind of setup and open the ods file
no find PDF. So this is exactly the same error.
Windows 10 latest development you can stuff it up exactly like Linux.
NTFS file system support symbolic and hard links for a long time if you could
create them without manually editing the file system has been the issue. Yes
Windows NT 4 NTFS if you manually edit the file system supports symbolic linked
files.
There is a difference in handling between a windows .lnk file and a Linux
.desktop file. A .lnk file is not a Windows symbolic link commonly confused
as such but should not be.
http://whatis.techtarget.com/fileformat/LNK-Shortcut-file-Microsoft-Windows-9-x
.lnk are officially shortcuts. .desktop file is the Linux desktop equal to a
.lnk file.
0S X is Aliases, Symbolic Links, and Hard Links yes the Aliases that are short
cuts behave like .lnk link files under Windows and .desktop files correctly
written under Linux. Yes on OS X if you go down and really use a Symbolic
link you will trigger the same issue.
So .lnk(windows shortcut), Aliases(OS X) and .desktop files(Linux) should
generate the same kinds of behaviour. If they don't then that is a bug.
My issue is how should we handle the case of symbolic link. The reality is
Symbolic link issue exists on Windows, OS X, Linux most all the other OS
Libreoffice runs on. The difference is user accessibility why users on Linux
hit it more often. Not that the issue is not present.
Working with symbolic links was not considered when ODF was written.
.r.ods or equal extensions where the r is resolve/real would be useful. So a
symbolic link with .r.ods triggers libreoffice to resolve out all the symbolic
links until it gets not a non symbolic link path before opening document.
Current default behaviour would be able to be left alone. There are cases
where you may want linked documents and images to change based on where a
document is linked from.
Of course doing extension change like this would require altering standard so
that all implementations of ODF do the same thing. Also would require
training users to use resolve/real extensions when they don't want symbolic
link behaviour.
So this is a bug as a usage case has not been considered. Person reporting
bug was not aware that Windows and OS X has the same fault hidden.
Martin Nathansen you do need to run some training on the difference between
lnk/.desktop shortcuts and symbolic links because staff not knowing the
difference are going to cause trouble if they start using newer versions of
Windows as well.
-- If you do want to have both working, then use absolute file paths.--
Dennis Roczek please no. Absolute paths in documents are the absolute worse
nightmare when you start having items shared on file servers because people
many not mount the file share in the same directory path on every system. So
Absolute path option does not work in every usage case. We need symbolic
links handled sanely. Also Absolute paths makes documents slightly larger to
store as well.
One of the other bugs in ODF is not being able to define relative base path in
document that relative paths can work from to give Absolute path behaviour
without in fact using a Absolute path everywhere and allowing min modification
if file path is altered.
So what we have here is people being told to use Absolute path that is only a
part work around to issue that will fail badly in many usage cases. The fix
is truly fixing up symbolic link handling and allowing the two use case of
symbolic link in a user controlled way.
So this area of ODF is a problem child. The standard has failed to consider
symbolic link case also really does not handle the case of needing to move a
Absolute path file successfully.
The default is Relative Path because that works in more cases than Absolute
Path. Any issue forcing user to use Absolute Path over Relative Path really
should be considered a bug if there is some way to allow user to remain using
Relative path. This case extending file extension adding a symbolic link
resolve option allows user to remain using Relative Path is a solution.
--
You are receiving this mail because:
You are the assignee for the bug._______________________________________________
Libreoffice-bugs mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
