Yet another feature request list

[Keith95119]

I love the product, probably use Total Command more than any other windows program. What I like about it is that is browses the directory hierarchy so quickly. This is very important to me. It shows me the files before painting the icons, and often I am drilling down before the icons are fully displayed. Please don't ever lose this.

The other feature I use a lot is synchronization: I keep all my working documents in a place, and I synchronize the entire document tree across 4 computers (from laptop to 1 at work and 2 at home) This is invaluable.

So what do I need?

1. Ability to connect to another Total Commander through an internet socket. The PORT connection to another PC works only over a serial or parallel port. The problem I have bringing the laptop in and out of various security domains, sometimes with VPN, is that often File System access is either extremely slow or I get locked out because the domain controller is not available. I can access web servers on that machine just fine, and can screen share to that machine just fine, but the file system is unavailable or very slow. I would like to be able to make a socket connection to another running instance of TC and synchronize directories through that. Seems like it would be a small change with a lot of benefit.

2. Close after sync. When synchronizing over a slow line, the initial directory search can take several minutes. Nothing can be done about that , but AFTER synchronization is jumps back into searching the directories again. Yes, I can hit ESC, but if the file system is slow it can take 10 to 15 seconds for ESC to work. I just want an option to immediately return to the normal display after synchronizing - I never want to to re-search what I know is already completely synchronized.

3. Sync in the Queue. The queue of file transfers is brilliant! I would like to be able to queue the synchronization transfers, since that can take a while, and it blocks all other TC usage while it is synchronizing. This would allow synchronization to operate in the background.

4. Avoid refresh when gaining focus. When TC is brought to the front (of other windows), it goes and re-searches the displayed directory. If I have a TC panel open on a remote file system with 1000 files in it, this can take 15 seconds (or even much longer sometimes). While it is doing this TC is completely frozen, so I can not even navigate back to a local disk ... I have to wait for it to re-search and redisplay the entire directory. This is annoying when browsing files on that directory, because everytime I launch an file the app pops in front of TC, and every time I close that app, TC goes and re-searches the directory again. There are times when I would rather it be out of date, and I would rather have a manual "refresh" button.

5. The file transfer queue window does not actually show the file that is being transferred. If you originally dragged a directory, it shows the directories, and it shows progress on the particilar file, but it does not show the file name. I recently tried to transfer a directory with 6 large files over a dial-up line so it was very slow. (I love the display of transfer rate, by the way). I was running out of time, so I wanted to know if it was close to completing the last file in the batch, or still somewhere in the middle, and I could not easily tell.

I have tried hard to collect all my current ideas to make the product better. Hope this helps.

-Keith

[Keith95119]

Oh yes, one more

6. When you drag a file across to copy, you get a pop up window. When I want to MOVE a file, I use right mouse drag, then get a pop up menu where I select MOVE, then a get the second pop up to confirm everything. Could this be combined into one? Could the normal drag bring up the normal box, but in that box I have a way to chose whether to COPY or MOVE? Seems like a simple checkbox in that pop up dialog would do it. And make it sticky so when I am moving a lot of files I just need to drag and get the same behavior by default.

-Keith

[Clo]

2Keith95119
Hello !
6.0 >> You can avoid all pop-up confirmation messages Configuration >> Options >> Miscellaneous >> Uncheck the box {Get confirmation before} "Drag&Drop…"
- To move the file(s), press <Shift> while you drag the file(s). END

 Kind regards,
Claude
Clo

[Hacker]

Keith95119,
In addition to Clo's suggestion, you can also press and hold the right mouse button before releasing the left button while dropping a file.

1. Ability to connect to another Total Commander through an internet socket.

That's overkill. FTP servers are meant for that, for instance http://www.serv-u.com/ or http://www.encrypted-ftp.com/ .

4. Avoid refresh when gaining focus.

wincmd.ini
[Configuration]
noreread=/

See also Help, section 4.b)

HTH
Roman

[sarx]

FTP-search ability.

[Hacker]

Feature request lists are very inefficient BTW. Some/many requests always get lost. It's better to post one request per thread (of course after one has searched for previous similar threads).

Roman

[krymson]

I was looking for this feature as well, to move files when I drag instead of copying, so you can imagine my confusion:

Keith95119,
In addition to Clo's suggestion, you can also press and hold the left mouse button before releasing the left button while dropping a file.

The correct method is to simply press the right mouse button while dragging, which will put a minus sign on the file icon which accompanies your mouse, informing that you are now moving and not copying.


The mouse commands for TC don't seem to be very well documented.

