Quote:
Originally posted by bigstar
hmm, I don't see how it could work like that. If it were to create the folder it would have to create the folder when attempting to change into it during navigation. To do it later when the file is transferred would be quite difficult due to the current design.
I was thinking the easiest way to impliment it would be to have a Folder Syncro Lock, when locked the other side would follow along. However since there's no defined base dir, things could get messy if you were to fall below the base dir on either side.
To do it any other way would probably have to wait until we rewrite FlashFXP.
|
It also needs "simple" symlink check (ie, you have symlink path under /copy_me/):
C> CWD path
S> 250 CWD command successful.
C> PWD
S> 257 "/dont_copy_me/" is current directory.
C> CWD <previous pwd>
S> 257 "/copy_me/"
C> CWD next_path
... and so on ...
This is how I would apply such lock:
1a. User locks remote path => store it to variable locked_remotepath
1b. User locks local path => store it to variable locked_localpath
2a. User changes directory on local => compare new directory against locked_localpath.. if comparison fails (user tries to change to invalid directory), restore path & display error
2b User changes directory on remote => compare new directory against locked_remotepath... again, if comparison fails, change back with nasty error msg
3a. User queues file from local to ftp => Get file's fullpath & remove locked_localpath from it, convert '\' to '/' and add locked_remotepath as prefix. Now you have filename on remote.
3b. User queues file from ftp to local => Get file's fullpath & remove locked_remotepath from it, convert '/' to '\' and add locked_localpath as prefix. There's local path for file.
4. User queues directory from X to Y. => Convert paths just like files + store locked_remotepath & locked_localpath in the queue. Use these stored paths when queuing directory contents.
You could/should have per site local and remote path...
Not sure, if this helps any
