I'm having trouble finding a portable file manager/browser that allows me to access Windows shares via SMB but doesn't use the built-in Windows network neighborhood/drive mapping API's.
Both FreeCommander and CubicExplorer call the native Windows API's, which means any drive I map in them stays mapped on the machine after I close the app and/or shutdown PAM.
I've used muCommander and it works fine using SMB:// syntax but it requires Java to run and can be flaky.
Does anybody out there have any suggestions?
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
Follow us on Twitter
All you're wanting is to use the UNC paths (\\computer\share\files) instead of mapping a drive letter. When you map drive
to \\computer\share - instead, just put \\computer\share as the path straight into Explorer.
Note: don't try to run portable apps from UNC paths. Most will fail badly (possibly corrupting data), ones using the new PortableApps.com Launcher will tell you they can't run.
(The smb protocol is the Samba protocol - connecting to Windows shares from *nix etc. It's native on Windows so muCommander will just be faking it.)
I am a Christian and a developer and moderator here.
“A soft answer turns away wrath, but a harsh word stirs up anger.” – Proverbs 15:1
Sorry, I wasn't as clear with my original post as I should have been.
I'm not trying to run a portable app from a UNC path. The portable app exists on a USB drive. I'm trying to connect to SMB shares on a Linux server to upload/download files.
I shouldn't have mentioned mapping drives at all since it just confuses the issue. I'm not mapping drives, I'm using UNC paths as you suggested. Within Windows XP for example, browsing to a UNC path instantly creates an object entry under "My Network Places". Because freeCommander, CubicExplorer, et al, utilize the built-in Windows support for SMB, they too exhibit the same behavior, which in my case is not desired.
In essence, I'm looking for a way to do it similar to using an FTP client with an FTP server. That's how it's implemented in muCommander. The SMB protocol is hard-coded into the app and does not call native Windows components.
and if you do, it will most likely be a windows port of a linux utility, or a cross-platform one such as the java one you already mentioned.
Windows has all of the name resolution, authentication, session management, user management, security, etc. already in place to handle SMB connections to a remote host. People won't generally re-write their own if they're targeting windows as the platform as it simply doesn't make sense not to use the OS provided APIs.
I understand it will likely be a linux port or cross-platform app - I would prefer that actually since I use Linux as well.
The fact that Windows has all of those things built-in is the root of the problem - their implementation is lacking, particularly in security, and if I wanted to use it, I wouldn't be looking for an alternative in the first place.
I guess for now I'll stick with muCommander.
32bit/64bit/unicode (or not)/portable (or not)
Does exactly what you want. UNC or mapped drives (with unmap)
It is native windows but on my network I have no problem accessiing
smb shares on iMAC, FreeBSD, PCLinuxOS, Win XP, Win 7, IPCop, etc.
And it is 1 - 4 panes in multiple styles of view.
http://www.softwareok.com/
launchs fine from PortableApps
If it uses it's own native Samba interfacing then guess it fits the bill. There's also a PortableApps development version
I've been playing with it for about 15 minutes here and it appears to call the same native Windows API's that the other programs call.
I can make a portable version that runs with Java Portable... (you see where I'm going?)
I could probably do that too but I've spent the last couple of days scripting something else.
For now, I was just looking for alternatives but I haven't found any. So eventually, coming up with one that runs off of Java Portable would be the better choice...