Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am running an Ubuntu 10.04.1 LTS server. Frequently I open up files using AFP from my Mac. Inevitably this created .DS_Store files on the server (although for some reason they are named :2eDS_Store. However, it also creates variants on DS_Store files. These variants are often named similarly to other files in that directory. E.g.:

~$ ls
total 60K
-rw-r--r--  1 tarakhovsky  16K 2010-11-30 18:28 :2eDS_Store
drwx--S---  4 tarakhovsky 4.0K 2010-11-08 13:58 :2eTemporaryItems/
lrwxrwxrwx  1 tarakhovsky   15 2010-10-19 17:44 bigdisk -> /media/bigdisk//
...
drwxr-xr-x  3 tarakhovsky 4.0K 2010-11-03 18:24 Temporary Items/
drwxr-xr-x  3 tarakhovsky 4.0K 2010-11-30 01:34 tmp/
...

I've disabled creation of DS_Store files using:

defaults write com.apple.desktopservices DSDontWriteNetworkStores true

so hopefully this won't continue to occur—but I really want to get rid of all of the existing variants of DS_Store files already on the server. Any ideas as to why these variants are being created and how I can get rid of them all?

share|improve this question
    
To clarify: I can remove all of the ":2eDS_Store" files simply by issuing this script: sudo find / -name ":2eDS_Store" -- but I'd also like to get rid of the other "2e*" files. –  Ron Gejman Dec 1 '10 at 15:47

7 Answers 7

The :2e prefix appears to be a side effect of the netatalk service's default setting that disallows dotfiles; to avoid this (i.e. have the file names appear on the server as .DS_Store etc), add options:usedots to each share in /etc/netatalk/AppleVolumes.default (see this previous question and the netatalk documentation).

This won't either get rid of the existing ":2e" files or prevent new "." files from being created, just make new files get created with saner names (and make them properly invisible). The DSDontWriteNetworkStores setting you've done should prevent new .DS_Store files from being created, but won't prevent .TemporaryItems, .Trashes, ._* files (these are AppleDouble files that hold resources forks and nonstandard metadata), etc. I don't know of any way to prevent these from being created, you can only clean them up afterward (and hope they didn't have anything important in them -- this is not always a safe assumption).

I found a script by Christian Imhorst to delete various of these files on the server. The character encoding on his site is a little garbled, so I'll include a cleaned-up (and slightly modified...) version here. I've added a bit to the list of filenames to delete; feel free to edit the kill list to taste. But MAKE SURE YOU HAVE A BACKUP BEFORE RUNNING THIS, as any script that includes the characters "rm -rf" should be regarded as potentially dangerous.

#!/bin/bash
# Script:       sauber
# Object:       Cleans up your Linux file system after a 
#                   session with AppleTalk and Finder.
# Etymologie:   sauber means clean in German
# Author:       originally by Christian Imhorst [http://www.datenteiler.de/what-is-2eds_store/]
#                   modified by Gordon Davisson

# Test number of arguments here
if (( $# < 1 )) ; then
    echo >&2
    echo "We need an argument here." >&2
    echo "Usage:   ./sauber [Directory]" >&2
    echo "Example: ./sauber /home/christian"  >&2
    echo >&2
    exit 1
elif [[ ! -d "$1" ]] ; then
    echo "$1 is not a directory" >&2
    exit 1
fi

find "$1" \( -iname ':2eDS_Store' \
    -o -iname '.DS_Store' \
    -o -iname '.AppleDouble' \
    -o -iname 'Network Trash Folder' \
    -o -iname 'Temporary Items' \
    -o -iname ':2eTemporary Items' \
    -o -iname '.Temporary Items' \
    -o -iname ':2elocalized' \
    -o -iname '.localized' \
    -o -iname ':2e_*' \
    -o -iname '._*' \) -exec rm -rf {} \;
share|improve this answer

I know this is a very old question - but after upgrading to Lion I got this problem back. I just installed BlueHarvest and that seems to fix my problem. It removes the unwanted files on my Linux server.

share|improve this answer

Not sure why they are called :2e_something instead of .DS_Store, but nevertheless, TemporaryItems are created by Carbon applications (which is the old MacOS 9 compability layer still used by a few programs, ie. MS-Office), and you can't get rid of them, AFAIK, but they are safe to delete.

The system creates them in the first place because MacOS can't use extended attributes via Samba, even if the underlying FS would support them, so it stores such things as resource forks, folder labels etc. in hidden files.

These are a real pain if you also use other systems than MacOS to access the files because they don't know about this pairing and if you move, rename or delete files, you end up with lot of orphaned ._xxx files.

share|improve this answer
    
Right, I know why DS_Store files and the like are created. I just don't understand why their have funky named on my server! –  Ron Gejman Dec 1 '10 at 16:05

:2E is likely a variant of %2E which translates to a . (period) per http://www.w3schools.com/tags/ref_urlencode.asp

share|improve this answer

Just a guess here, but 0x2e is hex for 46, which is ASCII for the period character .. I assume that the .DS_Store files are getting renamed in such a way that they don't collide with the Linux naming convention that anything beginning with a dot is a hidden file. As to what mechanism is actually doing that, I don't know; but that explains the "2e".

share|improve this answer

You should be able to find all variants of the folder using:

find ./ -regex '/:2eDS_Store$' | xargs echo

This will not delete the files in place but you should check results first and not trust me blind :)

share|improve this answer

I wouldn't recommend deleting the dot files because it can cause problems with some of the applications that still use resource forks (plus most of them will just get recreated anyways). You might also see files that start with ._ and these files are the resource fork of the file from an Samba connection. We have these files on some of our servers and in the end we decided it wasn't worth the effort to clean them up every night due to the potential loss of data.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.