1

Problem

I need to make a dialog, in which there are two progress bars: One for total progress (if multiple files copied / moved / deleted) and one for the current file's progress.

I basically need to have some way of copying, moving and deleting files and know the progress of the corresponding process in order to update my visuals.

I already found a question about the copying problem here, but this does not really work for moving, because if you move files around on the same disk, they usually do not get copied but rather the directory of them gets changed. (Moving to other disk results in copying and deleting) Also I do not know how to achieve the deleting process.

What I have already tried

Well, given that I posted a link to a solution for the copying process, I already solved the copying part (kind of) by modifying the code so that it suits my needs.

What is asked for?

A way to know the process of copying, moving or deleting one file. If I know this, I can figure the rest of it out.

Thanks

Jason Aller
  • 3,541
  • 28
  • 38
  • 38
berndoJ
  • 72
  • 6
  • Ill give you an up-vote for a surprisingly well formatted question for a low rep user.. – TheGeneral Jul 15 '18 at 12:11
  • Moving or deleting a single file is far too fast to ever display meaningful progress. At best you'd show progress for moving/deleting a bunch of files, that is simply done by counting down the files. Copying however can be slow, google "c# copy file with progress" to find solutions. Lots and lots of hits, top ones are SO posts. – Hans Passant Jul 15 '18 at 12:16
  • @HansPassant Well, here I have to disagree. What about a 4 GB video file? That will be done in milliseconds? I think not. – berndoJ Jul 15 '18 at 12:17
  • 1
    Yes, even on a slow spindle drive that takes at most 50 milliseconds. The file size is irrelevant because moving/deleting only affects the directory entry. Try it. – Hans Passant Jul 15 '18 at 12:18
  • 1
    Windows doesn't zero out files, when you delete a file it just delete its out of the file allocation table. – TheGeneral Jul 15 '18 at 12:19
  • @TheGeneral oh ok. But I did not ask specifically for zeroing out bytes. Just how to get rid of it, delete it the windows way. – berndoJ Jul 15 '18 at 12:22
  • @HansPassant Just calculated a bit: 4GB file over USB 2.0 (480 mbit/s) - 1min 15sec - "done in milliseconds". – berndoJ Jul 15 '18 at 12:23
  • Thats probably the recycle bin copy – TheGeneral Jul 15 '18 at 12:23
  • @TheGeneral rather the recycle bin move... – berndoJ Jul 15 '18 at 12:24
  • Hold shift when deleteing, it will go faster – TheGeneral Jul 15 '18 at 12:27
  • @TheGeneral the time was about moving a file. If you move to another disk the file content has to be copied, thats what may take time. And because I want to use the same move UI for moves within same disk and between disks, I want the second individual progress bar. Deleting files with only one progressbar is something I may consider. – berndoJ Jul 15 '18 at 12:32
  • 1
    would it not be nice to stay with one progress bar, sum up the total number of bytes - not files - to move or copy (yes, even when moving physically involves only updating a file system entry), and advance that progress bar by number of bytes done, so larger files would occupy a proportionally larger distance on the progress bar? I know that's not what you asked for, therefore it is a comment, but IMO from a UX point of view, this is a superior approach and also what modern versions of Windows (try to) do. – Cee McSharpface Jul 15 '18 at 12:37
  • Well, considering your comment I could do something like this: - Copying - Just copy bytes, count them - Moving - Just copy bytes if on other disk and FS entry to delete old file; if on same disk just modify FS - Deleting - Just modify FS – berndoJ Jul 15 '18 at 12:41
  • yeah but this "other disk" condition will prove difficult to get right. given today's high level of abstraction and pace of development of new storage media, that's the job of the operating system and drivers to keep up with. I don't say that it is not possible, but it is likely not sustainable and definitely not portable. – Cee McSharpface Jul 15 '18 at 12:55
  • @dlatikay System.IO.Path.GetFullPath gets me a uiform path of the file (even if a network drive is pointing to local drive). Or System.IO.Path.GetRootPath provides me with a drive letter. Then I can compare the letters and check for same disk. – berndoJ Jul 15 '18 at 13:00
  • 1
    did you look into `CopyFileEx` and/or `MoveFileWithProgress` already? there is [documentation](https://learn.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-copyfileexa), it has a callback for a custom progress handler reporting back [progress per file in bytes transferred](https://learn.microsoft.com/de-de/windows/desktop/api/winbase/nc-winbase-lpprogress_routine), and some [sample code using this and a dialog as you describe it](https://www.codeproject.com/Articles/36647/How-to-copy-files-in-C-with-a-customizable-progres) – Cee McSharpface Jul 15 '18 at 13:17
  • @dlatikay will take a look at it tanks – berndoJ Jul 15 '18 at 13:33

1 Answers1

0

I once had the need to show a progress bar for a mix of copy, move and delete. For copying computing progress is easy. You base the computation on bytes. But what about moves and deletes?

I based progress on "synthetic bytes". The cost for a move or a delete comes mainly from the disk seeks required to address the relevant directory entries. I therefore counted them as a synthetic number of bytes that was roughly equivalent to one disk seek. For a magnetic disk a seek is ~10ms. At 100MB/sec that's a synthetic cost of 1MB. But I think multiple moves can be processed more efficiently by the OS so, if I recall correctly, I just made the cost of a move/delete 64KB.

The progress bar seemed fairly reasonable and the concept is very extensible to new operation types and new disk types (SSD).

I hope this applies to your case.

usr
  • 168,620
  • 35
  • 240
  • 369