[Hacker]

Ooops, sorry.

The Drag&Drop possibilities are documented in Help section 3f.

Roman
P.S.: LOL, reading it again, it really must have been fun trying to figure out what I was trying to say.

[Keith95119]

Thanks for the tip on config for reread ... that is what I need.

Keith95119,

1. Ability to connect to another Total Commander through an internet socket.

That's overkill. FTP servers are meant for that, for instance http://www.serv-u.com/ or http://www.encrypted-ftp.com/ .

Roman

Yes in theory. It is a good idea not to try to duplicate functionality that could be gotten by FTP. Synchronize with an FTP site does not work exactly as I would like since date handling is not as flexible. Also, I would have to expose my entire disk to FTP server which I am uncomfortable with. Admittedly, the open a port through internet would also present security issues, but I would be happy for some draconian measure such as the 'serving' side pops up a window and does not serve anything until a local confirmation button is pressed. I don't know who else needs this functionality, but I just thought since it is there for parallel port, a small change could make it work over a socket. And I have noticed that file system access through my VPN is incredibly inefficient for synchronization.

-Keith

[ghisler(Author)]

I will not add any kind of server functionality to Total Commander. Why? This would be considered as a major security hole by many companies. It would also require that TC is running all the time. A server is better run as a service or a program in the system tray.

[Keith95119]

Seven years later am still using the product -- it is great -- and I have certainly motivated dozens of others to also get it.

BUT - I still see the need for a direct socket connection for file transfers.

1) Christian, I know you have said that you would put no "server" capabilities into the product, but that comment is inconsistent. You actually have server capabilities in the serial files transfer capability, USB and other. The is no "general principle" to stand on here. The server needed would not be anything more than what is already in the product ... it only need to allow a TCP socket connection to avoid having to string an extra wire between computers already connected by a network.

2) FTP is broken because it does not preserve timestamps on the files. Other file transfers do preserve timestamps and can be used for synchronizing a collection of files across a collection of machines. FTP protocol is unsuitable for this because the timestamp is modified at every copy. FTP is OK if you have one server and a number of clients, but among a collections of peers it is a nightmare.

3) FTP servers are difficult to install, and cumbersome to start and stop. Typically a user will leave them running all the time, when instead what is needed a capability that is available ONLY at the time of transfer. When left on all the time, they pose a security risk. What is needed is something that prompts the user on both ends of the connection to assure that a live human is sitting in front of the computers attempting to transfer between them. FTP servers do not do this.

4) Windows network, and SMB file sharing is riddled with arcane and difficult to identify rules and limitations. Machines that are "part of a domain" act different from machines that are not in that domain. Workgroups confuse the situation. Windows will sometimes prompt for user names in order to set up a SMB connection, and sometimes will not. Sometimes it is impossible to get an SMB connection even when the correct user name and password is entered.

5) SMB and file sharing is certainly a no-no outside of the firewall -- too much security risk. I would never open up my file system to the Internet. What is needed is a far more secure way to transfer files, that does not have the drawbacks of FTP.

A socket connection between two instances of Total Commander is VERY DIFFERENT from an FTP server and FTP transfer. On one computer you would "start" the server exactly as you start it for serial transfers - and this server capability would NOT be on otherwise. This is far more secure because you have to take a definite action to allow the other TC to connect.

On the other computer you "start" the client for connection. You can even have a session based password which would prevent any possibility that anyone else could hack into the port while it is momentarily available. You could use a session based port number so that can be changed every time. This is not about making TC into a file server. Instead it is simply about enabling file transfer between two peers, using TCP/IP.

This is not greater security risk than FTP, in fact it would be significantly lower security risk than running an FTP server, because the port would be open only when need it, and opening/closing operation would be a simple and clear UI gesture with positive feedback about the state of the connection. Instead of relying on difficult to configure security settings, this capability would give the user direct control of what is available, when it is available, and the assurance that when it is OFF, it is really off.

Furthermore, a binary transfer across a socket will be up to twice as fast as FTP over the same wire given the way that FTP encodes the binary date.

I hope you will reconsider. I am in the software field, so I know it is important to be very careful about adding unnecessary frills to software. It is critical that you keep the software as trim as possible, and as focused on you primary objective. So I understand that most cool features can not be followed up. You have done an excellent job so far of including very useful things. This capability would build on the peer-to-peer transfer that you already have, only by adding the ability to do it across a TCP/IP socket -- very small addition of code, but very significant benefit.

