Want to highlight a helpful answer? Upvote!

Did someone help you, or did an answer or User Tip resolve your issue? Upvote by selecting the upvote arrow. Your feedback helps others! Learn more about when to upvote >

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

StealthRocket Author

Level 2

200 points

._ files are locking up the real files.

Has anyone having trouble with ._ files and Windows servers? The issue is pretty confusing so I'll try and make this as clear as possible.

The problem is I can't move or edit files stored on a W2k server because the ._ files are shown as in use by another user. If I try and move a file on the server into another folder I get the following message: "The operation cannot be completed because a required item is in use." With my sys admins help using the computer management console (on Windows) we've tracked it down to the ._ files associated with the "real" files. It shows all of the ._ files being in use even if the user who's supposedly using it is logged off the server.

I get a similar message saving files to the server. Lets say I have .tif file and open it in Photoshop, make edits and hit command-S. The following message comes up: "Could not save "file name" because the file is already in use or was left open." Now this is where it gets dangerous. If I hit OK the file on the server is deleted so if I were to close the file at this point it would be lost. I have to hit command-S again and a Save As window comes up that pointes to the correct folder on the server and then I can save. The kicker is I STILL can't move the file because the ._ file has the same name so its linked back up to the file and since the ._ file is "in use" the problem persists. If I change the file name when doing the save as I can move it on the server because it has a new ._ file.

Now let's talk about deleting files from the server using Finder. If I try and delete a file on the server that has a ._ file 'in use" the message that says this file will be deleted immediately are you sure you want to continue comes up and I click OK. Then the following message comes up: "The operation cannot be completed because a required item is in use." If I click OK the file deletes anyway BUT the ._ file doesn't get deleted so if I move the file back to the server, the problem persists.
The other problem with deleting is if I try and delete an entire folder with ._ files 'in use" I get the messages I just mentioned and the last file in the folder is deleted. now imagine having to delete a folder full of 250 items one at a time. Even if you deleted all 250 items individually you still can't delete the folder because the ._ files are still there and still 'in use".

I don't normally work directly off the server but this makes file management impossible.

Is anyone else having this problem?

Posted on Jun 7, 2004 3:00 PM

83 replies

Oct 3, 2004 11:27 AM in response to Community User

from your message I conclude that we'll be stuck with this problem for a long time. that's annoying, as we finally got rid of (almost) all of our old afp files.

From our point of view, there isn't a big problem with the way the resource forks are handled; before when you put font files (with only a resource fork) on a PC disk, you ended up with nothing. Now at least they can be put there. It's just the conversion from one system to another that caused problems.

Hope apple will work on this, because it's really a pain.

Oct 4, 2004 10:02 AM in response to Reinko Hallenga

I've said it before...I'll say it again...it's not an Apple Problem...it's a Windows problem...and the incompatibilities between the two platforms...now if you could petition Microsoft to allow you to hide "._" files...there'd not be an issue...

...but as I've also stated in the past...it's not just an "Apple" thing...iTunes uses the same style of filing for additional information about its media files on Windows and Mac...

Oct 4, 2004 3:40 PM in response to JohnQPublic

JohnQPublic -

This is definitely an Apple problem.

Microsoft's NTFS system supports multiple file forks within the same file. Microsoft's Services for Macintosh and other third party AppleShare products can store the files without having to resort to ._files. Our DAVE and ADmitMac SMB products can do it without requiring any special magic other than a lot of engineering time to understand the unique requirements.

As GunnarSchroeder astutely pointed out, Apple's SMB client implementation is based on Open Source that was not originally designed for the Macintosh.

For once, please don't blame Microsoft. Microsoft's SMB/CIFS specifications include support for the Macintosh. Apple has not implemented these enhancements.

-- Bill

Oct 4, 2004 4:42 PM in response to Don Hayes

"My client's problem is similar: they have a Windows server with publishing files on it. Three studio machines run 10.3.5, but one missed the update and is at 10.3.4. The 10.3.4 machine can browse the files and folders on the server with no problems, but the 10.3.5 machines see weird additional files and 'unix executables' plus the document names are contracted and munged. File paths are shot. The network and all other settings are identical between the machines - only the upgrade is the difference, which is supposed to have 'improved' SMB/CIFS and handling of NTFS. It's killed the studio bar one machine..."

Your 10.3.5 machines are connecting via SMB, while your 10.3.4 machine is connecting via AFP. At least that's what it sounds like to me. There's got to be some difference in the way they're configured. Double-check that AppleTalk is enabled or disabled consistently on all machines by using the Directory Access application (in /Applications/Utilities/).

