Bug 426528 - Changing upper/lowercase on renaming a folder on a CIFS mount triggers multiple bugs
Summary: Changing upper/lowercase on renaming a folder on a CIFS mount triggers multip...
Status: CONFIRMED
Alias: None
Product: frameworks-kio
Classification: Frameworks and Libraries
Component: general (show other bugs)
Version: 5.72.0
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: KIO Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-09-14 16:26 UTC by Alexander Ewering
Modified: 2021-11-30 17:40 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Ewering 2020-09-14 16:26:12 UTC
SUMMARY

Changing the name of a folder on a CIFS share mounted from a macOS server (via an actual mount, not via smbfs:// or similar), and ONLY changing the CASING of the name (say, Foobar -> foobar) brings up an avalanche of odd behaviours:

1) Warning dialog ("This action will overwrite the destination")
2) When "Cancel" is clicked, the folder has apparently been renamed (case changed)
3) Trying to rename the folder again does absolutely nothing (left-clicking the selected folder or choosing Right-Click -> "Rename" doesn't bring up any kind of dialog)
4) When navigating to a different containing folder and then back, the case is suddenly reverted to before the rename operation. (I guess it has never been actually renamed, but only the DISPLAYED name has been updated after the failed rename operation).

SOFTWARE/OS VERSIONS
KDE Plasma Version: 5.19.4
KDE Frameworks Version: 5.72.0
Qt Version: 5.14.2
Comment 1 Patrick Silva 2021-11-23 20:33:30 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
Comment 2 Nate Graham 2021-11-24 19:17:50 UTC
Reason #487,498 not to use manual mounts :)
Comment 3 Alexander Ewering 2021-11-24 21:03:12 UTC
(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
Comment 4 Nate Graham 2021-11-24 21:26:30 UTC
That's what kio-fuse is supposed to do.
Comment 5 Alexander Ewering 2021-11-25 13:08:51 UTC
(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.)
Comment 6 Nate Graham 2021-11-29 18:59:27 UTC
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.
Comment 7 Alexander Ewering 2021-11-29 19:15:18 UTC
(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!
Comment 8 Alexander Ewering 2021-11-29 19:16:41 UTC
(I could of course also put an Apache on the Mac, but that would further complicate things)
Comment 9 Nate Graham 2021-11-30 17:40:40 UTC
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.