smb shared files not appearing in DIR listing

Question

Level 1

0 points

smb shared files not appearing in DIR listing

I've recently switched to Mountain Lion Server and moved over a large number of windows files. After a few problems with permissions, sorted by the ACL fix, I have anothe strange problem. One of our apps performs a DIR listing for file*.* and for some reason the SMB server reports file not found, even though if the whole file is typed in the DIR search it appears.

I need the file to show up on a directory listing with wildcards because the application calls for this. I've proved it isn't the filename of the command because having copied the directory to the local C: drive, the command returns the correct result.

Does anyone know if there is a way of fixing this?

Here is the output of the windows DIR command against identical files, one on the local drive, and one over the SMB share.

C:\Audio1>dir MYR00002*.*

Volume in drive C has no label.

Volume Serial Number is 18DB-DE36

Directory of C:\Audio1

19/11/2012 20:22 658,248 MYR00002.wav

1 File(s) 658,248 bytes

0 Dir(s) 82,869,899,264 bytes free

Q:\AudioTest>dir MYR00002*.*

Volume in drive Q is AHR-RAID

Directory of Q:\AudioTest

File Not Found

Mac mini, OS X Server, SMB Sharing

Posted on Nov 19, 2012 1:50 PM

Reply

Answer 1

etresoft

Level 8

46,312 points

Nov 19, 2012 2:01 PM in response to AHR2426

What do you get if you do "dir *.*"?

Reply

Answer 2

AHR2426 Author

Level 1

0 points

Nov 19, 2012 2:04 PM in response to etresoft

I get a full directory listing, correctly identifying the files, folders and free disk space.

Reply

Answer 3

etresoft

Level 8

46,312 points

Nov 19, 2012 2:10 PM in response to AHR2426

And that looks like what? You were so generous with actual output before...

Reply

Answer 4

AHR2426 Author

Level 1

0 points

Nov 19, 2012 2:25 PM in response to etresoft

There you go.

Q:\AudioTest>dir *.*

Volume in drive Q is AHR-RAID

Volume Serial Number is 0000-0000

Directory of Q:\AudioTest

19/11/2012 20:31 <DIR> .

19/11/2012 19:29 <DIR> ..

19/11/2012 19:33 614 Audwall.ini

19/11/2012 19:37 300,000 Carts1.lst

19/11/2012 19:33 300,000 Carts10.lst

19/11/2012 19:34 26,999,700 Carts11.lst

19/11/2012 19:32 300,000 Carts2.lst

19/11/2012 19:32 300,000 Carts3.lst

19/11/2012 19:32 300,000 Carts4.lst

19/11/2012 19:32 300,000 Carts5.lst

19/11/2012 19:32 300,000 Carts6.lst

19/11/2012 19:32 300,000 Carts7.lst

19/11/2012 19:32 300,000 Carts8.lst

19/11/2012 19:32 300,000 Carts9.lst

19/11/2012 19:37 112 MYR00001.INF

19/11/2012 19:37 12,507,814 MYR00001.wav

19/11/2012 19:37 68 MYR00002.INF

19/11/2012 19:37 658,248 MYR00002.wav

19/11/2012 19:37 <DIR> PeakFiles

19/11/2012 19:32 5,376 SharedICs.ic3

19/11/2012 19:32 <DIR> Thumbs

17 File(s) 43,171,932 bytes

4 Dir(s) 1,539,696,631,808 bytes free

Reply

Answer 5

AHR2426 Author

Level 1

0 points

Nov 19, 2012 3:37 PM in response to AHR2426

Strangely, this search does return a result :

Q:\AudioTest>dir myr00002*

Volume in drive Q is AHR-RAID

Volume Serial Number is 0000-0000

Directory of Q:\AudioTest

19/11/2012 19:37 68 MYR00002.INF

19/11/2012 19:37 658,248 MYR00002.wav

2 File(s) 658,316 bytes

0 Dir(s) 1,539,696,623,616 bytes free

Reply

Answer 6

etresoft

Level 8

46,312 points

Nov 19, 2012 4:34 PM in response to AHR2426

For some reason, I was assuming that you were upgrading to Mountain Lion. Did you actually switch from some other system?

DOS does not expand wildcards like other shells. It doesn't expand them at all. It is up to the individual programs to do the expansion. Apparently DOS just passed the wildcard on to the file system, which is going to follow UNIX rules for wildcard expansion. So, get rid of the ".*".

Reply

Answer 7

AHR2426 Author

Level 1

0 points

Nov 19, 2012 11:49 PM in response to etresoft

We actually switched from Windows server 2003 which was running on a really old box with physical disks in a raid array to the Mac Mini with Pegasus Raid. Most of our requirements have been met and the file sharing is working fine, but this one thing is causing a very minor problem.

We use a propritary application and after being able to replicate the crash when moving or copying these files within the program, I looked at procmon in windows and saw that the application itself was performing a lookup on MYR00002*.* which lead me to replicate that behaviour at the command line.

So, unless I can get SMB to respond to *.* queries I may need to report this to the application developers, although I'm not sure they'd support it because they recommend windows through and through.

This function is rarely used in the application so it isn't a show stopper, but would complete our migration away from windows servers.

Reply

Answer 8

etresoft

Level 8

46,312 points

Nov 20, 2012 5:24 AM in response to AHR2426

It would also be a good idea to repost your question (linking to this one) in both the OS X Server and Windows Compatibility forums. There may be people with better ideas who don't frequent this, more general forum.

Reply