How to? TCC and ftp:// commands

[mikea]

TCC 15.01.52 x64 Windows 7 [Version 6.1.7601]

I have a wifi connection between a PC running Windows 7 and an Android tablet, via a wifi-file-transfer app running on the tablet. For file browsing, you type an ftp:// address into a browser window (or Explorer window) on the PC. The address is provided by the wifi transfer app itself.

Knowing that FTP operations can be performed at the TCC command line, I tried a few. The address and port shown below are bogus -- used just for example purposes. The actual address and port DO work in the real-world situation.

There are two oddities I ran across -- with DIR commands and with reports of file dates.

Dir commands

Two "dir" commands I tried worked. The third didn't, though it seems as if it should. (Lines below might appear to be wrapped incorrectly. In the actual commands, they aren't.)

(1) WORKS -- wildcard '*' used:

c:\> dir "ftp://123.456.78.901:0000\Download\Phone_call_from_Neurosurgeon_32bps.mp*"
Directory of ftp://123.456.78.901:0000\Download\Phone_call_from_Neurosurgeon_32bps.mp*

9/09/2013 1:27 1,153,298 Phone_call_from_Neurosurgeon_32bps.mp3
1,153,298 bytes in 1 file and 0 dirs​

(2) WORKS -- wildcard '?' used:

c:\> dir "ftp://123.456.78.901:0000\Download\Phone_call_from_Neurosurgeon_32bps.mp?"
Directory of ftp://123.456.78.901:0000\Download\Phone_call_from_Neurosurgeon_32bps.mp?

9/09/2013 1:27 1,153,298 Phone_call_from_Neurosurgeon_32bps.mp3
1,153,298 bytes in 1 file and 0 dirs​

(3) FAILS when the complete filename is specified. This is the filename that is revealed by the above two commands that use wildcards.

c:\> dir "ftp://123.456.78.901:0000\Download\Phone_call_from_Neurosurgeon_32bps.mp3"
TCC: (Sys) The system cannot find the file specified.
"ftp://123.456.78.901:0000\Download\Phone_call_from_Neurosurgeon_32bps.mp3"
0 bytes in 0 files and 0 dirs​

File dates

In that "Download" folder on the Android tablet, nearly all of the files whose modification date is some time in 2012 are shown correctly as being modified in 2012 -- IF I view them via browser or via Explorer window.

But if I use "dir ftp://" (etc.etc.) at the TCC prompt, nearly all of the files that were modified in 2012 show as having been modified in 2013.


What am I doing wrong here?

 

[Steve Fabian]

Mixing slashes and backslashes may contribute to the situation. Try connecting using the /v (verbose) option of the IFTP command, which will reveal the actual protocol messages between the systems, and the underlying issue with it. TCC supports special protocols for devices that deviate from the standard file transfer protocol, which may be the case here. BTW, what happens with file dates when you actually transfer a file?

 

[mikea]

The file dates on the 'receiving' system are always changed to the date and time when the copy occurred. I haven't checked yet to see if the "/k" command would preserve the date, but since it's intended to retain attributes (+/- 'a' and 'r', etc.) I would doubt it.

