views:

59

answers:

3

I had a piece of code which uses windows SHFileOperation function with FO_MOVE operation. Additional flags specified were FOF_NOCONFIRMATION | FOF_NOERRORUI | FOF_SILENT.

A particular weird behavior was observed when the destination drive was full. In this case, MOVE could not place the file in destination folder but the source file was also lost. This was highly unexpected and this caused a loss of data.

Is this the standard behavior of SHFileOperation? Can we have something like MOVE if the destination drive has space otherwise leave the file at the original place?

A: 

I've not heard of this - sounds like a BUG.

May be best to choose the more pragmatic approach, by splitting the move operation into FO_COPY, followed by FO_DELETE (assuming the FO_COPY operation succeeded).

Additionally, you might gain some efficiency if your implementation could detect when the source and destination volumes are the same. In this case, you should be able to revert to FO_MOVE. A move operation on the same volume generally distills down to a rename + metadata move.

Bukes
A: 

I've not heard of this - sounds like a BUG.

May be best to choose the more pragmatic approach, by splitting the move operation into FO_COPY, followed by FO_DELETE (assuming the FO_COPY operation succeeded).

Additionally, you might gain some efficiency if your implementation could detect when the source and destination volumes are the same. In this case, you should be able to revert to FO_MOVE. A move operation on the same volume generally distills down to a rename + metadata move.

Bukes
A: 

The SHFileOperation should return DE_FILE_TOO_LARGE (0x85) in case the destination file is too large for the destination media or file system.

HJ