If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
The holy grail is to run Windows commands on Android files over USB.
Do Windows experts exist who know how to make the Windows libmtp port work? (Unfortunately, if you're not a Windows expert, you won't be able to help.) This is a specific offshoot of the highly polluted thread on o Mounting Android MTP filesystems as a drive letter on Windows over USB Which solved nothing that wasn't already solved before it was asked. I'm trying to move the ball forward, to increase our combined capabilities. The holy grail is to run Windows commands on Android files over USB. I think there may be a solution in "libmtp" because that's what Linux seems to use, where Linux "just works" exactly like you want it to work. o You plug in the MTP device & run commands on it directly over USB I don't know enough about Windows to make the Windows libmtp port work. Mainly, I don't know how to use the Windows libmtp port that exists. Do you? This is the libmtp code base: https://sourceforge.net/projects/libmtp/ And this is the Windows port: https://iweb.dl.sourceforge.net/project/libmtp/libmtp-win32/0.3.5-win32-1/libmtp-0.3.5-win32-bin.zip *Do any experts exist on this ng who know how to make that port work?* -- If you're not a Windows expert, you won't be able to help. |
Ads |
#2
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtpport work?
Wolf K wrote:
On 2018-10-18 09:03, Arlen Holder wrote: The holy grail is to run Windows commands on Android files over USB. Why? If you want to work on or back up data files, just Copy them to whatever system you use for that and work on them there. Or email them to yourself. If you want to mess with the Android's system files, well, er, that's not a sensible goal IMO. Sorry I can't help. To use a command line from Windows client the path would have to be one that Windows command shell can understand. MTP will not work. What you would need for Windows is SMB. So like a remote Linux server I would say you need to have a samba server on the Android device to mount the share. There is a samba server app, I have not used it, but I would guess if it works that is what you need. -- Take care, Jonathan ------------------- LITTLE WORKS STUDIO http://www.LittleWorksStudio.com |
#3
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
On Thu, 18 Oct 2018 10:03:35 -0400, Jonathan N. Little wrote:
To use a command line from Windows client the path would have to be one that Windows command shell can understand. MTP will not work. What you would need for Windows is SMB. So like a remote Linux server I would say you need to have a samba server on the Android device to mount the share. There is a samba server app, I have not used it, but I would guess if it works that is what you need. Hi Jonathan N. Little, Thanks for your purposefully helpful advice. This response is long because it's complete. It's designed to save a lot of effort summarizing where we start. The goal is to move forward on a _general solution_ for everyone here. I'll try to summarize why MTP will work & why SMB doesn't work (yet), where, if the experts here can _solve_ either of those two problems, we will have made huge progress on a _difficult_ problem with huge benefits: o MTP freeware o SMB ports Your suggestions are normal, hence reasonable, where I believe you know far more about Windows than I do so I accept your statements as valid, with the caveat that I have far more empirical experience than most people on the two issues you brought up above. o "*MTP* will not work" (actually, MTP will work - and it does work) o "What you need is *SMB*" (actually, SMB doesn't work - sans port mapping) Bearing in mind that your suggestions are the typical suggestions, both of which I've empirically explored long ago, in order for us to make progress together, you have to (momentarily) defer to me (just) for a moment (and to Frank Slootweg & Paul who both understand this problem set even better than I do), so that I can explain to you why MTP _does_ work (with payware) & why SMB _does not_ work (yet). o *MTP works great* on Windows over USB - but only (so far) with payware o *SMB fails every time* - due to Android root needs & port-mapping issues If either MTP or SMB freeware would work, this thread wouldn't exist. *This thread is an attempt to get the Windows libMTP port to work.* This thread attempts to advance our combined tribal knowledge for all: o There are likely only a score of people reading this who understand it. o Likely only 10% of those have the Windows skills to solve the problem. I need to be clear that this is a _difficult_ issue to solve: o I do _not_ have the Windows skills needed to solve this problem. o I only understand the _empirical_ problem set (not the theoretical). The empirical constraints are that we ask for a _general_ solution: o That means it has to work on most Android devices over USB on Windows o That means the Android device is relatively new (way newer than 4.3) o That means the Android device can't be rooted (knocking out SMB) o That means it has to be freeware (knocking out MTPDrive payware) o The most likely approach is the libMTP freeware (which Linux uses) There is a _good_ reason I listed these 5 critical things above: o USB (not WiFi) o Android 4.3 (not prior to 4.3 when it actually worked great) o SMB (every general solution requires Windows port mapping) o MTPDrive (which works _great_; but it's payware so it's not general) o LibMTP (this is what Linux uses - and Linux works great!) The goal of this thread is simple (but only an expert can solve it): o A general solution to the problem set for all users on Android 4.3+ o You plug in the MTP device & run commands on it directly over USB Running commands on the files over USB is the *holy grail* on Windows: o You first "mount" the MTP device over USB as a drive letter, and then, o You can run _any_ Windows command whatsoever on that mounted file system Nobody has a solution yet that is general, for Windows. o There is a Windows MTP payware solution that works perfectly. o The SMB solution has two huge flaws (which, if solved, would work too) Bearing in mind it already works on Windows, we _know_ it "can" be done. We just have to figure out, together, with experts, how to do it. o Either with libMTP freeware over USB, or, http://www.pcbanter.net/showthread.php?s=77db9aab5f7843183b6834e40cb5e4ed& t=1106141 o Using SMB over WiFi & solving the two huge issues with SMB https://comp.mobile.android.narkive.com/TjFmHwVr/what-s-the-best-way-to-forward-smb-tcp-port-445-to-something-higher-than-1024-on-windows In summary, it's a difficult problem that has huge advantages when solved, but, I don't have the Windows knowledge to solve the problem, and yet, I have the empirical experience to know that the likely solution is one of the two possibilities moving the ball forward on this difficult problem: 1. Either we get the Windows libMTP freeware to work, or, 2. We get the SMB freeware to work (solving root & port-mapping issues). The question is: Do Windows experts exist who know how to make the Windows libMTP port work? |
#4
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtpport work?
Arlen Holder wrote:
This thread is an attempt to get the Windows libMTP port to work. There would be two component parts. 1) libMTP must be available as an IFS (installable file system). 2) The regular MTP response from a driver perspective by the OS must be stopped. Two things will not be allowed to access a connected device at the same time. A "private" payware solution which opens its own type of browser window and copies files, that's not installing an IFS and consequently is a "cheat". Whereas an IFS version would be usable by File Explorer. Does this port have documentation that at least shows the basics of the stack ? If the documentation doesn't use the right terminology, you'd drop it like a hot rock. It has to make sense, before you'd waste time on it. Paul |
#5
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
Arlen Holder wrote:
[...] We just have to figure out, together, with experts, how to do it. o Either with libMTP freeware over USB, or, http://www.pcbanter.net/showthread.php?s=77db9aab5f7843183b6834e40cb5e4ed& t=1106141 o Using SMB over WiFi & solving the two huge issues with SMB https://comp.mobile.android.narkive.com/TjFmHwVr/what-s-the-best-way-to-forward-smb-tcp-port-445-to-something-higher-than-1024-on-windows [And similar earlier and later comments.] It seems that over time, you seem to change/lax your requirements. First it had to be over USB and not over WiFi, but lately, in other threads and this thread, you also mention SMB (server on Android), hence WiFi. So apparently *now* Wifi *is* on the table. Having said/noted that, you might want to consider 'Termux': 'Termux' https://play.google.com/store/apps/details?id=com.termux "Termux combines powerful terminal emulation with an extensive Linux package collection." As stated, Termux can "* Access servers over ssh.", but Termux can also have a sshd *server*: 'Using the SSH server' https://wiki.termux.com/wiki/Remote_Access#Using_the_SSH_server So by using a ssh client on Windows, you could run Linux commands on your Android device to do anything you like. AFAICT, that would more or less satisfy your requirements as stated in your OP: "The holy grail is to run Windows commands on Android files over USB." I.e. 'over USB' is now 'over USB or Wifi', because you allow SMB=WiFi as a solution. "Windows commands" is still open to interpretation, but I think you mean that you want to give the commands *on*/*from* your Windows system, not that they must be native 'Windows' commands (like 'dir'), but Linux commands (like 'ls') are also fine, as long as those commands are *given* *on*/*from* your Windows system. I.e. specifically: On Windows, ssh to your Android system and do a 'ls' to list files on the Android system. Let me/us know what you think of this alternative approach. |
#6
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
On 18 Oct 2018 20:29:15 GMT, Frank Slootweg wrote:
It seems that over time, you seem to change/lax your requirements. Hi Frank Slootweg, I understand the confusion. I apologize for teh complexity. We're trying to break new ground ... where complexities abound. Anyone responding merely to "keywords" won't be able to keep up with us. When you are breaking new ground, not every trail works out. So you have to try a few different trails, each separately. It's the nature of solving problems that have not been solved before. Each trail presents completely different problem sets. Hence, what you see are _different_ threads each with its own focus. Most people, as you are well aware Frank, don't even _comprehend_ the problem set like you and Paul and I do, so I try desperately to keep each trail focused on one problem definition. Even then, some people don't comprehend the problem set (as you are aware). First it had to be over USB and not over WiFi, but lately, in other threads and this thread, you also mention SMB (server on Android), hence WiFi. Let's look at this logically, where you and Paul can handle the detail. 1. We want USB. Why? Because it's fast. 2. If we can't get USB, we will take WiFi. Why? Because we can't get USB to work. 3. If we had both, which would we choose? USB. Why? Because it's fast. So apparently *now* Wifi *is* on the table. See above. We want USB. Why? It's fast. What if we can't get USB? Then we'll take WiFi. Why? Because we want a solution. Having said/noted that, you might want to consider 'Termux': 'Termux' https://play.google.com/store/apps/details?id=com.termux I've had Termux on Android for years. Once we decide that USB isn't going to work, then _any_ server gets on the table, whether that server is: a. WebDav (which works great, by the way, but not as a drive letter) b. FTP (which works for the most part, but not recently as a drive letter) c. SSH (which I haven't bothered to try because the above two work) d. HTTP (same reason since WebDav is better anyway) e. SMB (which has an advantage that it can be mounted as a drive letter) f. Adb (if rooted) etc. Notice that if we want a "server over wifi", then WebDav or FTP work except that they don't work as a removable drive letter (which is the key point since you want to be able to run any Windows command on the files). So by using a ssh client on Windows, you could run Linux commands on your Android device to do anything you like. Yes. But that's not the goal. The goal is to run _any_ Windows command. To do that, we need to mount the Android file system as a removable drive. The question is really, in general terms: How do we run a Windows command on an Android file system? https://groups.google.com/forum/#!topic/microsoft.public.windowsxp.general/6UdMAFVkv3s But you know full well how _that_ thread worked out (the trolls ruined it). The problem is that the trolls see a keyword (any keyword, it doesn't matter what the keyword is), and then they have a field day pasting their pre-prepared responses to _those_ keywords (which they've used for centuries). As you're well aware, the trolls don't bother comprehending the topic. They simply respond the same to those keywords as they have for decades. Another way of writing that same thread topic could have been: How do we MOUNT as a removable drive the Android filesystem? The goal is to universally run _any_ Windows command, as fast as possible: a. That means USB is best (not WiFi) b. That means a mount point (not a "network location") c. It would be best to require zero software on Android (i.e., no servers) AFAICT, that would more or less satisfy your requirements as stated in your OP: "The holy grail is to run Windows commands on Android files over USB." I.e. 'over USB' is now 'over USB or Wifi', because you allow SMB=WiFi as a solution. "Windows commands" is still open to interpretation, but I think you mean that you want to give the commands *on*/*from* your Windows system, not that they must be native 'Windows' commands (like 'dir'), but Linux commands (like 'ls') are also fine, as long as those commands are *given* *on*/*from* your Windows system. I.e. specifically: On Windows, ssh to your Android system and do a 'ls' to list files on the Android system. Let me/us know what you think of this alternative approach. I think USB is the way to go, since: a. We know it works on Linux (with libMTP) b. We know it works on Windows (with MTPDrive) o All we need is to get the libMTP port to work on Windows. o Or, to get a freeware alternative to LibMTP. I realize this post has some complexities involved, where anyone just reading keywords would be thoroughly confused. So far, only you and Paul seem to comprehend the complexities, so I appreciate the "server" suggestion. If I were to give up on USB over libMTP, then I'd just use USB over MTPDrive, since it works for me. It's not a _general_ solution - but it works just fine. Also, I can easily boot to Ubuntu 18.04, which also works. More to the point, I _already_ have WebDav and FTP servers working over WiFi. The only advantage of the SMB server would be that I presume SMB is more easily "mounted" as a drive letter. Again, I apologize for the complexities in my response. Breaking new ground isn't going to be done with keyword responses. In summary, I think the _best_ approach, is to get libMTP to work. To that end, there is this thread on the a.c.f newsgroup: Does freeware exist on Windows that will mount (as a drive letter) Android connected via USB as MTP? https://groups.google.com/forum/#!topic/alt.comp.freeware/TaIlIMK2Nuw |
#7
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
Arlen Holder wrote:
[...] Just some comments/additions (but sadly no solution): Once we decide that USB isn't going to work, then _any_ server gets on the table, whether that server is: a. WebDav (which works great, by the way, but not as a drive letter) There was a free solution for this, NetDrive, which was free for 1 Network Drive. But apparently they brought out a new version (3) and changed their policy. Now it is (7-day) trialware. :-( http://www.netdrive.net/ At the time, I tried it and it worked, but I abandoned it, because it had no advantage over FTPUSE. N.B. I used 'WebDAV Server' with it. https://play.google.com/store/apps/details?id=com.theolivetree.webdavserver N.B.2. I still have the working install package, NetDrive2_Setup_2_6_14_945.exe, but as you want a solution for all users, that's is of little/no help. b. FTP (which works for the most part, but not recently as a drive letter) IIRC, you had (have?) problems with FTPUSE on Windows 10. Do you have an older Windows version to check whether the problem is in FTPUSE or in Windows 10? FTPUSE worked fine on my Windows 8.1 system. My FtpUseInst.exe install package says it's version 2.2/2.2.0.0. BTW, I just saw that you can set 'Compatibility mode' on the FtpUseInst.exe. I assume that you can also set it on the resulting ftpuse.exe file. If so, it might be worth your while to experiment with that. Moral: It seems from these threads that Windows 10 users get each and every problem they deserve! :-) I.e. everything works fine on older Windows versions or/and with older versions of the tools, but not with the latest-and-(not-)greatest! :-) [...] |
#8
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
On 19 Oct 2018 13:46:48 GMT, Frank Slootweg wrote:
Just some comments/additions (but sadly no solution): Hi Frank Slootweg, Since this response to your wonderful netdrive suggestion is already detailed, I'll respond to your FTP suggestions in a separate post. Thank you for that suggestion of "netdrive" which I hadn't heard of befo http://netdrive.net/download (trialware, so it's not a general solution) Just in case the old freeware existed, I downloaded the following versions: o NetDrive 3.6.571 http://netdrive.net/ o NetDrive 3.5.434 https://en.freedownloadmanager.org/Windows-PC/NetDrive.html o NetDrive 2.6.2 https://filehippo.com/download_netdrive/64426/ o NetDrive 2.6.16 build 962 https://www.filehorse.com/download-netdrive/30799/download/ o NetDrive 2.5.7 https://netdrive.en.lo4d.com/ o NetDrive 1.3.4 https://filehippo.com/download_netdrive/15075/ etc. I have one key question for you (or anyone who knows Windows well), which is whether my "assumption" is accurate that we need to "mount" the filesystem as a "removable drive" (i.e., as a "drive letter") in order to be able to run any Windows command on that Android filesystem? I seem to be able to run DOS commands on both these types of connections: o USB + "removable drive" (to get a drive letter) http://www.bild.me/bild.php?file=1853998dir02.jpg o WiFi + "network location" + "removable drive" (to get a drive letter) http://www.bild.me/bild.php?file=6340420dir012.jpg o WiFi + "network location" + "net use" (to get a drive letter) http://www.bild.me/bild.php?file=8605173dir05.jpg Is that assumption of the intermediate "need" for a drive letter correct? If so, here's a summary of where we stand based on that assumption... (If not, please correct where I err.) The "problem" is that when you connect over USB an Android 4.3+ device (mine is a $130 64GB LG Stylo 3 Plus, running Nougat, Android 7.0) as MTP, you can't run any Windows command on the Android file system, as evidenced by this "dir" of APKs that had to be done after copying to Windows: http://www.bild.me/bild.php?file=9648761dir.jpg The best solution is to "mount" the Android filesystm as a "removable drive" (i.e., it gets a drive letter) over USB, which I can easily do with payware/crippleware, but which I'm trying to make into a general solution that _everyone_ can do. http://www.bild.me/bild.php?file=8315262dir03.jpg *For a general solution, we need bona-fide non-crippled Windows freeware.* o The goal is a _universal_ solution (which necessitates _freeware_); o which enables _any Windows command_ to run on the Android filesys; o which means (I think) it has to be "mounted" as a _removable drive_; o (or, in other words, it has to have a "drive letter" when on USB); o (although a Windows "network location" can also work when on WiFi); o which both MTPDrive (over USB) & NetDrive (over WiFi) payware seem to do Given: o USB solutions are faster & generally simpler (no Android software) MTPDrive: http://www.bild.me/bild.php?file=1853998dir02.jpg Linux: http://www.bild.me/bild.php?file=6181360dir01.jpg o WiFi solutions (which generally require a "server" running on Android). WebDav: http://www.bild.me/bild.php?file=8605173dir05.jpg FTP: http://www.bild.me/bild.php?file=7687244dir06.jpg For USB: The best solution is a freeware equivalent to the MTPDrive functionality o LibMTP freeware may work if we can figure out how to make it work, while https://sourceforge.net/projects/libmtp/files/libmtp-win32/ o MTPDrive crippleware works (crippled to 30 files per session), and, http://www.mtpdrive.com/download.html o Dual booting to Linux works (which natively uses, apparently, LibMTP). http://www.bild.me/bild.php?file=6181360dir01.jpg For WiFi: If a server must be run on Android, Windows probably handles SMB best, but: o SMB server (on Android) solutions are problematic for two reasons: (a) No known Play/F-Droid SMB server works on TCP port 445 unrooted (b) Port forwarding on Windows is required if a nonroot server is found. https://play.google.com/store/apps/details?id=com.icecoldapps.sambaserver Where these general-use servers don't require rooting or port forwarding, & where Windows "network location" & "removable drive" features are used: o WebDav https://play.google.com/store/apps/details?id=com.theolivetree.webdavserver network location: http://www.bild.me/bild.php?file=8605173dir05.jpg o FTP https://play.google.com/store/apps/details?id=com.theolivetree.ftpserver http://www.bild.me/bild.php?file=7075400dir07.jpg http://www.bild.me/bild.php?file=4731516dir011.jpg For WiFi FTP, these are possible universal free drive-mapping solutions: o FTPuse (freeware which I was not successful with in my recent tests) https://www.ferrobackup.com/map-ftp-as-disk.html FTP Server (free): http://www.bild.me/bild.php?file=3316456dir08.jpg The Olive Tree: http://www.bild.me/bild.php?file=7355568dir09.jpg Anonymous: http://www.bild.me/bild.php?file=4223201dir010.jpg o DirectNet (freeware which I was successful with in my tests today) http://www.directnet-drive.net/ http://www.bild.me/bild.php?file=4731516dir011.jpg http://www.bild.me/bild.php?file=6340420dir012.jpg o SFTP Net Drive (free for personal use but I was not successful today) https://www.nsoftware.com/sftp/netdrive/ (it took a bogus name & email) o NetDrive (trialware, untested because it's not a general solution) http://netdrive.net/ o Web Drive (trialware, untested because it's not a general solution) https://webdrive.com/download/ And where Linux solutions may work under some circumstances: o Dual-boot to Linux works perfectly (which uses LibMTP natively) https://groups.google.com/d/msg/alt.os.linux/oOfdMLmJ-oQ/jh_1DwTOBgAJ o Termux (contains a mini Linux command environment) https://play.google.com/store/apps/details?id=com.termux As always, this effort is for everyone - so please improve where you can! |
#9
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
On 19 Oct 2018 13:46:48 GMT, Frank Slootweg wrote:
Moral: It seems from these threads that Windows 10 users get each and every problem they deserve! :-) I.e. everything works fine on older Windows versions or/and with older versions of the tools, but not with the latest-and-(not-)greatest! :-) Hi Frank, Here is my detailed response to your purposefully helpful FTP suggestions. Thanks for the FTPUse suggestions, where, as I recall, it used to work for me but no longer does - but - I'm not too worried for two reasons: a. I found a method that did work for me with FTP over Wi-Fi, and, b. Even if I hadn't found that method that worked, USB is the main goal. For this post, we aren't discussing USB. For this post, we're only discussing WiFi. And, for this post, we're not discussing any other server other than FTP. (For example, we're not discussing WebDAV, which always worked just fine.) What we want, for this post, is a *drive letter*. We never had problems with a "network location". What else, we want for this post, is a *universal solution*. That means anyone can do it (not just you and me, Frank). In general, that means freeware. I think we have that solution below using DND freeware. o DirectNet-Drive created a drive letter of a WiFi FTP network location But I acknowledge that _other_ freeware should have worked for me. o FTPUse should have worked (and I think it did work, in the past, for me) https://www.ferrobackup.com/download/FtpUseInst.exe o SFTP Net Drive should have worked (but it also failed for me) https://www.nsoftware.com/sftp/netdrive/ (it took a bogus name & email) What worked for me the very first time, was this combination: 1. Android freeware FTP Server: https://play.google.com/store/apps/details?id=com.theolivetree.ftpserver 2. Windows freeware map of "network location" to a "removable drive": http://www.directnet-drive.net/ Here is a screenshot of the FTP WiFi connection as a drive letter (R http://www.bild.me/bild.php?file=4731516dir011.jpg And here is a screenshot showing that I can run DOS commands on Android: http://www.bild.me/bild.php?file=6340420dir012.jpg Where both those connections are made using the Olive Tree FTP server on my Windows 10 desktop connected to Android 7.0 Nougat. For whatever reasons, on my Windows 10 system, FTPUse failed under exactly the same circumstances (both as a password user & as anonymous): FTPUse failing with the "Olive Tree" FTP server as user "francis": http://www.bild.me/bild.php?file=7355568dir09.jpg FTPUse failing under the same FTP server as user "anonymous": http://www.bild.me/bild.php?file=4223201dir010.jpg As you know, FTPUse also failed when I used F-Droid "FTP Server (Free)": https://f-droid.org/en/packages/be.ppareit.swiftp_free/ Where these screenshots are from a few days ago when I ran those tests: http://www.bild.me/bild.php?file=7687244dir06.jpg http://www.bild.me/bild.php?file=7075400dir07.jpg http://www.bild.me/bild.php?file=3316456dir08.jpg SFTPNetDrive freeware also failed today with the "Olive Tree" server where SFTP NetDrive simply failed to connect whether using user "francis" or "anonymous". In summary, I was never worried about FTPUse not working on Windows 10 for me since I prefer USB and since I found (by trial and error) an WiFi FTP solution that works as a general freeware solution for everyone, which is "DirectNet-Drive". If we still wish to move the ball forward, we should ask another Windows 10 user to see if FTPUse or SFTP NetDrive works for _them_. All I can tell people here is that my empirical results are the following: o Using multiple FTP servers on non-root Android 7.0 Nougat... o DirectNetDrive Windows 10 network-location-to-drive-letter worked! o But both FTPUse & SFTP NetDrive failed (under the same conditions). Why? I don't know why. If another Windows 10 user can test either of those two failed solutions, we will get a better idea if it's Windows 10, or if it's just me. -- As always, the Usenet goal is for all to help everyone with their efforts. |
#10
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
*Do any experts exist on this ng who know how to make that port work?*
If another Windows 10 user can test either of those two failed solutions, we will get a better idea if it's Windows 10, or if it's just me. WiFi: Here is the detailed thread showing how to use WiFi FTP to map network locations to named removable drives on Windows if the users don't already know how from using Linux. https://groups.google.com/forum/#!topic/comp.mobile.android/IswZ5yEcpYA Note that there's a minor typo in one command which won't faze most users: ftp open 192.168.1.6 2221 (your IP address & port may well differ) USB: To answer Paul's question about USB libMTP documentation, there's a readme: C:\software\network\mtp\libmtp\README.windows.txt Which says, summarized: LibMTP depends on LibUSB and libiconv. o LibUSB Win32 - http://libusb-win32.sourceforge.net/ o LibIconv - http://gnuwin32.sourceforge.net/packages/libiconv.htm LibMTP takes advantage of the LibUSB-Win32 Device Driver package. Hence the steps to use freeware to get Android 4.3+ to connect to Windows as a drive letter so that any Windows command can run directly on the Android filesystem appears to be as summarized below. 1. Download the latest device driver binary package (libusb-win32-device-bin-x.x.x.x.tar.gz) from http://sourceforge.net/project/showf...group_id=78138 2. Upon extraction, plug in your Android device and run bin/inf-wizard.exe. Select your device and save the resulting inf file in the project root directory. 3. Copy the files "bin/libusb0.dll" and "libusb0.sys" for 32-bit operating systems. Copy the files "libusb0_x64.dll" and "libusb0_x64.sys" for 64-bit operating systems. 4. Goto Start - Run, type "devmgmt.msc" and press "ok". 5. Select your Android device from the list and click Action - Update Driver, Choose "No, not this time" if prompted to connect to microsoft. 6. Choose "Install from a list or specific location". 7. Choose "Don't search, I will choose the driver to install 8. Click the "Have Disk..." button in the bottom right corner of the prompt 9. Browse to your .inf file and select it. Press Ok 10. The name of your Android device should appear in the prompt, click it and click "Next" (Ignore any prompts about Driver Signing, continuing installation of the selected driver). 11. Click finish to end the driver install process. If needed, to roll back to the original Android USB driver: 1. Goto Start - Run, type "devmgmt.msc" and press "ok". 2. Select your Android device, right click on it and click "Properties" 3. Go to the "Driver" pane and select "Roll Back Driver". I'll run as many of those steps as I can, but I'm not a coder. I'm an empirical tester. I run things until they work. If I'm successful, this will be a first (to my knowledge) where almost nobody knows how to do this, AFAIK, and where the power is immense in that we can connect Android as a drive letter over USB using only Windows freeware so that _all_ Windows commands run on the Android filesystem. |
#11
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
On Sat, 20 Oct 2018 03:15:43 -0000 (UTC), Arlen Holder wrote:
If I'm successful, this will be a first (to my knowledge) where almost nobody knows how to do this, AFAIK, and where the power is immense in that we can connect Android as a drive letter over USB using only Windows freeware so that _all_ Windows commands run on the Android filesystem. The problem I'm running into is that the INF file that libusb created is apparently "unsigned", where I've never dealt with this problem before. http://www.bild.me/bild.php?file=1834269libusb_error.jpg Here's what happened when I tried to set up LibMTP on Windows 10 just now. 1. I already had the latest libusb device driver binary package installed: http://sourceforge.net/project/showf...group_id=78138 C:\app\network\libusb\ 2. I plugged in my Android device (LG Stylo 3 Plus) and ran C:\app\network\libusb\bin\inf-wizard.exe. That asked me to select my device to save the resulting inf file. NOTE: I hit "install now" but that just gave me the error of: "System policy has been modified to reject unsigned drivers". This created a 144-line detailed LG-TP450.INF file. C:\app\network\libusb\LG-TP450.INF 3. Since I'm 64-bit, I copied these two files FROM: C:\app\network\libusb\amd64\libusb0.dll TO: C:\app\network\libusb\libusb0.dll and FROM: C:\app\network\libusb\amd64\libusb0.sys TO: C:\app\network\libusb\libusb0.sys 4. I started the Windows Device Manager (Start Run devmgmt.msc OK) And I noticed that I had the following entry for my phone. Portable Devices LG Stylo 3 Plus 5. I selected the Android device from the list and clicked Action - Update Driver, I chose "No, not this time" if prompted to connect to Microsoft. 6. I chose "Install from a list or specific location". 7. I chose "Don't search, I will choose the driver to install 8. I clicked the "Have Disk..." button in the bottom right corner 9. I browsed to the .inf file and selected it & pressed OK C:\app\network\libusb\LG-TP450.INF 10. The name of your Android device appeared in the prompt, I clicked it and clicked "Next" (I can't ignore the prompts about Driver Signing, to continue installation of the selected driver). It says "Update Drivers - LG Stylo 3 Plus" "Windows encountered a problem installing the drivers for your device" "Windows found drivers for your device but encountered an error while attempting to install them." "LG-TP450" "The third-party INF does not contain digital signature information" 11. There is no "Finish" buttne; just a "Close" button. It seems digital signing is preventing C:\app\network\libusb\LG-TP450.INF from installing properly (which I've never had to overcome before). http://www.bild.me/bild.php?file=1834269libusb_error.jpg |
#12
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
On Sat, 20 Oct 2018 04:37:10 -0000 (UTC), Arlen Holder wrote:
It seems digital signing is preventing C:\app\network\libusb\LG-TP450.INF from installing properly (which I've never had to overcome before). http://www.bild.me/bild.php?file=1834269libusb_error.jpg I solved the problem of digital signing preventing C:\app\network\libusb\LG-TP450.INF from installing properly (which I've never had to overcome before). http://www.bild.me/bild.php?file=1834269libusb_error.jpg Searching for the solution to the error: "The third-party inf does not contain digital signature information" I find plenty of hits, most of which say to disable signature checking: bcdedit /set loadoptions DDISABLE_INTEGRITY_CHECKS bcdedit /set testsigning on Some of the hits for Windows 10 say to run: Start Settings Recovery Advanced Startup Restart now Then, when the machine boots, they say to hit: Advanced Options Startup Settings (7) Disable Driver Signature Enforcement Then the machine booted and I was able to rightclick on the INF to install. http://www.bild.me/bild.php?file=7081529libusb13.jpg I'm not sure what to do next, but I opened up the Device Manager: Start Run devmgmt.msc I went to "Portable Devices" and looked at the "Properties" for LG Stylo 3 Plu Which showed it still had the Microsoft drivers (as far as I could tell). In the "LG Stylo 3 Plus Properties" form, I went to the "Driver" tab. In that "Driver" tab, I clicked the "Update Driver" button. Here it gets tricky because the sequence is critical! (If you don't follow exactly, you don't get the same thing twice!) First, you click "Browse my computer for driver software". which defaults to C:\app\network\libusb Do NOT hit the "Browse" button! Hit instead, "Let me pick from a list of available drivers on my computer" This popped up with the following three choices: (icon) MTP USB Device (icon) MTP USB Device LG-TP450 I selected the "LG-TP450" which said "This driver is not digitally signed!" http://www.bild.me/bild.php?file=3395172libusb14.jpg Then I hit the "Have Disk" button and then the "Browse" button. From there I selected C:\app\network\libusb\LT-TP450.inf & hit "OK". http://www.bild.me/bild.php?file=7027918libusb15.jpg Then I hit the "Next" button. Windows said "Installing drivers" and then the phone beeped & buzzed. Windows said "Update Drivers - LG-TP450" "Windows has successfully updated your drivers" "Windows has finished installing the drivers for this device: LG-TP450" http://www.bild.me/bild.php?file=2309179libusb16.jpg I hit the "Close" button. This changed things in the "Device Manager". o There was no longer the "LG Stylo 3 Plus" in "Portable Devices" o Under a new "libusb-win32 devices" section was now "LG-TP450" o The LG-TP450 Properties "Driver" tab now showed Driver Provider libusb-win32 Driver Date 1/17/2012 Driver Version 1.2.6.0 Digital Signer Not digitally signed http://www.bild.me/bild.php?file=6013051libusb17.jpg The bad news is that the phone no longer shows up in the Windows File Explorer when connected via USB. I'm not sure what to do next, so I might not report back anything until I figure out whether changing the drivers from MTP to LG-TP450 gained anything with respect to the goal of devising a universal method for users to mount their entire Android device over USB as a driver letter. |
#13
|
|||
|
|||
Do Windows experts exist who know how to make the Windows libmtp port work?
On Sat, 20 Oct 2018 05:30:12 -0000 (UTC), Arlen Holder wrote:
I'm not sure what to do next, so I might not report back anything until I figure out whether changing the drivers from MTP to LG-TP450 gained anything with respect to the goal of devising a universal method for users to mount their entire Android device over USB as a driver letter. The goal is for _everyone_ to be able to run any Windows command on Android over USB, which necessitates a working freeware solution (where we already have payware solutions that work just fine). To that end, we broke new ground by getting libMTP to work ... but ... See below: I think LibMTP may have been a red herring all along. Yesterday I installed Zadig & libusbK after installing LG-TP450.INF: o Zadig http://zadig.akeo.ie/ https://github.com/pbatard/libwdi/wiki/Zadig o libusbK https://sourceforge.net/projects/libusbk/ Unfortunately, I don't know which made LibMTP finally work: o Replacing "LG Stylo 3 Plus" MTP with the libusb-generated "LG-TP450.inf" o Then adding Zadig o Then adding libusbK After I did those three things & tested LibMTP commands, they all worked. I don't know which of those three in sequence made LibMTP finally work on Windows 10, where it's important to figure that out so that others can follow in our footsteps - but where I have to move forward nonetheless. Since my credibility is important, I prove what I say, where here are screenshots proving the set of libmtp bin commands are finally working on Windows 10 - providing a glimpse of the entire Android filesystem over USB: o connect.exe http://www.bild.me/bild.php?file=4656598libtmp01.jpg o files.exe http://www.bild.me/bild.php?file=4184084libtmp02.jpg o folders.exe http://www.bild.me/bild.php?file=8059960libtmp03.jpg o emptyfolders.exe http://www.bild.me/bild.php?file=2119219libtmp04.jpg o detect.exe http://www.bild.me/bild.php?file=4408040libtmp05.jpg o connect.exe http://www.bild.me/bild.php?file=8349591libtmp06.jpg o tracks.exe http://www.bild.me/bild.php?file=2378716libtmp07.jpg o (other commands) http://www.bild.me/bild.php?file=8494912libtmp08.jpg (I wonder what "format.exe" does... This empirical result leaves me with this critical question: Q: What "can" we do with libMTP toward our goal of a general solution (hence freeware) for mounting the Android MTP filesystem as a drive letter on Windows over USB (so that all Windows commands work on it)? |
Thread Tools | |
Display Modes | |
|
|