Summary: | Changing upper/lowercase on renaming a folder on a CIFS mount triggers multiple bugs | ||
---|---|---|---|
Product: | [Frameworks and Libraries] frameworks-kio | Reporter: | Alexander Ewering <ae> |
Component: | general | Assignee: | KIO Bugs <kio-bugs-null> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | bugseforuns, kdelibs-bugs, kfm-devel, nate |
Priority: | NOR | ||
Version: | 5.72.0 | ||
Target Milestone: | --- | ||
Platform: | Neon | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Alexander Ewering
2020-09-14 16:26:12 UTC
Can reproduce on neon unstable. When I follow the same steps with Nautilus file manager installed on the same system, renaming just fails without any feedback. Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.23.80 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.3 Graphics Platform: X11 Reason #487,498 not to use manual mounts :) (In reply to Nate Graham from comment #2) > Reason #487,498 not to use manual mounts :) If you know of a robust way to "properly" make a CIFS share available so that it can be universally accessed, including by stuff like Apache, FreeFileSync and other non-KIO-aware apps, I'm all ears That's what kio-fuse is supposed to do. (In reply to Nate Graham from comment #4) > That's what kio-fuse is supposed to do. Thanks for the feedback despite this clearly not being a support forum ;) I'm not sure how you're supposed to use kio-fuse for that... the path that kio-fuse creates is different each time as far as I can tell (/run/user/uid/kio-fuse-xxxxxxx), so there's no way to even make a symlink to it so that I have it under a 'sane' path like ~/foobar. So there's no way either to configure Apache to point to it. Or am I missing something? Also, would kio-fuse automatically re-mount the path if the share disappears (say, server is turned off) and then later reappears? (that's all stuff I can (and do) achieve with plain mounts running from a minutely cron job.) kio-fuse is supposed to mount the FUSE path on demand, in response to explicit user actions that require it. Its not meant to be a permanent mount. Perhaps the real question is why you want to point apache as a permanent CIFS mount. That's a highly unusual use case. :) Typically I see this sort of thing done on a headless server (and I have done it myself back in my sysadmin days). What exactly is the use case here? Can you explain it in more detail? Maybe we can figure out a better alternative. (In reply to Nate Graham from comment #6) > kio-fuse is supposed to mount the FUSE path on demand, in response to > explicit user actions that require it. Its not meant to be a permanent > mount. Perhaps the real question is why you want to point apache as a > permanent CIFS mount. That's a highly unusual use case. :) Typically I see > this sort of thing done on a headless server (and I have done it myself back > in my sysadmin days). What exactly is the use case here? Can you explain it > in more detail? Maybe we can figure out a better alternative. I'm an absolute export at creating unusual use cases ;) I frequently do development on hybrid mobile apps (think Cordova, or whatever it's called these days...), and I test them in the browser and on the phone in parallel. XCode has (or at least used to have) the nasty habit of not being very cooperative when an XCode project is opened from a network share (which would be the proper way to do it). So instead, I opted for always putting the XCode project on the local hard drive in the Mac, and then instead mount that on my Linux machine, where the IDE (I'm not using XCode as an IDE, just for device deployment) and the browser (for testing) reside. So, Apache on the Linux machine has to mount the share from the Mac where the XCode project (and thus, the web part of it) is. I agree that's unusual, but I can't think I'm the only one who in some way wants Apache to host a "website" residing on a network share? :/ To derail this bug report further: I cannot emphasize enough how highly I respect the KDE developers and designers, it is by far the most powerful and useful desktop on the planet, on any platform. Thank you! (I could of course also put an Apache on the Mac, but that would further complicate things) Thanks for the explanation. It is a very unusual use case, but it seems like a valid thing to do in such an awkward situation. |