"see weird additional files and 'unix executables' plus the document names are contracted and munged."

Are you seeing FINDER.DAT files, RESOURCE.FRK folders, and inside those folders are filenames that are written like "BERMUD~1", etc?

If not, could you please give specific examples of what the filesnames are, etc. A screen shot would be tremendously helpful in trying to tell you what's going on.

Thanks....

Oct 4, 2004 5:25 PM in response to JohnQPublic

<cite>I've said it before...I'll say it again...it's not an Apple Problem...it's a Windows problem...and the incompatibilities between the two platforms...now if you could petition Microsoft to allow you to hide "._" files...there'd not be an issue...</cite>

Apple delivers AFP and SMB with Panther. If you write files with resource forks via one of these protocols on a Windows server, and then later want to read them with the other, the files are corrupt.

So how this is not a problem Apple delivered goes beyond me.

Furthermore AFP is terribly slow used with Services for Macintosh and the SMB implementation lacks on every end.

OS X is a fine OS in many aspects, but the SMB implementation is really not up to the task. Luckily there are solutions from third party vendors that overcome these limitations - at a considerable cost though.

Ciao
Gunnar

Oct 4, 2004 8:48 PM in response to Community User

"Apple delivers AFP and SMB with Panther. If you write files with resource forks via one of these protocols on a Windows server, and then later want to read them with the other, the files are corrupt."

First of all, the files are not corrupt. You are simply viewing them in a way that makes them look corrupt. And second of all, what the heck do you expect?

When you connect via SMB you're letting the Mac handle the HFS+ metadata and resource forks.

When you connect via AFP you're letting the Windows machine handle the HFS+ metadata and resource forks. Your Mac has no clue that it isn't saving to another Mac!

Services For Macintosh is great, isn't it? With it's 31 character limit on file names?

Oct 4, 2004 8:51 PM in response to Community User

"I don't expect them to break compatability again and change to the way OS 9 did it."

And OS 9 did it how?

Oct 5, 2004 7:32 AM in response to William Thursby

As GunnarSchroeder astutely pointed out, Apple's SMB client implementation is based on Open Source that was not originally designed for the Macintosh.

...this is very true...but neither was the OS currently used on Macintosh...BSD was not designed for Mac...and the first iteration of OS X was not ready for prime time...there was no real usability until 10.1.5 (ok...10.1.4)...and SAMBA was not added until 10.2...and I'm not playing the blame game or bashing Microsoft...it's just a Windows issue...

SAMBA is not a Microsoft construct and Windows is not fully SAMBA compliant either...I use several Non-Windows SMB Compliant OS's...and all of them have quirks in file sharing with Windows...I won't go into the headaches of file sharing between OS/2 (which is FULLY SAMBA compliant) and Windows...or NeXT...or SuSE...or even BeOS (although of all the choices BeOS is the easiest for file sharing with every platform with the least problems)...

DAVE is a great product...I used it with a company I worked for a while back...for letting our "Old World" Macs talk to our WinBoxen and fileservers...and DAVE does what Windows SHOULD be doing...filtering out the forks and allowing access to only the raw files...SAMBA shows everything...leaving it to the administrator (or user for that matter) to decide/know what files should be available for use...and which ones are "Phantoms"...

Right now we're running a Happy SAMBA Neighborhood...

2 Macs (one Old World and one FW800)
1 Aurora Server (OS/2 AEB Server as a DHCP/Fileserver)
1 Dual Boot (BeOS and SuSE)
4 WinXP Home
2 WinXP Pro
3 Win2000 Pro
1 NeXT (archaic...but it does everything we ask of it)

...needless to say getting everything to play well with each other was more than a few sleepless nights...the NeXT box still does not really play well with anyone...but it'll talk to the server (which is all that matters...I've owned it for so long I really don't have the heart to retire it)...

Some of the things that can be seen on the network insofar as file forks and other oddities can be interesting to say the least (which is the reason people using the XP Home and Win2000 boxes are locked out of parts of the network...all they can really access is each other (which too can be an issue at times)...and their "Z-Drive" on the server)...

...it's possible in a future release of OS X (possibly even "Tiger") that Apple will include SMB Filtering to hide resourse forks...but I've seen the same "._" files on WinBoxen (which have never been near a Macintosh) running iTunes...

--Scott

Oct 5, 2004 3:42 PM in response to MarkDouma®

