/g option (%) on MOVE cmd appears broken TCC 14.03.57 x64

[wingo395]

Re-verified in TCC 14.03.57 x64 on Win7 6.1.7601.

My alias "move=*move /g" no longer shows percentage moved. This behavior has been in the past couple of builds, have no idea of knowing which ones.

*copy /g works, however.

 

[leeuw013]

this behaviour started some builds earlier somethimes the /g works en sometimes not

 

[rconn]

WAD (and this hasn't changed in v14).

MOVE first tries to rename the file; if that doesn't work then it copies it and deletes the original. On older versions of Windows you couldn't rename across volumes, but with the newer versions you can. The /G option isn't invoked on a rename, only on a file copy, so for MOVE's on your local drives you're never going to invoke the Windows CopyFile API; hence no /G results.

 

[vefatica]

WAD (and this hasn't changed in v14).

MOVE first tries to rename the file; if that doesn't work then it copies it and deletes the original. On older versions of Windows you couldn't rename across volumes, but with the newer versions you can. The /G option isn't invoked on a rename, only on a file copy, so for MOVE's on your local drives you're never going to invoke the Windows CopyFile API; hence no /G results.

Should I see the progress indicator when I do something like this?

v:\> move /g 10mb \\lucky\e$\Workplace\
V:\10mb -> \\lucky\e$\Workplace\10mb

     1 file moved         10,485,760 bytes freed

That took about half a minute. I saw no indication of progress.

 

[rconn]

Should I see the progress indicator when I do something like this?

That's up to Windows and your redirector. As I said, if the rename works, the copy (and progress) is never done.

 

[rconn]

If you have doubts about what Windows is doing, try:

ren 10mb \\lucky\e$\Workplace\

 

[vefatica]

That's up to Windows and your redirector. As I said, if the rename works, the copy (and progress) is never done.

Well there's nothing I can do to get MOVE /G to show me the progress indicator. Here's a filename that has never been used before containing just-now geneated random data. The file must have been copied because now it exists in the destination. But I saw no progress indicator.

v:\> rndmfile unique_name %@eval[10 * (1 shl 20)]
 
v:\> timer move /g unique_name \\lucky\e$\Workplace\
Timer 1 on: 12:39:05
V:\unique_name -> \\lucky\e$\Workplace\unique_name
 
    1 file moved        10,485,760 bytes freed
Timer 1 off: 12:39:50  Elapsed: 0:00:45.01
 
v:\> dir \\lucky\e$\Workplace\u*
 
Directory of  \\lucky\e$\Workplace\u*
 
2013-01-13  12:37      10,485,760  unique_name
        10,485,760 bytes in 1 file and 0 dirs
    22,829,895,680 bytes free

 

[wingo395]

WAD (and this hasn't changed in v14).

MOVE first tries to rename the file; if that doesn't work then it copies it and deletes the original. On older versions of Windows you couldn't rename across volumes, but with the newer versions you can. The /G option isn't invoked on a rename, only on a file copy, so for MOVE's on your local drives you're never going to invoke the Windows CopyFile API; hence no /G results.

Is it possible to add a /g option to the rename command, or is that yet another API issue?

 

[rconn]

Is it possible to add a /g option to the rename command, or is that yet another API issue?

It's possible using a different API; it's on the list for v15.