home bbs files messages ]

Forums before death by AOL, social media and spammers... "We can't have nice things"

   comp.mobile.android      Discussion about Android-based devices      236,147 messages   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]

   Message 235,692 of 236,147   
   Maria Sophia to Arno Welzel   
   Re: Discussion of FTP vs WebDav for Andr   
   29 Jan 26 11:34:09   
   
   XPost: alt.comp.os.windows-11, alt.comp.os.windows-10   
   From: mariasophia@comprehension.com   
      
   Arno Welzel wrote:   
   >> You can't mount the Android filesystem as a Windows drive letter with FTP   
   >> (unless you add third-party software). But WebDAV needs no software.   
   >   
   > The issue with WebDAV in Windows is, that it does not work realiable.   
   >   
   >> Having the Android phone as a Windows drive has huge advantages, e.g., the   
   >> Windows file explorer can save DIRECTLY from Windows to Android in 1 step.   
   >   
   > Using the Windows file explorer you don't need a drive letter at all.   
   > That's the reason, why namespaces exist in the explorer - to be able to   
   > access locations even when they don't have a drive letter.   
   >   
   > A drive letter is only useful if you want to access the data in *other*   
   > applications besides the Windows file explorer which *require* a drive   
   > letter.   
      
   Hi Arno,   
      
   It is good that you are pointing out the differences between WebDAV and   
   FTP for connecting Windows to mobile devices. Those distinctions are real.   
      
   Regarding your comment that WebDAV in Windows is not reliable, I do not   
   doubt that it can fail. I am only saying that in my specific use model it   
   has been reliable enough to be useful. If you have concrete failure cases   
   it would help to list them, since the discussion here is about FTP vs   
   WebDAV. Without examples it is hard to understand what you mean by   
   unreliable in this context.   
      
   My setup is simple. I run a free WebDAV server on Android or iOS, then use   
   the built in Windows WebDAV client:   
      
   C:\> net use Z: \\192.168.1.2@8000\DavWWWRoot /USER:joe * /PERSISTENT:YES   
      
   No third party software on Windows, no shell extensions, no drivers.   
   Windows maps it as a normal filesystem. For my purposes this has been   
   stable, and the fact that it uses only built in components is a major   
   advantage. Scripts that expect a persistent drive letter work fine with   
   this mapping.   
      
   The biggest practical benefit for me is that I can save APK files directly   
   from a Windows browser session to the mobile device. APKs are useless on   
   Windows, so saving them straight to the phone is the natural workflow.   
   This is something FTP cannot do on Windows without third party redirectors,   
   because Windows has no FTP filesystem provider.   
      
   Only protocols with filesystem redirectors can be mapped as drives:   
   1. SMB has one.   
   2. WebDAV has one.   
   3. FTP does not.   
      
   That is a critical difference when the goal is full read write access to   
   the visible mobile filesystem through normal Windows applications.   
      
   You are correct that a drive letter is not required for basic file copying.   
   Explorer namespaces work fine for that, and adb does not need a drive   
   letter either. So yes, we can live without mapping the device.   
      
   But the question remains. How do you directly save an APK obtained during a   
   Windows web browsing session to the mobile device? That is the specific   
   workflow where a mapped drive letter matters, and where WebDAV provides   
   something that FTP cannot provide on Windows without extra software.   
      
   If we arbitrarily toss SMB into the mix, this is my assessment:   
    a. Can a web browser save an APK directly to Android with SMB?   
    b. Can a web browser save an APK directly to Android with WebDav?   
    c. Can a web browser save an APK directly to Android with FTP?   
      
   The answer, when we tackle iOS & SMB, is surprisingly unintuitive!   
      
   1. SMB   
   A Windows browser can save directly to an SMB share, but only if the   
   non-rooted/non-jailbroken mobile device is running an SMB server.   
      
   A. Android   
   Non-rooted Android cannot bind to privileged ports, which includes the   
   standard SMB ports. Because of that, Android SMB servers must run on   
   high ports. So SMB can work, but it is not useful on Android IMHO.   
      
   B. iOS   
   Shockingly, iOS is the only common consumer operating system that allows   
   apps to bind to privileged ports, so an SMB server on iOS can run on the   
   standard SMB ports and behave more like a normal SMB server.   
      
   In practice this makes SMB on iOS more useful than on Android.   
      
   In both cases, if the SMB server is reachable and writable, a Windows   
   browser can save directly to it because SMB is a real filesystem   
   provider in Windows.   
      
   2. WebDAV   
   A Windows browser can save directly to a mapped WebDAV drive letter.   
   WebDAV has a filesystem redirector in Windows, so the mobile device appears   
   as a normal drive. We can save an APK directly to Android during a Windows   
   web browsing session (without needing to save it and then copy it over).   
      
   3. FTP   
   Unfortunately a Windows browser cannot save directly to an FTP location.   
   Windows has no FTP filesystem provider, so FTP cannot be mapped, cannot be   
   assigned a drive letter, and cannot appear in Save dialogs. Explorer can   
   browse FTP, but only inside Explorer itself.   
      
   Having said those distinctions between SMB/WebDAV/FTP I certainly agree   
   with you that FTP/WebDAV are no longer being worked on my Microsoft.   
   --   
   Usenet is where people with vast knowledge converge to discuss ideas.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   

[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]


(c) 1994,  bbs@darkrealms.ca