First of all, the files are not corrupt. You are simply viewing them in a way that makes them look corrupt. And second of all, what the heck do you expect?

That is correct. Nevertheless the client connecting with the other protocol cannot use those files. To this client the files look corrupt and are unusable. And that is part of the confusion people got caught in and led to quite a few threads like this one. They got confused the files didn't work on all their machines anymore and that some clients see dot-underscore files they didn't expect.

A work around would be to copy all files to a Mac with the originally used protocol ant then copy them back with the protocol that shall be used in the future and make sure all clients connect with the same protocol. Nice task at hand, if you handle a Terabyte or so and still have OS 9 machines on your network.

Another way to handle this is to change the SMB client on the workstations to a product from Thursby that handles resource forks on Windows servers like OS 9 did. And that is what I expect from Apple's implementation.

Many people start with a server filled with files from OS 9 machines. Then they implement OS X with SMB because Apple praised its compatability with Windows and get cought in this mess.

Ciao
Gunnar

Oct 5, 2004 3:53 PM in response to MarkDouma®

And OS 9 did it how?

That got already answered by William Thursby. OS 9 stores resource forks on Windows Servers with NTFS files systems in NTFS streams. OS X does not anymore, it stores them in seperate dot-underscore files.

An old article by MS discusses this. I just dig that up with a quick search, I bet there are better and newer articles on the topic.

Ciao
Gunnar

Oct 5, 2004 4:08 PM in response to JohnQPublic

As you could have seen by reading my post above, Apples SMB implementation is not Samba.

Ciao
Gunnar

Oct 6, 2004 7:24 AM in response to Community User

Gunnar...

SMB/CIFS IS SAMBA...Borris Popov chose to create a stable BSD port of the SAMBA project's work...something the SAMBA developers really haven't done because BSD is significantly differing with respect to Linux and Debian...likewise it is easier for the Darwin Team to pick up where Popov left off than to work from the original open source of the SAMBA Teams...but seeing that I am not part of the Darwin Team...I cannot tell you what iteration they actually chose...but the foundation has been the same since 1992...

...right now you're arguing semantics and picking nits...my whole point is this is not really a problem with Apple or OS X...if you use other OS's than Windows and OS X (some more further across the fields)...you end up with other strangeness than just "._" preceding certain "clones" of filenames...try working with OS/2...NeXT...Debian...OpenBSD...Gentoo...or BeOS for a bit and you might understand what I've been saying...it is not an Apple issue (or any of the other OS's I've worked with...it's a Windows problem...

Oct 6, 2004 3:14 PM in response to JohnQPublic

...right now you're arguing semantics

You are somewhat right, I was too tired to comment appropriately.

Yet we have a new problem at hand with Windows Servers. This thread now gives people that search some information at hand, to educate themselves further and hopefully choose a good solution for their environment.

CU
Gunnar

Nov 11, 2004 5:35 PM in response to StealthRocket

Add me to the list of people having this problem. From what I read in this post it looks as if ExtremeZ-IP ( http://www.grouplogic.com) or DAVE/ADmitMac ( http://www.thursby.com) will fix this problem since they allow the information to be stored with out the extra resource fork files (i.e. ._filename).

It looks as if the other option may be to connect using AFP, although that means you will have to run AppleTalk and deal with the performance issues (AFP is A LOT slower connecting to windows shares), but this would not store the extra hidden files. (This is not an option in our environment.)

I'm kind of annoyed that I have to shell out extra cash to install a 3rd party plug in to get this working, but I don't see any other way around it. Grrrrrr. I am planing on testing ExtremeZ-IP to see if this fixes our problem. From what I read here, it looks as if it will...

Nov 11, 2004 5:49 PM in response to StealthRocket

Has anyone gotten better results with SMB access to Windows after upgrading to 10.3.6?

Since upgrding to 10.3.6, I've not had a problem but I don't use it heavily.

I've been able to create problems by deleting (from a Windows machine) a file while leaving the ._ companion file. I fear that's what wil happen if I let my Mac users work with such files in a cross-platform environment. The users on the Windows side will modify the name or location of a file without knowing about the ._.

This is a really dumb implementation given the ability of NTFS to store this info in a stream in the same file. I assume that is what 3rd parties solutions use.

I'm also trying to get funding for ExtremeZIP. Management's initial response: Why do we need Macs anyway, if they are such trouble and add to the expense?

Apple -- are you listening?

Jack

._ files are locking up the real files.