XFS file system and OS X compatability issue

Hi Aaron,
This is essentially a discussion about the command line. It helps us greatly to see commands and their output copied into the post. For instance, when there's one of these extra directories around, it would help to see a long listing from the command

ls -AFlh /Volumes

It would also help to see their contents, listed with the following command:

ls -AFlh /Volumes/*

If there's really a lot, I don't think we have to see much of it but it would probably help to see at least a few lines of each.

I've had a similar problem with disks. In my case, the directory whose name ends end with -1, or heaven forbid another number, was created by the Finder when asked to mount a volume when a directory by that name already existed in /Volumes. The case of automounting a network share is probably different as the shares are mounted in /private/Network/Servers and symlinks are created to them. Unfortunately how you mounted the share is something else you've left out so we can only guess at what might have happened.

I would guess that one of two things happened. One possibility is that you've had a dirty shutdown and the automounter didn't get the opportunity to remove a directory or symlink it created in presenting the share. The other is that you have mounted the share twice. The fact that you can see content in both suggests that this is the case but there isn't sufficient information to know why this might have occurred or even if it has. You might try running the following command as you're accessing a share:

sudo lsof -i

That command lists network connections but I think those are closed after the information has been transmitted so timing would be critical. If this were NFS I would suggest running showmount but I don't know if there's a comparable command for AFP. It is possible to determine this from the logs of the server version of OS X but I assume that the "Buffalo TaraStation NAS" isn't running OS X. Does that server at least have logs?
--
Gary
~~~~
Say it with flowers,
Or say it with mink,
But whatever you do,
Don't say it with ink!
-- Jimmie Durante

I really doubt this is an XFS problem. I'm more inclined to believe the problem is a poor implementation of Appletalk.

Have you tried a mount using CIFS? If not, try mounting it using smb://<address> and see what happens. It'll be a lot slower than using AFS, but I bet the problem goes away.

Hi Aaron,
I asked for a (long) listing with the -l (lower case "el") option, not the -I (upper case "eye") option. All you had to do was copy-and-paste. However, I don't know if it would have helped. We may be able to tell you something about the client that will help you figure out what the server is doing but we can't tell you about the server because it's not an Apple implementation of an AFP server.

I gather that you told iTunes that to open a music library on an AFP share. It's nice that iTunes is robust enough to mount the share but it appears to not know when the share is already mounted. One possible reason is the difference is case. HFS+ is case-insensitive but is case-preserving so if a process inquires as to what is mounted in /Volumes, the name of this share is given as "media." If iTunes is looking for "MEDIA" and compares in a case-sensitive fashion, it will think it's not there. Thus, if you could get the cases to match, maybe iTunes wouldn't mount the share again.

In mounting AFP shares, the Finder is case-sensitive. If I specify the share in the URL and spell it with the wrong case, the Finder reports that it cannot find the share. If I select it from the menu, it's already spelled with the correct case so I don't see how it's possible to get the case wrong with the Finder. Of course I'm mounting the share of an OS X server and your evidence suggests that the "Buffalo TaraStation NAS" behaves differently.

I don't know how iTunes deals with libraries that are on a remote share but I hold out hope that you can convince it that the share name is media. I think there's a chance that it will use the already mounted share if the names match in case.

On the other hand, it doesn't seem to be an error to mount an AFP share twice and the Finder's method of adding "-1" to the name should work to make UNIX paths unique. I cannot explain the discrepancy in the two listings though. There is another mistake in the /Volumes/media listing; the "iTunes Music Backup" directory is listed twice and the inodes match. Thus there clearly an error; it would be interesting to sniff packets and see if the error occurs on the server or the client but I'm betting on the server.

According to the one long listing we have, both shares were mounted with the authority of the user aaron. However, the groups are different and that really surprises me. This may take an AFP expert to resolve but it was my impression that the group owner of a share was determined by the server. That suggests that these are actually two different shares. Does this server share a directory that contains the "media" share? Can you think of any way that these could be two different AFP shares with the same share name?

I also want to second Jeff's — Oh, you just posted that you like Jeff's solution. That's just as well. Tiger puts resource forks in files on such filesystems and the Finder presents them as it would an Appledouble file. Also, it supports Windoze permissions, which are quite elaborate. Finally, to answer your last question, it shouldn't be possible to have a problem with samba shares on Leopard if they really stood behind their claims and froze the kernel API in Tiger.
--
Gary
~~~~
"Out of register space (ugh)"
-- vi

XFS and EXT2/3 have pretty much the same file naming restrictions. XFS is what you want to use for storing media because the file size limitation is on the order of millions of terabytes. But as I mentioned in my previous post, it's not the file system that is at fault because you're talking to it through a layer of software through the network, and that's where the problem lies.

My take on this is that Linux implementation of AFS that Buffalo uses to control the RAID isn't completely up to what OS X expects of it. Therefore, your OS X computer does the best it can with it.

I'm betting that if you used something like Automount Maker and set the name to MEDIA, it would behave as you want under AFS. The link is http://jm.marino.free.fr/index.php?switch=main_