+1 to this. I hope this issue is solved soon.

Can you see if this is done on C itself to, im pretty sure this is a 7zip thing.

You're right, this also happens with 7-zip 19.00.

https://superuser.com/a/197963

Hmm I would honestly find it cleaner to put the file in memory than add it to the users clipboard and then paste it into explorer. After paste restore previous clipboard content or and clear the files from clipboard history. The currently implementation is so clunky I hope someone whos more in touch with 7zip would have the time to look over it again.

AFAIK all archiver software (7zip, WinRAR etc) do this when drag and dropping onto Windows Explorer. Read the link from @soredake above: to clarify, this is seemingly a Windows drag and drop limitation... unless maybe Windows 11 makes or will make in the future a relevant feature change.

Maybe a clean solution that everyone missed until now could be found (can software possibly read the current path from the dragged-onto Windows Explorer window?), but probably, roundabout ways to workaround this limitation in archiver software could be devised but they'd be clunky technically themselves (perhaps you could even do it using something like a AHK script), so rather than that it's better for the user to be the one to workaround this instead if they care to, by using any other method to extract than drag and drop to Windows Explorer. Or the user could try placing their Temp directory (either system's temp folder or specific folder manually chosen in 7zip's settings as 'working folder) on a RAMdisk, which would make the issue not matter much.

It's not so bad, this kind of thing is pretty much the system Temp folder's purpose... It doesn't really matter when you're not currently extracting a very large file or a huge amount of files (maybe the archiver could show an optional alert when the user tries to use Explorer drag'n'drop in these cases)... when you do, use another approach like the Extract command. You can right-click the path in an open Windows Explorer window and click "Copy address as text" to make this easier.

Yup I read it, was stated it was an issue with 7zip

That's unfortunate. I am now seeing this with other applications as well (e.g. VMWare). I suppose it's only most noticeable here because of the large amount of data extracted.

Could there be some sort of dialog box providing a warning?

I doubt it, it would be nice to have applications be more eco friendly. But here we are haha, I would recommend looking into ramdisk software if youre looking to extend the life of your SSD/nvme drives

It's possible to implement it using a copy hook handler like WinSCP (see https://github.com/dinhngtu/DragNotifier).
Some help on implementing the NanaZip side would be welcome.

@dinhngtu

Thanks. I think I will reference your implementation in recent days if I understand the implementation. I will set git commit co-author-by with your mail.

Kenji Mouri

It's possible to implement it using a copy hook handler like WinSCP (see https://github.com/dinhngtu/DragNotifier). Some help on implementing the NanaZip side would be welcome.

To clarify this skips writing to the temp directory on windows?

To clarify this skips writing to the temp directory on windows?

Yes, that's the case.

@MouriNaruto: I've made some basic tests (https://github.com/dinhngtu/NanaZip/tree/fastdrag). The extension works fine when unpacked, however, there are a couple problems with including it in NanaZip as MSIX:

• There's no MSIX support for copy handlers (no extension points, no support for out-of-process copy handlers in Explorer), so we need to register the copy handler class manually via Registry.
• However, due to conditional ACEs set on files in the MSIX, the extension DLL is not executable except to programs running as part of NanaZip proper. As a result, even if NanaZip installs the copy handler manually via Registry then Explorer will still refuse to load it.
• It looks like we can use com4:Extension but that requires Windows 11 + installing as a sparse package.

Of course, installing with MSI would sidestep all of these problems.

Should any checks be done to make sure no corruption occurs? I have network drives, and raid setup I could test 5tb+ transfers on. Is this only for dragging files out, or into archives too, or does this apply for all file ops done with nanazip?

Is this only for dragging files out, or into archives too, or does this apply for all file ops done with nanazip?

I don't think there's any issue dragging files into the archive. The problem of copying to a temp directory only happens when dragging out. I just tested this.

However, due to conditional ACEs set on files in the MSIX, the extension DLL is not executable except to programs running as part of NanaZip proper. As a result, even if NanaZip installs the copy handler manually via Registry then Explorer will still refuse to load it.

I'm not sure I understand this part. What extension dll is it referring to?

However, due to conditional ACEs set on files in the MSIX, the extension DLL is not executable except to programs running as part of NanaZip proper. As a result, even if NanaZip installs the copy handler manually via Registry then Explorer will still refuse to load it.

I'm not sure I understand this part. What extension dll is it referring to?

Copy handler class?

@dinhngtu Hey was curious how implementation in regular 7zip would look like? Packaging as MSI makes more sense considering the tool is more for "power users", and if MSI was used would that get around the support issues for Windows 10?

Ran into the same problem, when decompressing a large number of small files, you can't just drag and drop them directly, otherwise it will be too slow.

I switched to HaoZip 52pojie version, which drags and drops in accordance with the working directory settings and can be written directly to the target directory.

Wait for NanaZip to fix this problem and make it more in line with user habits than 7z