Suggestion for how to code drag without %temp

[AlexVallat]

I recently extracted a large archive through drag and drop, and noted the non-ideal process of extracting the files to temp and then copying them.

First off, yes, I have read the FAQ, I have seen the old forum posts, I am aware that if I'd done it without drag and drop it wouldn't have needed the temp files. However, I have a new suggestion that I don't think has been raised yet.

Have you considered using the CFSTR_FILEDESCRIPTOR format to perform a virtual drag and drop? This appears to be the 'official' windows way of dragging data that isn't currently a file, into a file. You can populate it with multiple file descriptors, each of which has a corresponding CFSTR_FILECONTENTS which points to an IStream that you use to write the actual decompressed file data to. For folders, the file descriptor can have the FILE_ATTRIBUTE_DIRECTORY, then for the files to go in that folder, just provide a relative path in cFileName for them.

ref: <http://msdn.microsoft.com/en-us/library/bb776902%28VS.85%29.aspx#CFSTR_FILEDESCRIPTOR>

[Igor Pavlov]

I'll check it later.

[Dodot]

When ?

[CoolOppo]

This is pretty important. The copying imposes twice the wear on SSDs, and it takes longer.

[ex g]

This also seems to be the way Explorer transfers files from FTP servers or MTP devices. When you copy such files onto clipboard, you can fetch the files' contents through CFSTR_FILECONTENTS streams, without downloading the files to local disk.

If you set the FD_PROGRESSUI flag in FILEDESCRIPTOR, Explorer will show a Windows 7 style copying dialog if the operation is taking too long. You can clear this flag and use your own dialog instead. If you want to cancel the file operation from your side, return error code HRESULT_FROM_WIN32(ERROR_CANCELLED) or 0x800704c7 when IStream::Read is called. Returning other error codes will cause Explorer to show the error message.

One downside: while CFSTR_FILEDESCRIPTOR + CFSTR_FILECONTENTS combo can be recognized by Windows Explorer, many other applications do not recognize such formats as files. They still requires the standard CF_HDROP format, so if 7-zip chooses to use CFSTR_FILEDESCRIPTOR + CFSTR_FILECONTENTS instead of CF_HDROP, users won't be able to drop files into, for example, notepad or media player.

However, the current version of 7-zip will delete the temp file immediately after the drop target completes the dragging operation, so programs like media players won't be able to open and read the dropped file again if it cannot read all the file's content into memory at once. In fact, 7-zip deletes the temp files so fast that many applications just cannot find the files from 7-zip that have just been dropped onto them.

So, at least currently, 7-zip's drag-and-drop feature is only intended for file transfers between 7-zip windows, or between 7-zip and Explorer. Not being able to drop into other applications might not be a big problem.

[Igor Pavlov]

As I remember there are some drawbacks for any alternative ways of drag and drops.
Maybe timestamps problem, alternate streams problem or something else.

[ex g]

FILEDESCRIPTOR allows you to set the virtual file's attribute flags, creation time, last write time, and last access time. Only the file name is required, other properties are optional. But if you want, you can specify the correct attributes and timestamps for the virtual files.

As for files with NTFS alternate data streams, all alternate streams should be in separate FILEDESCRIPTORs and CFSTR_FILECONTENTS streams as if they were separate files. The main file, for example "text.txt", comes first, followed by all its alternate streams, with names like "text.txt:AltStream", "text.txt:Zone.Identifier", etc. I guess this works because of the way CreateFile works.

• Alternate streams should be after the main file. If "text.txt:AltStream" comes first, an empty "text.txt" will be created, then Explorer will rename the latter "text.txt" to "text (1).txt" to avoid name collision.
• Alternate stream creation will change the timestamps of the main file. If you want to keep the correct timestamps, set the timestamps for at least the last stream of the file.
• If there is already a file with the same name, Explorer will ask whether to overwrite or not for the main file, but not for alternate streams. Alternate streams will always be created or overwritten.
• If a file with alternate streams is dragged into a drive with no alternate stream support, when copying the alternate stream, Explorer will say that the path syntax is incorrect and will stop the copying process. Files already copied will not be deleted, so you can put all alternate streams at the end of the list to get all the main files copied, though the error message could still confuse users.

There are more differences between dropping CF_HDROP and dropping CFSTR_FILECONTENTS, though.

When copying from CFSTR_FILECONTENTS, Explorer will only provide a basic dialog that shows a progress bar, an estimated remaining time, and a Cancel button, with the Windows 7 animation style and provides no more information and functionalities than the copying dialog in XP.
When copying from CF_HDROP, the Explorer dialog is much fancier, with more functionalities like showing current speed and speed graph, allowing to pause and resume copying, etc.

Of course, 7-zip can hide the Explorer dialog and show its own dialog instead, but 7-zip can't do much about the following behaviors of Explorer when copying from CFSTR_FILECONTENTS.

• Explorer stops copying immediately on the first error, and doesn't give users a chance to retry.
• When copying files to protected locations (system directories, for example), users cannot choose "Continue" to grant administrator's permission.

So maybe using CFSTR_FILECONTENTS to implement the default drag-and-drop behavior is not a good idea for some of the users.