The request is not supported (50) when moving sparse files

Sometimes when I'm moving files I get an error that reads "The request is not supported (50)". If I click on retry it works the second time, every time.

The only unusual thing about those files is that they are sparse. I'm on V12.27.

Where are you moving them from and to? The same logical disk, or another one? Local drives or network drives? If network, is it a Windows machine or a NAS at the other end(s)?

If Preferences / File Operations / Copy Attributes / Copy sparse files as sparse is on, does turning it off make a difference?

This happens with local drives, although they are also network shares for other computers to access. No other machines were accessing them at the time.

Different logical disk on a different physical drive. Source is an SSD, destination is a HDD.

Machine is running Windows 8.1. Copy sparse files is on, I will experiment with turning it off. I really need it to be on though.

Turning off copy sparse files seems to have cured it, but I need that so I turned it back on.

Does the target drive/filesystem support sparse files? Or is the error because it can't be done?

I guess we could detect the error and copy the files non-sparse in that situation, automatically and without having to turn off the option, but it may not be what you want/expect if you need the files to be sparse and don't want them to grow in physical size. The error may be telling you there's an underlying problem where the destination doesn't support sparse files at all.

Both source and destination are NTFS and support sparse files.

I usually copy a bunch of files, and 90% of them are fine but 10% get this error. Clicking retry allows them to be moved just fine, and they remain sparse. So it does work, there is just this occasional but persistent error.

I haven't been able to reproduce this so far.

Would it be possible to provide some extra information:

  • A Process Monitor log of what happens. (Let us know the name of the file that has the error, too.)

  • File size in bytes, of the file that had the error.

  • From a Command Prompt, the output of:

    fsutil sparse queryRange "C:\abc\xyz.ext"
    

    Where C:\abc\xyz.ext is the path to the source file that had the error.

  • Same again on the output file, to check if the ranges were set on retry, or if it simply skipped that stage after the failure.

I'll do it the next time I see it, thanks.

Thanks for sending the log earlier today. Some questions:

  • Is the fsutil output for the source file or the destination? We need to compare it for both files to see if the destination had any sparse sections defined or if they all failed.

  • A network share is involved, which can complicate things if something involved doesn't support setting sparse file regions. You mentioned above the source/destination were local drives but also shared for other machines. Please try the operation using the local paths, and avoiding any UNC share paths or mapped letters. Even if the network paths point to the local machine, operations involving them go through the network filesystem, firewall, etc., which brings a lot more complexity into things.

  • The Proc Mon log shows antivirus is scanning things. That could be blocking things, potentially.

  • Other than that, I can't see anything obvious from the Process Monitor log, assuming I'm looking at the correct parts of it. It looks like a few different files were copied, so I may have been looking at the wrong file(s) or time periods in the log vs where the error or retry was needed. You didn't mention which file(s) had the error.

  • The Process Monitor log would be much more useful in the recommended Native Process Monitor Format (PML), although you'd need to recreate the problem with file names that top secret for that as, unfortunately, that format cannot easily be redacted. That would allow us to see the callstack of any failing operations, as well as making filtering the data far easier.

Hi Leo.

Unfortunately I don't have the data anymore, but I can tell you that this always happens with drives that are network shares and I've never seen it happen on drives that are not shared. If it happens again with some other data I'll remove the network shares and try it again.

Fsutil output is for the source file. Opus deletes the destination file, but I guess I can run it before it gets deleted next time.

I found another one. I'll do a full check later when I'm not busy, but a quick look shows this output from fsutil:

Allocated range[1]: Offset: 0x2af000000 Length: 0x60000

It was sparse at one point but once the download completed all parts were written.

I thought everything worked but the problem was you had to click retry? That’s what the first post says.

FSUtil output for the destination before and after clicking Retry might be useful, in addition to output for the corresponding source file.

It seems to be a slightly different issue now. I am getting error 87 instead of 50, and clicking retry does not work.

fsutil on the partial destination file produced no output. I guess maybe the file is locked for writing so it silently fails.

I will send over the Process Monitor data in just a moment by PM.

New logs

The new ProcMon logs seem to be missing part of the picture, as they only show the source file being read, not the destination file being written. Could path/name filtering have been applied while the log was being made? If not, something unusual is going on which is preventing Process Monitor from seeing some operations on the target drive.

There are some events on the target drive at the very end, where it looks like the operation has already failed and the destination file is deleted, but there should be thousands of write events to the destination file which aren't there, and I don't think it's showing where the sparse information is set on the file either.

File size

The file looks like it's about 4GB in size, which could cause problems with some filesystems, but it looks like the target is NTFS so that shouldn't be an issue; just an observation, as it's interesting that it seems to be very close to that size, or at least the copy stopped around then. If it isn't that size, it might be important that the reading of the source file stopped at that point.

If the problem only affects larger files and not smaller ones, or you get different errors codes depending on the sizes, then that might also give us a direction to look in.

Tried other copy tools?

Have you tried using any other tools to copy the same sparse file to the same drive? If it fails with them as well then it may be something external to Opus causing the failure. There aren't many tools that can copy sparse files, as it's such a niche feature of Windows that almost no one uses directly, but some options are mentioned here:

And this looks like a good one to try with:

If it succeeds, check if the fsutil output for the source and destination match, showing it was able to set the sparse regions on the file.

This Reddit post also mentions that Robocopy sometimes preserves the sparse nature of files but sometimes doesn't, apparently depending on what created them. Copying sparse files seems more complex than you'd think.

1 Like