Version: (using KDE Devel) Installed from: Compiled sources At the moment it's not possible to define how a kioslave should handle symlinks. Right now creating a "real" copy of the data is not possible, without overriding the copy method and imho this functionality belongs down into kdelibs.
We're getting close. Any chance this request gets considered? :)
Can you describe a use case where this would be useful? (KIO is mostly based on filemanager concepts, and in a filemanager when you copy a symlink you get a symlink).
Well, I do file management on the command line using cp (hey, these are even POSIX options), but to give you a real answer: While looking at Konqburn¹, I noticed that it copies the files somewhere below ~/.kde, using standard KDE functionality, then burns the whole stuff. Now guess (or try) what happens with copied relative links - right, either dangling or possible pointing to entirely different subtrees. I informed the author about it, but this as well as some other - imho broken - functionality was fine with him and he had no time for it anyways, as he said. Now, my point is that copying and modifying the whole functionality deep in kdelibs is pointless, when it can be put, where it belongs (imho). [1] http://konqburn.sourceforge.net/ (not well maintained, builds only against K3B 0.12.x)
On Thursday 26 April 2007, Carsten Lohrke wrote: > Well, I do file management on the command line using cp (hey, these are even POSIX options) So? KIO provides file management to KDE applies, it doesn't aim at being a POSIX implementation of cp. > While looking at Konqburn¹, I noticed that it copies the files somewhere below ~/.kde, using standard KDE functionality, > then burns the whole stuff. Now guess (or try) what happens with copied relative links - right, either dangling or possible pointing to entirely different subtrees. Relative links should be fine actually, e.g. a link from "foo" to "bar" in the same directory will still work even after burning onto a CD... So I presume you're referring to links that point outside of the tree being burned, or to symlinks with absolute paths. But what I'm still missing is: why would resolving those symlinks be the right thing to do? Imagine you have a symlink to ".." - would you then copy an infinite number of directories to the CD? ;) Imagine you have a symlink to a directory out of the .kde subtree; when looking at the size of .kde you thought it would be 80MB, but when burning it that big directory is getting copied onto the CD and it doesn't fit anymore... Not good.
No links won't work fine, you just choose the most trival example. Take having /home/user/data/ and a symlink pictures -> ../pictures in it. When you now copy /home/user/data/ to another location, at a different path depth, kioslaves let the symlink remains as it is, but the target directory has either no pictures directory sibling (dangling link) or by accident even has one, but with comletely different content. Depending on the action the user wants to perform, he may want to a) create a real copy of the data, turning the symlinks into directories b) let the kioslaves automatically kill dangling symlings c) have the symlinks autmatically adjusted to the new location So, the situation, that you may shove a copy of your data to a place that matching included symlinks, leading to size not matching the target iso, tape, etc. exists right now. The problem that your copy isn't a real copy - the data may change while the user works on it, not noticing that his copy symlinks to it - exists right now. And if the copy should include symlinked data, scrap symlinks ointing ouside of the base directory of the copy or data on other file systems (-x option in cp), matches a target size, etc. is up to the discretion of the user*, who knows what he wants to do (a warning if the fs space is going to be exceeded is welcome, of course). > Imagine you have a symlink to ".." - would you then copy an infinite number of directories to the CD? ;) Recursive symlinks are a different story, but that's beside my point. > Imagine you have a symlink to a directory out of the .kde subtree; when looking at the size of .kde you thought it would be 80MB, but when burning it that big directory is getting copied onto the CD and it doesn't fit anymore... Not good. Yes - right now, kioslaves trick the user behind his back. In some cases this is the wanted functionality, in some cases it's not. [*] The user may here be the developer or the user of the application, depending of what type of application we have.
OK, I agree that options a+b+c would be nice to have, although I still see a large amount of possible problems with option a, and c sounds like black magic unless the application has additional knowledge about how to adjust the symlinks. Both b and c sound like something that could be done by the application after doing the copy though. Looking for dangling symlinks recursively and killing them or adjusting them. This allows much more flexibility (e.g. in the algorithm used to adjust them) than doing it all in KIO. So only option a) is missing in kio, IMHO. But I disagree with this: > > Imagine you have a symlink to a directory out of the .kde subtree; when looking at the size of .kde you thought > > it would be 80MB, but when burning it that big directory is getting copied onto the CD and it doesn't fit anymore... Not good. > > Yes - right now, kioslaves trick the user behind his back. No, they don't. You see 80MB (which doesn't include the size of the linked data, only the actual data that is inside the directory, like with `du -sh`), you get 80MB in the copy. No trick at all.
Doesn't seem likely, sorry. People who would benefit from these options are most likely people who already use the command line to manage their files, so it wouldn't actually be that useful to them anyway. For everyone else, it would just be confusing.