Can't list more than 32 files per folder on OS X 10.9 share

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • sidb
    New User
    • Jan 2012
    • 2

    Can't list more than 32 files per folder on OS X 10.9 share

    I have an SMB share on OSX 10.9 Mavericks, and am connecting from a Windows 8.1 PC. I can fully explore the share using Windows Explorer, but Beyond Compare throws an error for any folder which contains more than 32 files:

    28/10/2013 12:34:42 Unable to load \\serverX\folderY: The specified server cannot perform the requested operation

    I've checked permissions etc - it always seems to be adding a 33rd file (even an empty one) which kills it.

    Been struggling with this for hours - any suggestions would be gratefully received.
  • Chris
    Team Scooter
    • Oct 2007
    • 5533

    #2
    OS X 10.9 Mavericks changed from SMB1 to SMB2 for file sharing. It looks like there are already issues reported with the SMB2 implementation when connecting a client Mac to a Windows Server (http://www.zdnet.com/mavericks-smb2-...es-7000022519/).

    It's possible whatever they changed in the file sharing also broke something when a Windows PC is a client and the OS X 10.9 computer is the server.

    Do files list correctly if you open the share on the Mac using Windows Explorer?
    Chris K Scooter Software

    Comment

    • sidb
      New User
      • Jan 2012
      • 2

      #3
      Yes - no problem viewing the folder contents with Windows Explorer, only with BC.
      I can put the two side by side, refresh both WE & BC, and get the full lisitng in WE and the failure in BC for any folder which contains, or has a subfolder which contains, 32 files or more.

      Comment

      • dempson
        Enthusiast
        • Apr 2008
        • 44

        #4
        As another data point: I've just tried accessing an OS X 10.9 Mavericks share from my Windows 7 PC, and I can repeat the problem, but not consistently.

        It doesn't affect the top-level folder which is shared, or one of the subfolders I tried, but another subfolder which contains 103 files reported the same error "The specified server cannot perform the requested operation". A second attempt to open that subfolder showed some of the files (47). On another subfolder with a lot more files (162 files plus 40 folders), I got the error on the first attempt to open it, and the second attempt showed it as an empty folder.

        Windows Explorer has no problem accessing any of the folders I tried including the big one.

        dir on the command line exhibits a similar problem to Beyond Compare: the folder with 103 files shows as having 47, and the one with 162 files plus 40 folders shows as being empty, with only the "." directory entry and not even a ".." entry.

        Comment

        • Chris
          Team Scooter
          • Oct 2007
          • 5533

          #5
          If dir from the command line also returns incomplete directory listings, then this is probably a bug on Apple's part that they will need to fix.
          Chris K Scooter Software

          Comment

          • fgbc
            New User
            • Nov 2013
            • 1

            #6
            Directory compare not working

            Another echo in the chorus - from win7, both explorer and shell access to mac share works as expected, with full directory listings, access to files, etc. Using BC for directory compare results consistently with "the specified server cannot perform the requested operation" and BC is borked.

            Comment

            • Chris
              Team Scooter
              • Oct 2007
              • 5533

              #7
              fgbc,

              Does it work correctly if you run the DIR from your Windows PC in a command prompt, or does it fail to show all files like dempson described earlier in this thread?
              Chris K Scooter Software

              Comment

              • Chris
                Team Scooter
                • Oct 2007
                • 5533

                #8
                This is also being discussed on Stack Overflow:
                http://stackoverflow.com/questions/1...ver-cannot-per

                It looks like Apple broke something when they changed from SMB1 to SMB2, hopefully they release a fix before too long.
                Chris K Scooter Software

                Comment

                • AshuJoshi
                  Visitor
                  • Nov 2013
                  • 4

                  #9
                  Originally posted by Chris
                  fgbc,

                  Does it work correctly if you run the DIR from your Windows PC in a command prompt, or does it fail to show all files like dempson described earlier in this thread?
                  Yes it does work correctly. I have confirmed this - it breaks only in BC. I just bought BC3 (I was using BC2) - and the problem remains. I understand Mac may be broken but there is something that BC does that makes it worse, and irrecoverable. Given that this problem is dominant in BC - I really, really hope that Scooter looks for a solution.

                  Comment

                  • AshuJoshi
                    Visitor
                    • Nov 2013
                    • 4

                    #10
                    Chris - I tried the directory command by mapping it to a Network driven and from the DOS Command in Windows 8 - it works fine and there are no error messages. In case of BC2 - I get an error code 58 - turns out this is the Windows Error Code related to domain joining. And in BC3 - the error is something like cannot find server.

                    My guess is that this is a combination of problems related to how BC accesses file shares and the changes made by Apple. I am hoping that BC can issue a patch - and is more responsive of the two companies. Not all Apple Users are BC users - so I am hoping that being a BC customer twice - I get better support from Scooter.

                    Comment

                    • AshuJoshi
                      Visitor
                      • Nov 2013
                      • 4

                      #11
                      Dempson - I don't see any problems from Command Line access - seems to be working normally for all the folders that BC is having trouble with.

                      Comment

                      • dempson
                        Enthusiast
                        • Apr 2008
                        • 44

                        #12
                        A correction to my previous comment: dir on my command line exhibits the same problem as Beyond Compare: I'm using JPSoft's TCC LE 13.03.39 as my command interpreter.

                        Testing again with the Windows 7 standard cmd.exe I don't see any problem in the same directory. Therefore the problem is affecting both TCC LE and Beyond Compare 3, but isn't affecting Windows Explorer or cmd.exe.

                        I've had a look at the network traffic with Wireshark. tcc.exe and Beyond Compare have an identical sequence, but it differs notably from the one used by cmd.exe in a few places.

                        With cmd.exe (which works) I see the following sequence:

                        1. Create Request; Find Request using SMB2_FIND_ID_BOTH_DIRECTORY_INFO with output buffer length 65536; Find Request using SMB2_FIND_ID_BOTH_DIRECTORY_INFO with output buffer length 128.

                        The Mac responds with a full directory listing spanning the two requests.

                        2. Find Request using SMB2_FIND_FULL_DIRECTORY_INFO with output buffer length 616 asking for a single entry.

                        The Mac responds with a single entry, as specified (the "." entry).

                        3. Find Request using SMB2_FIND_FULL_DIRECTORY_INFO with output buffer length 65536.

                        The Mac responds with a directory listing limited to 65536 bytes, continuing from ".." but not enough to complete the whole directory.

                        4. Find Request using SMB2_FIND_FULL_DIRECTORY_INFO with output buffer length 65536.

                        The Mac responds with a continuation of the previous directory listing, up to the last file.

                        5. Find Request using SMB2_FIND_FULL_DIRECTORY_INFO with output buffer length 65536.

                        The Mac responds with an error saying no more files.

                        6. Close Request


                        When tcc.exe or Beyond Compare does the same directory listing, the same messages are used, but some of the parameters differ. At step 3, the output buffer size is only 4096 instead of 65536, which results in a much more limited number of files being returned in the response. At step 4, the same limited length of 4096 bytes is used, and a continuation of the response isn't sufficient to complete the directory listing. Step 5 never happened - the next message is a close request, even though the Mac hasn't reported a no more files error yet.

                        Testing with a different directory had an even worse result: tcc.exe and Beyond Compare only did up to step 3 (again asking for 4096 bytes) then closed the request.

                        I can't see any obvious reason for the directory listing terminating at the point it did. I've discounted a few initial theories by trying different directories.

                        Doing a similar test with a Windows server results in a longer sequence of SMB2_FIND_FULL_DIRECTORY_INFO requests with buffer size of 4096, until it gets one which returned a no more files error, as expected.

                        Given the evidence I've seen so far, it looks more like a Windows client bug than a Mac server bug, but why is it only appearing with a Mac server?

                        Comment

                        • Zoë
                          Team Scooter
                          • Oct 2007
                          • 2663

                          #13
                          dempson,

                          Thanks for your research. The difference appears to be controlled by whether the Windows application uses the FIND_FIRST_EX_LARGE_FETCH flag with FindFirstFileEx; if you use it Mavericks works and if you don't it doesn't. We did start using that flag in 3.2, but it caused similar problems for various NAS devices, so right now BC only uses it for local drives. Short-term, you could roll back to BC 3.2.4 and it should work right. Given the issues we already had reported against it, I'm reluctant to reintroduce that flag in v3, but I am looking into making it used more often in the v4 alpha. I'll re-evaluate if Apple doesn't handle it in a timely manner, but hopefully it'll be fixed in 10.9.1.
                          Zoë P Scooter Software

                          Comment

                          • Royce
                            Visitor
                            • Feb 2005
                            • 3

                            #14
                            Good to see I'm not the only one having this problem. This is the first time I've tried using BC3 to compare windows to mac and I hit this issue immediately. I'll try rolling back to 3.2.4.

                            Edit:
                            Anywhere I can download 3.2.4? The main site doesn't list old versions.

                            And one more thing to add, in windows explorer I can see my mac listed under Network. In BC3, when browsing for folder, it does not show under Network. I have to paste the UNC file path directly into the folder compare file path and then it can access the mac share, but I hit the error during the compare.
                            Last edited by Royce; 02-Dec-2013, 09:49 PM.

                            Comment

                            • Chris
                              Team Scooter
                              • Oct 2007
                              • 5533

                              #15
                              Send an email to [email protected] and we'll provide you a link for version 3.2.4.
                              Chris K Scooter Software

                              Comment

                              Working...