Version: (using KDE KDE 3.1.4) Installed from: Compiled From Sources The ability to add files to a project via ioslaves. Burn directly from sftp://, nfs://, ftp://, smb://, fish://, etc.
I would really appreciate such a possibility ...
I need this functionnality, I don't have space left on my box and I need to burn data that only accessible via ssh or ftp.
*** Bug 86245 has been marked as a duplicate of this bug. ***
*** Bug 93250 has been marked as a duplicate of this bug. ***
*** Bug 67581 has been marked as a duplicate of this bug. ***
*** Bug 79851 has been marked as a duplicate of this bug. ***
*** Bug 107120 has been marked as a duplicate of this bug. ***
This wish is about two and a half years old, and still as valid as it was then. Any chance to see this implemented at some time?
proably not.... sorry. :(
What's the problem?
it's not trivial at all to include kioslave support and I have other priorities.
What would be the best way to implement this? Would artsdsp's trick work? That is, catch and redirect mkisofs's open(), read(), and stat() calls: the fake open() could pass out fake descriptors for kio-based files and the fake read() and stat() could do the kio interfacing.
that sounds like a good idea...
Hmmm, I suppose buffer underruns become a problem, since some connections can simply not provide data with the minimum speed that a burner/medium requires. In that case the data would need to be prefetched before burning.
> Hmmm, I suppose buffer underruns become a problem, > since some connections can simply not provide data with the minimum > speed that a burner/medium requires. The same can happen with "normal" filesystem access, if the system is busy, or if the stuff is on a slow (or faulty) device (scratched CD) or a networked filesystem (NFS, SaMBa, anything tricky with FUSE, etc.). This is the user's responsibility. The user knows where the files are, knows the risks and consequences.
I disagree. When e.g. kpdf opens a file that is on a remote storage facillity like ftp://example.org, the only drawback is that it might take long to load. However, if k3b cannot get to the data fast enough, then the medium might be broken (disregarding burnfree and such stuff). A possibility is to disable on the fly burning for remote services but that is inconvenient for people who have smb:// on a local network and it would work fine, so disabling it all together is not an option. A warning of some sort is definitely needed though.
*** Bug 132499 has been marked as a duplicate of this bug. ***
> I disagree. When e.g. kpdf opens a file that is on a > remote storage facillity like ftp://example.org, the only drawback is > that it might take long to load. However, if k3b cannot get to the > data fast enough, then the medium might be broken (disregarding > burnfree and such stuff). That is true. But the same can happen if you are burning files from the "real" filesystem. I mentioned a few examples. > A possibility is to disable on the fly burning for remote services > but that is inconvenient for people who have smb:// on a local > network and it would work fine, so disabling it all together is not > an option. A warning of some sort is definitely needed though. If such a disabling of on-the-fly burning or warning is to be implemented, it is logical only if the files on the "real" filesystem are also checked whether they are reliable enough. Maybe k3b could have a list of reliable and unreliable filesystem types and ioslave types. If such a safety net is to be implemented, please let the user modify the list of unreliable ioslaves and filesystem types, or switch the checking completely off.
Sorry, misread comment 15 and did not realize that you were talking about mounted filessystems. I agree with your wish for a configurable safety net.
I think this is related to this bug: In k3b 1.0, the context menus in konqueror does not appear when the url is like system:/users/myUser, which would be myUsers's home directory. Is it only possible to fix it when this bug is fixed, or is a independent new bug?
*** Bug 184966 has been marked as a duplicate of this bug. ***
*** Bug 240683 has been marked as a duplicate of this bug. ***
When you open an ISO image residing via SMB in Dolphin, the I/O first laboriously copies the file into temporary storage and then K3b fails to open the result. When you open the same within K3b, K3b says "File does not exist". K3b should use a local cache to handle remote files. This is what Nero does (also for files on removable media).