My frustration is based on having wasted two hours this evening trying to get a laptop computer to mount the drive of a desktop solely for the purpose of synchronizing a few files. Both machines have web servers on them, and each can access the other's web server. But the SMB simply will not connect and I can not figure out why. The error messages from windows are atrociously bad and probably misleading. Problems with user names, domains, workgroups, passwords, etc. But -- all I want is a socket connection to transfer a few files over. FTP will torque the timestamps. In the past 10 years I have faced this problem many times. GUESS I may have to go buy a USB cable. Seems like a waste given that there is a fine network connection working between them.

[Sob]

First, I'm not really against such thing, my position is somewhere around "I don't care". :) Just few comments:

2) FTP is broken because it does not preserve timestamps on the files.

Original FTP did not deal with timestamps much, except for showing some (often cripled) modify date in file listings and in local time zone, so you could never be sure what the exact time really is. But modern FTP can use exact timestamps, even with miliseconds and always in UTC. Seems enough for synchronization to me. You just need some recent version of FTP server (with support for commands like MLSD, MFMT, ...) and TC will detect and use them automatically.

3) FTP servers are difficult to install, and cumbersome to start and stop.

Not necessarily. It's just because they are usually intended to be always running. But I don't see any reason why no install FTP server consisting of single executable, started and ended as needed would not be possible. No config would be necessary either, it'd just auto-share all existing drives. There's only one little problem, it doesn't exist yet or I don't know about it. ;)
But I do know about opensource FTP server, even BSD licensed, that could be quite easily modified for this. The only major problem is that FTP is not firewall friendly protocol and those things are everywhere now. But similar problem would be also with any custom solution, because at least one port must pass in any case to be able to establish connection. Even FTP has some experimental extensions to work using only one port.

Furthermore, a binary transfer across a socket will be up to twice as fast as FTP over the same wire given the way that FTP encodes the binary date.

FTP binary transfers are not encoded in any way, by default it's just stream of unmodified bytes, exactly as they are read from disk. Optional ZLIB compression supported by some servers can only help.

[Keith95119]

Thanks for the reply. MDTM (modification time) is mentioned in IETF RFC 3659 from March 2007, but only as a way to read the modification time of a file. I found this note as well: "Using MDTM to modify a remote file's time stamp is not endorsed by the IETF Extensions to FTP working group or any formal RFC. However it is supported by quite a few FTP servers." This motivates two questions:

(1) Does Total Commander attempt to use MDTM to set the file timestamp?

(2) How do I find out whether a particular FTP server support this?

According to RFC 3659, the timestamp returned by MDTM must always be UTC. That would, indeed, be excellent and eliminate most of the timezone difficulties. My experience however is that FTP transfers tend to return timestamps in the timezone that the server is in. I will have to investigate this a bit more. Raises this question:

(3) Does Total Commander use MDTM to get the file modification time?

I agree there is no technical reason that an FTP server could not be created in such a way that it is started with a UI command, and runs only when a window is open, displaying the status. Similarly, when starting up you could specify the username, password, and port number that the client will use to access it.

It is just that as you acknowledged FTP servers are never constructed this way. They are designed to be servers that run continuously. They almost always hook into the OS user support, requiring that you access an actual OS user account. I also have never seen an FTP server designed for the specialized task of transferring files between peers on demand.

(4) Can anyone find any directly-invoked FTP servers that support MDTM timestamp setting, and run on windows?

I will do some research on this. Modifying an open source FTP server is one option, but my guess is that modifying Total Commander would be less work (given that the serial transfer support is already there) and far more convenient.

Thanks for the correction about file transfer speed. You are right, a proprietary transfer would not be any faster.

[Sob]

1) TC prefers the proper command for this called MFMT, but according to help file it can also use MDTM, if MFMT is not supported by server.

2) Just connect to it and look for response to FEAT command, supported extensions are listed there. Or look at manufacturer's website, they usually have some list of supported features.

3) It doesn't need to, proper timestamps are already present in directory listing, when MLSD is used.

4) FileZilla Server seems to be able to run in non-service mode. And it supports MLSD and MFMT. But you'd still have to manually set up shared paths and permissions.
I have something else pretty close to fully automatic solution, but it needs a little more work.

Modifying an open source FTP server is one option, but my guess is that modifying Total Commander would be less work (given that the serial transfer support is already there) and far more convenient.

Modifying FTP server has one major advantage. Only single person in the whole world can modify TC. But with FTP server, anyone can do it. Well, of course, not exactly anyone, you know what i mean. :)

[ghisler(Author)]

The widely used server Pure-FTPd also supports a command which Total Commander can use to send the timestamp:
SITE UTIME