darkone
12-29-2002, 03:23 PM
Most graphical ftp clients are supporting directory caching nowdays (It's a great feature, as it reduces work/traffic done by both server & client) - However due lack of one simple ftp command, caching is currently very inaccurate. :mad:
What I'm suggesting is to add 'DATE' command (similar to SIZE) to read file's/directory's timestamp via control channel. This would allow client to determinate with simple check, wheter contents of directory have changed since last cache update. :p
Client Command: DATE <filename>
Server Response: 213 <file time low-order dword> <ft high-order dword> <system time low-order dword> <st high-order dword>
Client should turn caching off, if server replies with error on the first try (same as with REST).
Here are examples how it could/should be implemented:
Client enters directory for the first time:
CLIENT => SERVER: DATE . ("." = current directory)
SERVER => CLIENT: 213 0 0 0 1
... Client requests for directory list ...
Client enters cached directory (unmodifed):
CLIENT => SERVER: DATE .
SERVER => CLIENT: 213 0 0 0 2 (Client compares cached values to with new values - and notices directory has not changed)
... Client waits for next command ...
Client enters cached directory (modified):
CLIENT => SERVER: DATE .
SERVER => CLIENT: 213 1 0 0 2
... Client requests for directory list ...
*Note* Directory should not be cached, if 'System time' in server response is equal to or less than 'File time' - as it's possible (not very likely) that contents have changed since.
Server that doesn't support 'DATE':
CLIENT => SERVER: DATE .
SERVER => CLIENT: 500 'DATE': Command not understood
... Client requests for directory list ...
Any questions/comments? :confused:
What I'm suggesting is to add 'DATE' command (similar to SIZE) to read file's/directory's timestamp via control channel. This would allow client to determinate with simple check, wheter contents of directory have changed since last cache update. :p
Client Command: DATE <filename>
Server Response: 213 <file time low-order dword> <ft high-order dword> <system time low-order dword> <st high-order dword>
Client should turn caching off, if server replies with error on the first try (same as with REST).
Here are examples how it could/should be implemented:
Client enters directory for the first time:
CLIENT => SERVER: DATE . ("." = current directory)
SERVER => CLIENT: 213 0 0 0 1
... Client requests for directory list ...
Client enters cached directory (unmodifed):
CLIENT => SERVER: DATE .
SERVER => CLIENT: 213 0 0 0 2 (Client compares cached values to with new values - and notices directory has not changed)
... Client waits for next command ...
Client enters cached directory (modified):
CLIENT => SERVER: DATE .
SERVER => CLIENT: 213 1 0 0 2
... Client requests for directory list ...
*Note* Directory should not be cached, if 'System time' in server response is equal to or less than 'File time' - as it's possible (not very likely) that contents have changed since.
Server that doesn't support 'DATE':
CLIENT => SERVER: DATE .
SERVER => CLIENT: 500 'DATE': Command not understood
... Client requests for directory list ...
Any questions/comments? :confused: