Hello,
I use a mapped drive from Synology exposed to Windows via CIFS. I created a folder Foo and a symlink foo -> Foo from Linux (the same drive exposed to Linux via NFS). The good thing is that, I don't have issues opening the folder (not the symlinked one) and browsing the contents (most other explorer products fail to even do this). The bad thing is that, it gets confused when I try to open any file via double-click -- falls back to the lower case folder (in this case, a symlink) and fails. Note that the viewer pane has no issues reading the content, so I am hoping it's a minor issue/bug. Please find the attached screenshot for more details.!
CIFS / SMB is assumed to be case insensitive. Things like Samba for Linux go out of their way to ensure this.
It's going to confuse virtually everything that talks to the network drive if it breaks that convention.
(I know Microsoft have just changed Windows to allow even local filesystems to be case sensitive, as part of their plan to turn Windows into Linux, but anyone using that also needs to know it is going to confuse virtually all software on the Windows side. DOS and then Windows filesystems and APIs have been case insensitive for several decades and changing things now is frankly an absurd move on MS's part.)
Opus has support for case sensitive filesystems via FTP, and we may extend that in the future, but I would not expect it to ever be pain free because the entire ecosystem of software and libraries has been developed for Windows has been written for something different, and it's far from trivial to retrofit.
(And, frankly, Microsoft do so many ill-considered things lately, and then pull them or completely change them later when they realise they were bad ideas, that it's hard to justify chasing their tails. Indeed, this change is part of them trashing the way they do Windows/Linux which was only introduced about a year ago and is now completely changing, making our time spent supporting the initial version questionable.)
In short, set CIFS filesystems to be case sensitive or anything talking to them will be confused. The bug is in the file server not following conventions, rather than everything that connects to it.
1 Like
Thanks for the detailed reply, Leo!
Windows supporting NTFS case sensitive file systems is relatively new and I agree it's a bit premature to add full support for it given MS history.
My request is simply asking if Opus can mimic what Windows explorer is doing for the last 8+ years (since I started using the CIFS drive). Note that it can't work with symlinks and that's not my use case either -- I just need to mimic how Windows explorer works with the regular folder (and not convert case while doing anything in it). In other words, explorer has no issues browsing to the folder (not the symlink) and open files/do anything in that file structure.
You're already doing a great job browsing to the folder and reading the content (native pane) -- the only thing that breaks is opening the file content (when passing the filename to the external program). As mentioned above, your program is the only one I found in market that's so close to mimic native Windows explorer behavior when it comes to this case.
I hope asking Opus to do something that Windows has been doing reliably for the last decade or so isn't unfair, especially given that Opus can potentially replace Windows explorer!
I would appreciate if you give a shot trying to resolve this as that would let me start using Opus full blown. Needless to say, I am happy to be a beta tester and help you anyway to resolve this.
Thanks in advance!
Hello,
Just wondering if the native explorer behavior can be mimiced i.e., pass file path as-is (without converting the folder name it to lower case), to the external program when I double-click on a file? That's the only issue that is blocking me from using the program and purchasing a license.
Thanks!
Opus already passes filepaths as-is in almost all situations, including when running Notepad.
e.g. I permissioned a file to deny read access, then launched Notepad on it via Opus:
Opus isn't lower-casing paths or anything like that.
If you have a symlink from foo->Foo then it shouldn't matter which is used, either, since both end up in the same place?
Not sure if you saw the screenshot I attached in my original post -- that is the issue!
If you have a symlink from foo->Foo then it shouldn't matter which is used, either, since both end up in the same place?
In Linux world, yes, but Windows has no idea, which is why I end up with the error I attached in my original post.
The symlink is on the Linux side. If the NAS is set up properly, the symlink should appear as just another folder to remote machine browsing the network share, where both folders have the same contents.
If both foo and Foo are the same folder, with the same permissions etc., then it should not matter which one is used in the path.
What happens if you manually run Notepad.exe from a command prompt, with the filepath using the lowercase "foo"? Does that fail as well? What about the uppercase "Foo" path?
The error message indicates a permissions issue, not an issue finding the path or file. That makes me wonder if the permissions on the symlink are blocking things in some way. Or maybe the CIFS/SMB server on the server refusing to follow symlinks (could be for security reasons) and returns a permissions/access error code.
Why does the symlink exist anyway? Having both foo and Foo be the same folder seems strange and is going to cause problems with Windows software, especially if only one of them really works.
(FWIW, in places we will check what's on disk to get the real path of folder paths which come from commands and favorites. So we could end up using Foo or foo, whichever the network drive tells us exists when we query the folder. But once the lister is in one of them, we usually construct paths to child files by adding them to the folder path without doing that check again, since we already know the case is correct. Notepad itself could be doing something similar, and getting the other answer, maybe only when launched via one method and not others. Both answers should work as well as each other, if the server is set up correctly.)
