See the above post which gave an alternate suggestion if rc4 didn't fix.

 

I'll most likely just leave it, because I do like how it won't write everything to the array/parity until it starts working on that particular file, less wear and tear. It's only really an issue when I get low on space and start thinking I have more than I do. I just wanted to make sure it was still marked as a bug and not closed

See the above post which gave an alternate suggestion if rc4 didn't fix.

 

I'll most likely just leave it, because I do like how it won't write everything to the array/parity until it starts working on that particular file, less wear and tear. It's only really an issue when I get low on space and start thinking I have more than I do. I just wanted to make sure it was still marked as a bug and not closed

 

Let's make sure the situation is summarized correctly:

 

• You have a program on a secondary system that downloads files.
  
• This program is configured to save the file as it's downloaded to a temporary location on an unRAID user share (over the network).
  
• When the file completes downloading, the program then moves it to another share on unRAID as its final resting place.
  

 

The expected result is that when a file begins to download, you want unRAID to see that file based on the total disk space it will consume by the time it finishes.  Instead, unRAID sees it only as data is written, and therefore if the physical disk fills up from other operations prior to the download completing, the download will fail mid-stream.

 

Does that summarize the issue properly?

Does that summarize the issue properly?

 

Not at all 

 

There's no temporary location or moving files between shares when the download is done. The program saves the file in one location, and keeps working on it the same location until it's done, it just does so by using sparse files

 

I would imagine the same would be for any sparse file type of program, another good one would be VirtualBox. Expanding VM images would probably have the same issue

 

The expected result is that when a file begins to download, you want unRAID to see that file based on the total disk space it will consume by the time it finishes.  Instead, unRAID sees it only as data is written, and therefore if the physical disk fills up from other operations prior to the download completing, the download will fail mid-stream.

 

Correct. I guess a way to display the storage usage in a way similar to Windows would be ideal, like the screenshots from the first page. Eg in Windows, I right click a drive, look at the properties, and see how much space is allocated AND how much space is actually used. In the unRAID Web GUI, I can only see how much space is currently used in a drive, allocated space doesn't show. To get the allocated space total, I would have to calculate it myself by locating every sparse file on the server, and check its properties in Windows, and add that to unRAID's total

Does that summarize the issue properly?

 

Not at all 

 

Good thing I asked ;-)

 

There's no temporary location or moving files between shares when the download is done. The program saves the file in one location, and keeps working on it the same location until it's done, it just does so by using sparse files

 

What about this?

 

 

You can specify where to put new downloads vs completed downloads.

 

I would imagine the same would be for any sparse file type of program, another good one would be VirtualBox. Expanding VM images would probably have the same issue.

 

Well, I can confirm that unRAID sees virtual disk files of RAW format as their full size correctly.  However, QCOW files do not work that way because QCOW works on the idea of thin provisioning (allocating more space to the vdisk than is actually available on the host system).  This is by design and if we were to represent them on the filesystem as fully allocated, it would defeat part of the purpose of QCOW.  So I don't think that example would really constitute the same issue you're having with downloads-in-progress.

The expected result is that when a file begins to download, you want unRAID to see that file based on the total disk space it will consume by the time it finishes.  Instead, unRAID sees it only as data is written, and therefore if the physical disk fills up from other operations prior to the download completing, the download will fail mid-stream.

 

Correct. I guess a way to display the storage usage in a way similar to Windows would be ideal, like the screenshots from the first page. Eg in Windows, I right click a drive, look at the properties, and see how much space is allocated AND how much space is actually used. In the unRAID Web GUI, I can only see how much space is currently used in a drive, allocated space doesn't show. To get the allocated space total, I would have to calculate it myself by locating every sparse file on the server, and check its properties in Windows, and add that to unRAID's total

 

The challenge here is that not all systems do things this way, but I can definitely bring this up to Tom and get some further insight from him.