Use JCIFS Library for CIFS/SMB Networking Protocol Support

[teamamaze]

Use JCIFS Library for CIFS/SMB Networking Protocol Support

[lbdroid]

I don't think that a file browser is really the right context for this kind of thing. A file browser's function is NOT to mount things into the filesystem, it is to manipulate the filesystem as it is presented.

As an example; https://play.google.com/store/apps/details?id=ws.plattner.cifsmanager&hl=en
I don't think that is open source, but it is a more correct approach for mounting network shares into the local device's filesystem.

[amtlib-dot-dll]

@lbdroid Thank you for your reply.

Above all, the `mount' command needs root privilege, which may void the guarantee of the device.

Besides, the function of a file browser is to browse through hierarchies of files, or documents, the idea of which is taken from https://developer.android.com/guide/topics/providers/document-provider.html, but not only through the file tree provided by the Linux kernel. Amaze File Manager has already implemented a zip file browser, but the contents inside the zip file is not a part of the file system either.

[lbdroid]

That is not a zip file browser. It is a zip file HANDLER. A file manager's job is to manipulate the FILESYSTEM, and nothing else.

[amtlib-dot-dll]

Firstly it's glad to see a CIFS solution without root requirement. FTP, SMB, WebDAV and so on are actually files in the file system on Alice's or Bob's computer, just like the App Manager in Amaze File Manager, which calls Android's package manager API but actually operates files behind the Android framework. Thank you for your reading and reply.

[lbdroid]

You clearly have no clue how filesystems are mounted on Linux. Despite being a remote filesystem, the portion of it that is shared to the local user, is MOUNTED INTO the local filesystem. It becomes PART OF the local filesystem. There is no distinction between them.

[amtlib-dot-dll]

Sorry for late reply.

You're right, and for traditional Linux and Unix FTP servers should be mounted as FTPFS, WebDAV servers as WebDAVFS, and zip files as `zipfs'.

But Android is not a traditional Linux. The `mount' command requires root privilege, which is a good excuse for device manufacturers to void the guarantee. No one wants this to happen just because he needs to access a directory in his personal computer or in the server of his company.

So personally a good solution for this problem is to use jcifs.smb.SmbFile as well as java.io.File, to provide such functionality without any root privilege.

Thank you for reading.

[mase76]

I'd also like to see SMB and WebDAV support. This would be a real killer
feature. There are no open source filemanagers which implement
both features. I only know OpenExplorer with SMB support.

[lbdroid]

If anybody is interested in this functionality being implemented in an integrated-ish manner, I suggest that it be implemented as a COMPANION application rather than being baked in to the file manager.

[amtlib-dot-dll]

Could you please speak more clearly? What is a COMPANION application? Is it a plugin or what? 😐Thank you

[lbdroid]

Like I already said, there is no reason at all for it to be
integrated. A companion application would be like amaze network
filesystem mounter.

On 4/8/15, amtlib-dot-dll [email protected] wrote:

Could you please speak more clearly? What is a COMPANION application? Is it
a plugin or what? 😐Thank you

---

Reply to this email directly or view it on GitHub:
#43 (comment)

[amtlib-dot-dll]

Thank you for reply.

So it is necessary for the file manager to be extensible for a companion application, and it currently fetches data from the java.io.File API directly.

By the way, end users will have to install two or more apps, which is not so neat on Android platform, though it seems to be matching the Unix's rule.

[lbdroid]

No. It does not require any extension at all. A companion application is just that -- something that does the job CORRECTLY, which in this case, is by mounting a remote filesystem into the local filesystem SO THAT ALL file browsers can access it, and WITHOUT needing any extra code added to them. Once the remote filesystem is mounted, ANY file browser can use it.

And I could not disagree more with it being "not so neat" on Android. Integrating everything into a big mess is what is not neat. Why? Because you would be limiting the usefulness of one thing to the context of the other thing, when those two things are not tied together by functional requirements.

I.e., you wouldn't integrate libreoffice into amaze just because you want to use amaze to open documents. This kind of thinking causes insane degrees of needless bloat.

And it isn't just a unix rule, EVERYTHING SANE uses this approach. And because you are probably more familiar with the WINDOWS (I'm not suggesting that windows is sane by any means, but even THEY get this reasonably ok) way of doing things, let me describe under windows contexts;

On windows, you MAP A DRIVE LETTER to a remote server (mount the remote share into the local filesystem -- command "net use somedriveletter: \server\share"), you then browse through the filesystem for the files you are interested in (windows explorer) and click the file you want to use (open). It then launches the most appropriate application (libreoffice) to handle the file.

You may notice that even on windows, once you map a drive letter, it is usable by ALL file browsers, and not just windows explorer.

[mase76]

I think, these functions should be integrated into a filemanager. Calling special apps to mount
network shares is less comfortable. There are so many (open source) filemanagers. All of them
do exactly the same. the only difference is the design. Why not being able to connect to a
home fileserver or webdav share? I did not find any open source solution to do so.

[lbdroid]

Because it is INCORRECT SOLUTION + unnecessary bloat + inappropriately tied to work with just one application.

[lbdroid]

Correct solution;
http://smbnetfs.sourceforge.net/

Cross compile that, and you gain the ability to mount network smb/cifs shares via commandline.

Take it one step further, you can create desktop shortcuts using widget --> terminal emulator.

Take it TWO steps further, and you can write a simple application to wrap the functionality.

[amtlib-dot-dll]

Sorry again for late reply.

I think your idea is right, but it hasn't been integrated into the Android platform and it may work only if it has so, because the root-needing mount and the non-provided FUSE; as far as I know the FUSE on Android is only made to handle SD-cards and virtual ones and this platform lacks a fusermount command. Again, we needn't let our warranties to be voided just because we are going to access shared directories from our Android devices.

Thank you.

[lbdroid]

Huh? FUSE is part of Android. Android needs it in order to provide a pretend multi-user sdcard. You just need to compile the userspace FUSE module.

Excerpt from a Nexus 6 "mount" command:
/dev/fuse /mnt/shell/emulated fuse rw,nosuid,nodev,noexec,relatime,user_id=1023,group_id=1023,default_permissions,allow_other 0 0

[amtlib-dot-dll]

FUSE is exactly part of Android, but not provided to application developers. fusermount doesn't need an elevated privilege but is not provided; mount is there but voids your warranty. I didn't find any way to make use of that compiled module and I hope you can. Don't forget to tell us if you do so. It will be much simpler leaving root and warranties aside. Thank you.

[mase76]

Look how it is implemented in openexplorer.

https://github.com/BrandroidTools/OpenExplorer/

gpg: 383107c4
https://www.setho.org/people