item "python2.7" is in use
1. Create CIFS share and share it out
2. Start copying data to the share via CIFS
3. While data is copying, go to the main FreeNAS menu and double click "Shell"
4. Expand shell to 132x50
5. After a few seconds the transfer stops and there is an error that an item cannot be found.
6. Trying to delete the destination folder via CIFS yields this error (on a mac): "The operation can't be completed because the item "python2.7" is in use"
The only way to delete it is from the command line / shell / ssh.
#8 Updated by Jordan Hubbard over 5 years ago
I cannot reproduce the actual error (thank god) but I am seeing some variability with the transfer times. It is hard to correlate that directly with the shell being open, however, as I'm also noticing that CIFS performance in general (at least at 1GbE) tends to be bursty and somewhat difficult to measure the performance of, at least for finder copies on the Mac. I need to find some sort of windows tool that will do metered I/O to a mounted SMB share and try this again - I'm sure such tools exist.
#9 Updated by Cyber Jock over 5 years ago
I don't see a performance drop when copying.
Here when copying from my Win7 Laptop to a TrueNAS 9.3 (latest build) I get a sustained 115-119MB/sec during the transfer of a 5GB test file.
But if I change the shell size to 132x50 when a transfer is not in progress, I get a new shell of the new size within about 2 seconds. If a transfer is in progress, it takes 10 seconds or more to get the new shell unless the transfer finishes. If the transfer finishes, then I get the new shell size within about 2 seconds.
So I tend to think that something programmatically is related. But what the hell it is is totally beyond me. I blame Jordan for this one. This sounds like some kind of super-bug he'd slip in to see who in the company is a badass programmer and can catch it. That person gets a 10% payraise this year. ;)
It is really weird how the python 2.7 message comes up for the OP though. Samba doesn't have the code to tell you what is using a file remotely, only that a file is in use (by another user, obviously). At least, unless I'm mistaken about this. So I tend to think this is somehow related to a locally installed python package and a local python 2.7 install is touching things it shouldn't.
Edit: Ok, it is possible that the html code necessary to run the shell is queued up behind the Samba transfer since I'm so close to saturation speed for Gb LAN. I could try to find a way to test this I think...
#10 Updated by p s over 5 years ago
Did some further testing and there are 2 findings:
First, opening up the shell does indeed slow things down.
Second, I believe (i.e.: I'm not sure) that this problem has to do with path length. If the directory tree being copied over contains files with a deep path length, this python error occurs and there's no way to delete it from the freenas box (other than via shell).
All files are all accessible on the mac but it looks like Samba may be having issues with them. I checked some of the paths and they are indeed long, but shorter than 255 characters.