To nemají zaručeno. Je možné, že /foo/oldPath je přípojný bod.
To však lze snadno zkontrolovat spuštěním mount | grep 'on /foo/oldPath' Žádný výstup by neměl ukazovat, že oldPath adresář není přípojný bod.
Pokud používáte vnořené adresáře, budete muset být opatrnější, protože bod připojení můžete mít kdekoli.
Nejsem si jistý, zda je to automatizované, ale stojí za zmínku, že 3. pole od připojení (oddělené mezerou) je bod připojení pro každý řádek, takže použití cut -d ' ' -f 3 lze použít k extrahování cesty (pokud potřebujete ověřit, že to není jen podřetězec jiného přípojného bodu, například /foo/oldPath/nested/mountPoint )
Pokud to chcete přeložit do kódu C/C++, možná budete moci použít system("mount | grep 'on /foo/oldPath'") , ale nebudu na to přísahat. Možná budete mít větší štěstí na StackOverflow, kde najdete další podrobnosti o implementaci, pokud je budete potřebovat.
Neměli byste to zkoušet z různých důvodů (podrobně popsaných v dalších odpovědích):/foo/oldPath může být sám o sobě přípojným bodem nebo může být přítomen překryvný souborový systém a bránit přesunu souborů. Můžete se dokonce setkat s připojením vazby u jednotlivých souborů, což také způsobí problémy při přejmenování souborů.
Místo toho, abyste se pokoušeli předem určit, zda lze soubory přejmenovat, měli byste se je pokusit přejmenovat a vypořádat se s chybami. rename vrátí -1, pokud dojde k chybě, a errno bude nastaven na EXDEV pokud přejmenování není možné kvůli problémům s křížovou montáží. Poté můžete pokračovat jiným způsobem (zkopírovat a odstranit).
Obecně platí, že chcete-li zjistit, zda jsou dva objekty systému souborů na stejném systému souborů, měli byste spustit stat na nich a podívejte se na identifikátor zařízení (st_dev pole v struct stat ). Dva objekty systému souborů na stejném systému souborů budou mít stejný identifikátor zařízení.
Pamatujte, že když běžíte na overlayf, nemůžete se spoléhat na rename() z již existujících adresářů.
Myslím, že byste tuto možnost mohli obvykle ignorovat, pokud nepíšete obecný nástroj pro správu souborů... Například správce balíčků... v takovém případě jej zřejmě nepovažujete za opravitelný (z důvodů atomicity) a chcete spoléhat na nový redirect_dir formát překryvných vrstev.
Takže toto je spíše pedantská poznámka, abyste věděli, že se jedná o Linux, pokud nechceme, nedodržujeme POSIX a "zaručeno" je velmi silné slovo :).
https://www.kernel.org/doc/Documentation/filesystems/overlayfs.txt
Pokud není povolena funkce "redirect_dir", přejmenování(2) na nižším nebo sloučeném adresáři se nezdaří s EXDEV.
Overlayfs již neodpovídá obvyklým očekáváním unixového souborového systému v dalších detailech:
Objekty, které nejsou adresáři (soubory, symbolické odkazy, speciální soubory pro zařízení atd.), jsou prezentovány buď z horního nebo spodního souborového systému podle potřeby. Když se k souboru v nižším souborovém systému přistupuje způsobem, který vyžaduje přístup pro zápis, jako je otevření pro přístup k zápisu, změna některých metadat atd., soubor je nejprve zkopírován z nižšího souborového systému do horního souborového systému (copy_up)...
Operace copy_up v podstatě vytvoří nový, identický soubor a přesune jej pod starý název. Všechny otevřené soubory odkazující na tento inode budou mít přístup ke starým datům.