Unable to delete some 'hidden' Mac file from Win2003 server

We run a Win2003 server as a fileserver which is connected to by both
PC's and Macs. Unfortunately the Mac's leave a lot of
hidden ._filename files on the server. Often these files will be
completely locked so that I cannot even remove them when logged on as
administrator. Firstly, is there a way I can delete these files and
secondly, how can I stop them being written to the server as
occasionally these files will also prevent Mac users overwriting files
as well.

Many thanks

Pete

 

You can't and you shouldn't. Those files may contain data that's
critical to opening them correctly, depending on the specific file types
and (to a much less degree) the specific app that's trying to open them.

There _is_ a way to prevent the creation of the .DS_Store files that
some people find too distracting. It has to be done on the Mac(s) in
question. <http://docs.info.apple.com/article.html?artnum=301711> Doing
so may cause some inconvenience to the Mac users, but shouldn't be fatal.

G

 

I can understand this from the point of view when opening a pre-
existing Mac file but if I create a file on a PC and then it's opened
by a Mac, the file won't exist until it's first opened so this won't
be an issue?

I've already set the Macs in our office to do this.

 

I can understand this from the point of view when opening a pre-
existing Mac file but if I create a file on a PC and then it's opened
by a Mac, the file won't exist until it's first opened so this won't
be an issue?[/QUOTE]

It shouldn't be. The tricky part is coming up with a means to
automatically determine the difference so you know when it's safe.

The underlying problem is that Macs have, and Mac software assumes, a
richer file system than what Windows is able to offer. The dot files
you're seeing are the workaround that lets Mac software make those
assumptions without breaking when they're working with a weaker FS. The
real solution is to not make the Macs use SMB. Give them a server that
offers an up-to-date implementation of AFS and everyone will be happier.

 

It shouldn't be. The tricky part is coming up with a means to
automatically determine the difference so you know when it's safe.

The underlying problem is that Macs have, and Mac software assumes, a
richer file system than what Windows is able to offer. The dot files
you're seeing are the workaround that lets Mac software make those
assumptions without breaking when they're working with a weaker FS. The
real solution is to not make the Macs use SMB. Give them a server that
offers an up-to-date implementation of AFS and everyone will be happier.[/QUOTE]

Not fully correct. HFS+ does have features that at least FAT32 doesn't
have... but OS X isn't necessary using them all. Like Resource forks,
which true OS X files don't have. .DS_Store files exist on HFS+ just as
well, but Finder hides them and the initial dot hides them in Darwin as
well... try ls -a in Terminal & you see them. Not an issue of AFP vs SMB
vs anything else.

Mac Dude

 

What "OS X" is using is irrelevant. Unless we know the specific document
formats that may be stored on the OP's server(s) and the specific
applications that are reading and writing those documents, there's no
general mechanism to safely delete the dot files. (And all that's really
needed for this to be death, btw, is one legacy program that sets and
relies on the 4-byte file type code.)

What ever gave you that idea? Resource forks are discouraged for new
development, but to suggest that their presence on a file somehow
invalidates that file as "a true OS X file" is nonsensical.

Even if you want to persist in that absurd notion, how do you feel about
extended attributes - which have only come to the Mac since the advent
of OS X?

I had specifically addressed .DS_Store files earlier in the thread. The
issue is what users of other platforms see when they interact with a
file server whose network file system doesn't support the additional
features that Mac OS applications are supposed to be able to rely on.