Further experiments...for convenience, I stored the FTP address (including port number) in variable "%tablet" (including "ftp://" at the start of the variable's value).

"Filename.txt" already exists in the Download folder on the tablet (specifically "/mnt/sdcard/Download"). Then:

copy filename.txt %tablet\Download​

Result: I'm asked if I want to overwrite the existing file.

Change the command slightly -- note the forward slash.

copy filename.txt %tablet/Download​

Result: copies the file without query.

Is that expected?

Change slightly again:

copy filename.txt %tablet/Download/​

Result: copies the file; if it exists in the destination, again overwrites without query.

copy filename.txt %tablet/Download\

or​

copy filename.txt %tablet\Download\​

In both those cases the result is The system cannot find the path specified.

Also expected?

I am long in the habit of using a trailing slash in a copy command, if I want to copy to a new directory -- to force TCC (and 4NT before it) to recognize the destination as a directory and never as a filename. I'd hope to keep doing that if I'm to use these "ftp-wise" commands at the command line.

Further:

copy filename.txt %tablet\Download\xxx.xxx​

I expected this to do a copy and RENAME the file to "xxx.xxx" in the destination. The actual result:

A file named Download\xxx.xxx was created one directory-level above "Download." In other words, the string "Download\" became part of the name.

This did work:

copy filename.txt %tablet\Download/xxx.xxx​

If the file existed in the destination, I got the overwrite query. Or:

copy filename.txt %tablet/Download/xxx.xxx​

If the file existed in the destination, there was NO overwrite query.

It appears that the positions of these slash-marks make a big difference. One mistyped slash-mark might bring a person to grief. Makes me wonder if this isn't one of the few situations in which, no matter how much I prefer the command line, I'd be better off using Win Explorer.

 

[vefatica]

Browsers are probably among the most robust FTP clients these days. If you want to perform your task interactively the browser could be the best choice. If you want to script/automate the task you can forget the browser.

Just out of curiosity, did you try any of this with FTP.EXE?

 

[Steve Fabian]

What type of file system and OS is in the tablet - Posix? It it their horrible habit to do the equivalent of changing your hiring date when they move you to a different office, i.e., change the modification date when a new copy is made, but this is only the default, appropriate options are (usually) available to consider the modification date as important as the access permissions and retain them in the copy.

Using 4NT's or TCC's FTP feature between websites using POSIX file systems and my Windows computers never changed the date. The modification date and time of file content for me is the file's most important metadatum, and often the only way to know which of several versions is oldest and which the most recent. And I do have problem on occasion with files older than a year on POSIX file systems - the native POSIX utlities report only the date, not the time, for files older than a year, even though it is stored in the file control block, because 40 years ago the extra characters did not always fit in the same line. Consequently if multiple versions were made on the same date, one must look for the content to possibly provide the chronology.

 

[mikea]

Android 4.0.4, and I don't know what its file system is. I'll have to try /k to see if it makes any difference. Tried Android-to-Windows file transfers via Bluetooth for the first time today. That was nice when it worked. Namely, once. Then it stopped working. Well, life's too short to waste time troubleshooting that kind of thing. Now trying an Android app that enables wi-fi transfers...and ran across the "interesting" things with slashes and "copy" and ftp. Well, there's always the old-fashioned USB cable. The tablet connects as a "music device" and not a drive -- so (apparently) no running file copies from the command line.

As for ftp.exe -- don't know much about it, aside from having looked at its near-incomprehensible command line. : )

 

[mikea]

Nah, not so incomprehensible after all -- but for whatever reason, ftp.exe doesn't like the IP address used by the Android app -- and it can't connect. Well, I could use Win explorer or even generic TCC 'copy' commands if I can just get clear on precisely when to use or not-use which kinds of slashes in the commands.

But I sure do need to find out why the modification dates/times of files (seen via 'dir' at the TCC command line) are so hugely different from the modification dates as seen 1) in Win explorer and 2) on the Android device itself. That, and why specifying a remote file by its fully qualified name (no wildcards) makes TCC think it can't find the file at all.

 

[mikea]

Ran across another solution that isn't as convenient as command-line copying. But in the absence of more information about what's going on with the slashes and the file dates ("dir ftp://whatever..."), then I'll use this. It's a free Android app, available on Google Play. Name: AirDroid. Install it on the mobile device, start its service, and then get access to the "server" (via IP address) in a browser on the PC. The user interface is pretty elegant, for an Android app. Uploads and downloads require a GUI approach, but they seem less problematic than the "ftp" solutions described above. I'd much prefer using the command-line tools -- scriptable, after all -- but the glitches are getting in the way. AirDroid does not have its SSL act together and IMO would not be the right tool to leave up and running for hours at a time. (The non-"light" connection is via their web site, but that isn't an HTTPS address, either, grumble). Anyway, for minor file-transfer jobs, this will be fine,