ZTree.com  | ZEN  | About...  

 Index   Back

/API - looks like it may be a Windows issue   [Zeta]

By: John Leslie       
Date: Apr 12,2019 at 04:28
In Response to: /API - looks like it may be a Windows issue (Kim Henkel)

> > C:\ZTW\ZTW64.EXE /XT /L1 /XP /ROWS:50 /COLS:96 /APIT
> /ZV"C:\ZTW\FILELIST.ZLOG"
>
> Unfortunately. when you use /API (or /APIT), Windows is completely
> responsible for all copy and move operations - ZTree itself is not
> deleting the source or target of a move, when whether the operation is
> cancelled or not.

Presumably it has to pass on the cancel request to Windows in some way, could there be something unusual going on there? Could the T in APIT be an issue in some way? It is curious if that's a long-standing Windows bug or SMB interaction error, you'd have thought with a squillion users people would be complaining. Is there anything specific in the type of abort used on the move that might be a factor?

Anyway, avoiding a lengthy investigation of the problem and going with an easy way to avoid the issue might be simpler and more practical. Perhaps to be safe ZTree could use Windows Copy for API moves and do a Windows Delete on the source after it has checked the move worked, so if interrupted the source will always still be there and it's just a question of whether there's a destination file too?

So something like:

(1) Move not interrupted:

* Copy source to destination (after overwrite checks, etc.).
* Check no errors returned and destination is there.
* Delete source.
(If user hits abort after this point it has no effect.)
/APIT speedup will still come from Windows copy.

(2) Move interrupted:

* Copy source to destination (after overwrite checks, etc.).
* (Receive user abort)
* Send abort to Windows API
* If there's an option to flush any pending file actions do that and wait for it to finish
* Refresh directories
* Is file at both locations? If so delete destination. (As we know source is a good copy and user wanted to abort, avoids issue of destination being correct size but without all content.)
* If file is just at source then nothing to do.

Obviously I'm not an expert in which parts of the Windows API you're using or how you're using them, this is just a general suggestion as it's very annoying when a new file disappears before it's been backed up, e.g. on a move away from a download directory, or worse from a camera ingest directory (especially for long videos).

I'd be extremely happy with any improvements that could be made, as it catches me from time-to-time and I've had a number of instances now, a small number but, as you can imagine, very annoying. Presumably even harder to spot if aborting a move of many tagged files, so may be several I've not noticed.

106 views      
Thread locked
 

Messages in this Thread

 
94,591 Postings in 11,933 Threads, 348 registered users, 11 users online (0 registered, 11 guests)
Index | Admin contact |   Forum Time: Nov 20, 2019 - 7:04 pm EST  |  Hits:29,206,161  (19,402 Today )
RSS Feed