Harrison, please cc to the bug. Forwarding it below.
---------- Forwarded message --------- From: Harrison <sainokawara.sisyp...@gmail.com> Date: sam. 16 févr. 2019 à 18:32 Subject: Re: [Pkg-samba-maint] Bug#878163: samba: Samba updates from Windows 10 fail because "Size on Disk" miscalculated To: Mathieu Parent <math.par...@gmail.com> Mathieu, Upon rereading my reply to you, I noticed that I wasn't crystal clear in explaining the test results when I "selected the /mnt/non-backed folder" in the "Map network drive" function in Windows Explorer. When I tested this with "max disk size = 1000", the copy was not even attempted due to lack of space as I indicated. HOWEVER, when I tried this with "max disk size = 1000000", the copy was initiated and was successful. I hope these two results are consistent with your understand of how the code works and the "max disk space = 1000" option? It would seem that this option "overrode" the actual "free space" on the "non-backed" partition which was more than adequate to hold the data being copied? Harrison Below is the prior email I sent you: On 2/16/2019 7:44 AM, Harrison wrote: Mathieu, Interesting option, I loved the comments in MAN on it! Unfortunately, the Windows Explorer "copy function" using SMB refused to even try telling me that "Space Free: 999 MB" and "Total Size: 0.97 GB" which would be consist with "max disk size = 1000". So, I tried setting "max disk size = 1000000" and tried again. It again refused to try the "copy" telling me: "Space Free: 37.5 GB" and "Total Size: 58.4 GB". Apparently, you can only "lie" to SAMBA so much! I also tried selecting the "/mnt/non-backed" folder in the "Map network drive" but SAMBA knows that is the "root" partition even though the "non-backed" partition is mounted on it. I am comfortable with the "workaround" of "selecting a sub-folder in the actual partition where the data will be copied on the Map network drive" although this is less than ideal for general users. I have not checked any of the Debian code and haven't a clue what Windows Explorer sends to SAMBA when it is checking for adequate space before initiating a copy. But, unless this initial request identifies the actual "folder" in which the data is to be stored, there is no solution. If it does identify the "folder", SAMBA would have to "walk" the directory tree towards "root" looking for the partition in which the data would be stored and send back the correct "space information" for the partition to Windows Explorer, or whoever is making the request. I suspect there is enough information on the request and that it is doable so it all comes down to need and resources. If SAMBA is like any other software group, there are more requirements than resources to do all of the work. I did check and see that you are listed as a "maintainer" and might know. Under some circumstances, there might be additional resources to get this done if it were deemed important enough to even do. Let me know if anyone is interested in pursuing this option. Harrison On 2/15/2019 10:55 PM, Mathieu Parent wrote: Hello Harrison, Try setting in smb.conf: max disk size = 1000 Le vendredi 15 février 2019, Harrison <sainokawara.sisyp...@gmail.com> a écrit : > Louis, > > My apologies, I never received your email. My email provider is a little too > aggressive about "protecting" me from spammers. After reading your reply to > my "bug report", everything is "explained" but Debian does have some bugs, > plural. > > My Debian system consists of several partitions, the two relevant ones here > are "root" and "non-backed". My "root" partition, containing only the OS, is > only 64 GB; the "non-backed" partition is mounted on /mnt/non-backed and is 4 > TBs. > > When I "display" the attributes of "non-backed", I get slightly different, > but consistent, values depending upon whether I use "Disks" or "Nautilus" on > the Debian side or "Windows Explorer" on the Windows side. But, what really > caught my attention was the "total space" reported when an SMB "copy" failed > [wasn't attempted due to space] from the Windows side: "total space: 64 > GB"! It appears that the "Windows Explorer" copy function using SMB is > "checking" the "available space" in the "root" partition and not the > "available space" in the "non-backed" partition mounted on /mnt/non-backed > prior to doing the copy and just failing the copy! Not knowing enough about > the various components involved, I don't know which component would "own" any > bug. > > When I tried your suggestion of SMB "mounting" one of the sub-folders in the > "non-backed" partition instead of the "root" partition, EVERYTHING WORKED! I > did see a potential "cosmetic" bug in "Disks" but that would be a completely > different issue. I don't know how/where it obtains the information, but it > reported that the "non-backed" partition was mounted on /media/Music instead > of /mnt/non-backed. Actually, one of the sub-folders in "non-backed" is > mounted on /media/Music and another on /media/Videos so it may just be > displaying the "wrong" one instead of /mnt/non-backed? > > Harrison > > I hope you don't get multiple copies of this. I encountered several minor > "glitches" trying to send it to you. If you do, my apologies. > -- Mathieu -- Mathieu