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

Discussion in 'Apple' started by pete.jones, Jun 7, 2007.

  1. pete.jones

    pete.jones Guest

    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
     
    pete.jones, Jun 7, 2007
    #1
    1. Advertisements

  2. 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
     
    Gregory Weston, Jun 7, 2007
    #2
    1. Advertisements

  3. pete.jones

    pete.jones Guest

    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.
     
    pete.jones, Jun 8, 2007
    #3
  4. 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.
     
    Gregory Weston, Jun 8, 2007
    #4
  5. pete.jones

    The Mac Dude Guest

    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
     
    The Mac Dude, Jun 10, 2007
    #5
  6. 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.
     
    Gregory Weston, Jun 11, 2007
    #6
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.