Przenoszenie katalogu atomicznie

Ostatecznym rozwiązaniem jest połączenie symlink-i rename-podejście:

mkdir alpha_real
ln -s alpha_real alpha

# now use "alpha"

mkdir beta_real
ln -s beta_real tmp 

# atomically rename "tmp" to "alpha"
# use -T to actually replace "alpha" instead of moving *into* "alpha"
mv -T tmp alpha

Oczywiście, aplikacja uzyskująca dostęp do alfy musi być w stanie poradzić sobie ze zmianami dowiązań symbolicznych w ścieżce.

Przyjrzałem się rozwiązaniu Davida, które jest w pełni atomowe ... jedynym problemem jest to, że opcja -T dla {[2] } nie jest zgodna z POSIX, więc niektóre systemy POSIX mogą jej nie obsługiwać (FreeBSD, Solaris, itp. ... http://pubs.opengroup.org/onlinepubs/9699919799/utilities/mv.html). z niewielką modyfikacją, to podejście może być zmienione tak, aby było w pełni atomowe i przenośne we wszystkich systemach operacyjnych POSIX:

mkdir -p tmp/real_dir1 tmp/real_dir2
touch tmp/real_dir1/a tmp/real_dir2/a
# start with ./target_dir pointing to tmp/real_dir1
ln -s tmp/real_dir1 target_dir
# create a symlink named target_dir in tmp, pointing to real_dir2
ln -sf tmp/real_dir2 tmp/target_dir
# atomically mv it into ./ replacing ./target_dir
mv tmp/target_dir ./

Exaple via: http://axialcorps.wordpress.com/2013/07/03/atomically-replacing-files-and-directories/

Jeśli masz na myśli atomowe w obu operacjach, to nie sądzę. Najbliżej byłoby:

mv alpha delta
mv bravo alpha
rm -rf delta

Ale to wciąż miałoby małe okienko, w którym alfa nie istniała.

Aby zminimalizować prawdopodobieństwo, że cokolwiek spróbuje użyć Alfy, gdy jej nie ma, możesz (jeśli masz uprawnienia):

nice --20 ( mv alpha delta ; mv bravo alpha )
rm -rf delta

, co znacznie zwiększy priorytet Twojego procesu podczas operacji mv.

Jeśli, jak mówisz w swoim dodatku, jest tylko jedno miejsce, które sprawdza alpha i błędy it jeśli go nie ma, możesz zmienić ten kod na not error natychmiast, ale spróbuj ponownie w krótkim czasie ( łatwo sub-sekunda dla dwóch operacji mv) - te powtórzenia powinny złagodzić każdy problem, chyba że często zastępujesz alpha bardzo.

Użyj oddzielnej, gwarantowanej operacji atomowej, aby działać jako SEMAFOR.

Tak więc, jeśli operacje tworzenia i usuwania plików są atomowe:

1) Utwórz plik o nazwie "SEMAFOR".

2) wtedy i tylko wtedy, gdy to się powiedzie (brak konfliktu z istniejącym plikiem), wykonaj operację (albo proces alpha albo przenieś katalog, w zależności od procesu)

3) SEMAFOR rm.

Sekcja SQLite Dokumentacja blokowanie plików i współbieżność w wersji SQLite 3 posiada dobrze napisany opis swojego eskalującego protokołu blokującego, który kontroluje jednoczesne czytanie, ekskluzywne pisanie i wycofywanie po awarii. Niektóre z tych pomysłów mają tu zastosowanie.

To powinno załatwić sprawę:

mkdir bravo_dir alpha_dir
ln -s bravo_dir bravo
ln -s alpha_dir alpha
mv -fT bravo alpha

Strace mv-ft bravo alpha pokazuje:

rename("bravo", "alpha")

Nawet jeśli uzyskujesz bezpośredni dostęp do i-węzłów, nadal nie będzie możliwości atomicznej wymiany wartości i-węzłów w przestrzeni użytkownika.

Martwienie się o atomowy charakter operacji jest bez znaczenia. Chodzi o to, że dostęp do alfy przez inne zadanie i tak nie będzie atomowy.

Podejście do semafora Oddthinking to jedyna droga.

Jeśli nie możesz zmodyfikować innego zadania, musisz upewnić się, że nie działa przed wykonaniem wymiany.

Od Linuksa 3.15, nowe wywołanie systemowe renameat2 może atomicznie wymieniać dwie ścieżki w tym samym systemie plików. Jednakże, nie ma nawet glibc owijarki do niego jeszcze, nie mówiąc już o coreutils sposób, aby uzyskać do niego dostęp. Więc wyglądałoby to mniej więcej tak:

int dirfd = open(".../base", O_PATH | O_DIRECTORY | O_CLOEXEC);
syscall(SYS_renameat2, dirfd, "alpha", dirfd, "bravo", RENAME_EXCHANGE);
close(dirfd);
system("rm -rf alpha");

(oczywiście, należy zrobić właściwą obsługę błędów itp. - zobacz Ten gist {[10] } dla bardziej wyrafinowanego renameat2 opakowania.)

To powiedziawszy - rozwiązanie dowiązania symbolicznego wymienione przez innych jest zarówno łatwiejsze, jak i przenośne, więc chyba że bravo już istnieje, a ty musisz atomicznie go zaktualizować, zamiast tego użyj dowiązania symbolicznego.

Nie wierzę, że jest na to jakiś atomowy sposób. Najlepiej zrobić coś takiego:

mv alpha delme
mv bravo alpha
rm -rf delme

Należy pamiętać, że jeśli twój proces ma otwarty któryś z plików w alfie, gdy wystąpi ten ruch/usuwanie, proces nie zauważy, a wszelkie zapisane dane zostaną utracone, gdy plik zostanie zamknięty i ostatecznie usunięty.

Mv i ln mogą być używane do operacji atomowych. Użyłem ln (1) do atomicznego wdrażania aplikacji internetowych.

Poprawnym sposobem zastąpienia dowiązania symbolicznego jest LN-nsf

ln -nsf <target> <link_name>

Np.

$ mkdir dir1
$ mkdir dir2
$ ln -s dir1 mylink
$ ls -l mylink
lrwxrwxrwx  1 phil phil 4 Nov 16 14:45 mylink -> dir1
$ ln -nsf dir2 mylink
$ ls -l mylink
lrwxrwxrwx  1 phil phil 4 Nov 16 14:46 mylink -> dir2

Możliwe jest również zastąpienie całej części zawartości jednocześnie w jakimś prefiksie (Z tutaj) za pomocą unionfs-fuse:

# mkdir a b c Z
# touch a/1 b/2 c/3
# ln -s a X
# ln -s b Y
# unionfs X=RW:Y=RW Z
# shopt -s globstar
# file **
a:   directory
a/1: empty
b:   directory
b/2: empty
c:   directory
c/3: empty
X:   symbolic link to a
Y:   symbolic link to b
Z:   directory
Z/1: empty
Z/2: empty
# ln -sfn c Y
# file **/*
a:   directory
a/1: empty
b:   directory
b/2: empty
c:   directory
c/3: empty
X:   symbolic link to a
X/1: empty
Y:   symbolic link to c
Y/3: empty
Z:   directory
Z/1: empty
Z/3: empty
# fusermount -u Z
# rm -r a b c X Y Z

Dlaczego po prostu nie zrobisz czegoś takiego:

rm -rf alpha/*
mv bravo/* alpha/
rm -rf bravo/

Oznaczałoby to, że wszystko w alfa zostanie zniszczone, alfa nigdy nie zostanie usunięta, a cała zawartość zostanie przeniesiona.