Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
A Bindlink kódtár lehetővé teszi a rendszergazdák számára, hogy egy fájlrendszer-névteret helyi virtuális elérési úthoz kössenek, a kötésszűrőn (miniszűrő bindflt.sys) keresztül. A kapcsolati hivatkozások fájlrendszer-átirányítást biztosítanak egy helyi virtuális elérési útról egy helyi vagy távoli háttérelérési útvonalra. Elsősorban kétféle forgatókönyvet engedélyezhetnek: először is helyi megjelenésűvé tehetik a távoli fájlokat egy hálózati megosztáson keresztül, ami javítja az alkalmazások kompatibilitását, másrészt lehetővé teszik azokat a forgatókönyveket, amelyekben egy alkalmazás azt szeretné, hogy a különböző helyekről származó fájlok új helyen jelenjenek meg, esetleg különböző névvel és címtárstruktúrával, a fájlok másolása nélkül. A kötési hivatkozások transzparensek az alkalmazások számára, és az összes meglévő API az átirányítás ismerete nélkül működik. A virtuális elérési úthoz nem jön létre fizikai fájl vagy könyvtár, és a kötési hivatkozások kiterjesztik a biztonsági leírókat és engedélyeket a háttérelérési útvonalon lévő fájlok és könyvtárak számára a virtuális elérési útra.
Használat
Az API-k halmaza 2 kapcsolódó függvényből áll:
- CreateBindLink – Ez az API lehetővé teszi a rendszergazdák számára, hogy kötési kapcsolatot hozzanak létre egy virtuális elérési út és egy háttér elérési út között.
- RemoveBindLink – Ez az API lehetővé teszi, hogy a felhasználó eltávolítson egy korábban létrehozott hivatkozást a CreateBindLinkmeghívásával.
A függvények használati példáit lásd a Bindlink-példákalatt.
Kötési hivatkozások létrehozása
A kötési hivatkozások transzparensek az alkalmazások számára, és bár ezek a hivatkozások léteznek, az összes művelet a háttérútvonalra vonatkozik. Ennek eredményeképpen DeleteFile vagy RemoveDirectory a háttérelérési útvonalon lépnek érvénybe, így a háttér elérési útját törli, a hivatkozást azonban nem. Ez az API sikertelen lesz, ha a felhasználó nem rendelkezik rendszergazdai jogosultságokkal, ha a felhasználónak nincs engedélye a virtuális elérési út vagy a háttérút megnyitására, ha a háttérútvonal nem létezik, ha a virtuális elérési úthoz egy másik hivatkozás is létezik, vagy ha a hivatkozás beállításakor belső hiba történt. A rendszergazda felhasználónak képesnek kell lennie a szűrő csatolására (FilterAttachengedélyeivel), csatlakozni a szűrőporthoz (FilterConnectCommunicationPortengedélyeivel), és elérni a támogató útvonal gyökerét, különben az API sikertelen lesz ERROR_ACCESS_DENIED.
Ha egy alkalmazás a hivatkozás beállítása után törölt háttérútvonalra mutató hivatkozást kísérli meg követni, az alkalmazás ERROR_FILE_NOT_FOUND* jelenik meg. Később, ha a háttér elérési útja ismét létrejön, a hivatkozás erre az új háttérútvonalra is érvényes lesz. Ha a virtualPath-nél hoznának létre egy fájlt, miközben a hivatkozás létezik, az megjelenne a virtualPath-nél, ha a hivatkozás létezik, de fizikailag a háttér útvonalon hoznák létre. A hivatkozás eltávolításakor a fájl csak az eredeti útvonalon jelenik meg, és többé nem fog megjelenni a virtualPath. Ez az alábbiakban ismertetett összes hivatkozástípusra vonatkozik.
Attól függően, hogy a virtuális elérési út lemezen található-e, az eredményül kapott hivatkozás vagy horgony nélküli hivatkozás vagy árnyékhivatkozás lesz.
Horgony nélküli hivatkozások
A horgony nélküli hivatkozások olyan kötési hivatkozások, amelyek akkor jönnek létre, ha a virtuális elérési út nem létezik a lemezen a hivatkozás létrehozása előtt. Az ilyen típusú hivatkozás létrehozásakor a virtuális elérési út a memóriában szintetizálódik, és normál elérési útként jelenik meg a fájlrendszerben. Vegye figyelembe, hogy egy ilyen kötési hivatkozás létrehozásához a virtuális elérési út szülőjének lemezen lévő könyvtárként vagy korábban létrehozott hivatkozásként kell léteznie. A C:\Foo\Bar virtuális elérési útként való használatához például a C:\Foo fájlnak lemezen lévő könyvtárnak kell lennie, vagy korábban egy másik hivatkozás virtuális elérési útjaként kell létrejönnie. Egy kötetnek nincs szülője, így nem lehet horgony nélküli link egy olyan kötethez, amely nem létezik. Egy "Z:" virtuális elérési úttal rendelkező kötési hivatkozás létrehozása például sikertelen lenne, ha még nem lett volna "Z" nevű kötet.
Árnyéklinkek
Az árnyékhivatkozások olyanak, ahol a virtuális elérési út a hivatkozás létrehozása előtt létezik a köteten. Ha egy ilyen virtuális elérési utat használ egy hivatkozás létrehozásához, a virtuális elérési út tartalma rejtve marad, míg a háttérútvonal tartalma láthatóvá válik a virtuális útvonalon. Például:
- C:\Foo exists on disk with two files Cat.txt and Dog.txt
- C:\Bar exists on disk with two files Cow.txt and Mouse.txt
Amikor a rendszer létrehoz egy hivatkozást a C:\Foo virtuális elérési úttal, a C:\Bar pedig háttérútvonalként, a C:\Foo path will then show Cow.txt and Mouse.txt to all users while Cat.txt and Dog.txt rejtve marad, amíg el nem távolítja a hivatkozást.
Az alábbi diagram egy újabb példával segít megkülönböztetni az Árnyék- és Horgony nélküli kapcsolatot.
A c:\Foo-t számbavevő felhasználó még a diagramban látható kötési hivatkozások létrehozása előtt megkeresi a könyvtárat és annak meglévő tartalmát. A hivatkozások létrehozása után a c:\Foo könyvtár felsorolásakor C:\Foo\Bar and Cow.txtfog megjelenni. Mivel a C:\Foo kapcsolattal vagy anélkül létezik a lemezen, a C:\Foo és a \\Remote\Target közötti kapcsolat árnyékhivatkozás.
A c:\Foo-t számbavevő felhasználó nem látja a c:\Foo\Bar elemet a második kötési hivatkozás létrehozása előtt. Mivel a C:\Foo\Bar csak a c:\Foo\Bar és a C:\Target2 közötti kapcsolat hozzáadása után jelenik meg, ez kizárólag virtuális, ezért a c:\Foo\Bar és a C:\Target2 közötti kapcsolat horgony nélküli kapcsolat.
Vegye figyelembe, hogy mindkét ilyen típusú hivatkozás esetében a háttérút biztonsági leírói érvényesek.
Bizonyos jelzők átadhatók az alapértelmezett viselkedés módosításához a felhasználó igényeinek megfelelően.
CREATE_BIND_LINK_FLAG_MERGED jelző
Az egyesített hivatkozás olyan, mint egy árnyékhivatkozás, azzal a különbséggel, hogy a virtuális elérési úton található meglévő tartalom össze van olvasztva a háttérútvonallal. Az ilyen típusú hivatkozás létrehozásához a CREATE_BIND_LINK_FLAG_MERGED jelzőt kell használni.
Tekintsük át ismét az árnyékhivatkozás korábbi példáját a jelző hozzáadásával.
Például:
- C:\Foo exists on disk with two files Cat.txt and Dog.txt
- C:\Bar exists on disk with two files Cow.txt and Mouse.txt
Amikor létrehozunk egy kapcsolatot a C:\Foo virtuális útvonallal és a C:\Bar háttérútvonallal, a CREATE_BIND_LINK_FLAG_MERGED, C:\Foo path will show Cat.txt, Dog.txt, Cow.txt and Mouse.txtjelzővel.
Fontos megjegyezni, hogy az egyesített hivatkozások csak akkor érvényesek, ha a virtuális elérési út könyvtár. Abban az esetben, ha egy fájl a háttérútvonalon és a virtuális útvonalon is megjelenik, a háttérútvonalon lévő fájl elsőbbséget élvez , azaz a virtuális elérési út fájlja maszkolt. Ez rekurzívan vonatkozik a virtuális útvonalon belüli összes könyvtárra. Mivel az egyesítés a címtárakra vonatkozik, ha a virtualPath és a backingPath egy azonos nevű címtárral rendelkeznek, a címtár a hivatkozás eredményeként egyesül. Ha a hivatkozás nem egyesített hivatkozás, akkor a backingPath könyvtára elsőbbséget élvez, és felülírja a virtualPathkönyvtárát. Ha az egyesített hivatkozás létrehozásakor egy fájl az egyesített útvonalon lett létrehozva, akkor az fizikailag a backingPath jön létre (ahogy a kötési hivatkozás esetében is), és felülbírál egy azonos nevű fájlt a virtualPath.
Tekintsük át a következő könyvtárstruktúrát és a két különböző hivatkozást:
- c:\Foo\Sub\Foo_sub.txt
- c:\Bar\Sub\Bar_sub.txt.
Ha a c:\Foo össze van kapcsolva a c:\Bar -val egyesítés nélkül, akkor a c:\Foo\Sub will only show Bar_sub.txt. Ha azonban a c:\Foo a c:\Bar -hoz van egyesítéssel összekapcsolva, akkor a c:\Foo\Sub will show both Foo_sub.txt and Bar_sub.txt.
Mivel a kötési hivatkozások elérési utakon alapuló hivatkozások, ha egy fájlt lecserélnek, módosítanak vagy törölnek/újra létrehoznak a háttérútvonalon a hivatkozás létrehozása után, a virtuális elérési út a hivatkozás követésekor létező fájlra mutat. Ez azért történik, mert a hivatkozás feloldva van a fájl megnyitásakor. Ennek megfelelően, ha a háttérelérési útvonal egyik fájlja a hivatkozás miatt maszkol egy fájlt a virtuális elérési úton, és a háttérelérési útvonalon lévő fájlt törölték, a fájl megnyitására vonatkozó későbbi kérés megnyitja azt a virtuális elérési úton.
CREATE_BIND_LINK_FLAG_READ_ONLY jelző
Az írásvédett hivatkozások olyan kötött hivatkozások, amelyek megakadályozzák, hogy a rendszer felhasználói módosítsák a háttérelérési útvonalon található fájlokat, ha azokat a virtuális útvonalon keresztül érik el. Ez azt jelenti, hogy a háttérelérési útvonalon egy fájl módosítására engedéllyel rendelkező felhasználó akkor is módosíthatja a fájlt, ha a háttérelérési útvonalon keresztül fér hozzá, de nem, ha a virtuális útvonalon keresztül fér hozzá. A háttérútvonal engedélyei általában a megfelelő virtuális elérési út elérésekor érvényesek, CREATE_BIND_LINK_FLAG_READ_ONLY jelölő használata esetén azonban az írási engedélyek maszkolódnak. Ez biztosítja, hogy az alkalmazások lássák, hogy a fájl CREATE_BIND_LINK_FLAG_READ_ONLY.
Vegye figyelembe, hogy az írásvédett korlátozás csak a háttértár elérési útvonalán található fájlokra érvényes. Ha a hivatkozás egyesítve van, és az eredetileg a virtuális könyvtár elérési útjáról származó fájlok láthatók, azok módosíthatók maradnak.
Például:
- C:\Foo exists on disk with a file Cat.txt
- C:\Bar exists on disk with a file Cow.txt
Amikor a C:\Foo elérési úttal hoz létre hivatkozást, akkor C:\Bar as the backing path and the link is marked read-only and merged, both Cat.txt and Cow.txt látható lesz, de C:\Foo, however, Cat.txt will be modifiable while Cow.txt nem lesz módosítható.
Emellett ez az API számos más kapcsolati forgatókönyvet is támogat. Ezeket a következő szakaszok ismertetik.
Beágyazott hivatkozások
A kötési hivatkozások beágyazhatók. Ez azt jelenti, hogy egy virtuális elérési út elődje vagy leszármazott összetevője is lehet virtuális elérési út a saját kapcsolatához.
Vegye figyelembe, hogy a körkörös hivatkozásokra nincs korlátozás.
Vegye figyelembe a fenti "Beágyazott kötési hivatkozások" diagram hivatkozásait és sorrendjét.
Ha egy hivatkozás virtuális elérési úttal jön létre: C:\Foo\Bar, egy másik hivatkozás is létrehozható a C:\Foo virtuális elérési úttal, és egy másik hivatkozás is létrehozható a C:\Foo\Bar\Baz virtuális elérési útként.
Például:
- C:\Target exists on disk with a file Cat.txt
- C:\Target2 exists on disk with a file Dog.txt
- C:\Foo könyvtársávmal rendelkező lemezen létezik
Ha a C:\Foo\Bar a C:\Target (Link1) útvonalhoz van csatolva, és a C:\Foo a C:\Target2 (Link2) útvonalhoz van csatolva, akkor a felhasználó számbaveszi a C:\Foo will see Dog.txt és a könyvtár Bar-t, mivel a Bar könyvtár a saját hivatkozásának virtuális elérési útja. Ezt követően, ha a C:\Foo\Bar\Baz a C:\Target2 (Link3) útvonalhoz van csatolva, egy felhasználó a c:\Foo\Bar will see Cat.txt és a Baz könyvtárakat sorolja fel, mivel a Baz egy virtuális elérési út a saját hivatkozásához.
További kapcsolódási forgatókönyvek
A következő pontok fontosak, és mindig együtt kell figyelembe venni, amikor egy hivatkozás vagy hivatkozáskészlet eredményéről döntenek:
A háttérútvonal mindig elsőbbséget élvez és felülbírál, ha egy ugyanilyen nevű entitás szerepel a virtuális elérési úton vagy egy hivatkozás révén. Ez a kötési hivatkozások minden típusára vonatkozik.
Vegyük például a következő hivatkozást:
c:\Foo össze van kapcsolva c:\Targettel, ahol a c:\Target egy fájl.
Ebben az esetben a c:\Foo olyan fájlnak fog kinézni, amelynek tartalma megegyezik a c:\Target tartalmával egy horgony nélküli hivatkozáshoz. Még akkor is, ha a c:\Foo egy helyileg létező könyvtár (árnyékhivatkozás), a fenti hivatkozás a c:\Foo fájlként fog kinézni, ha a hivatkozás és a háttér elérési útja létezik.
Ütköző hivatkozások esetén a legutóbb létrehozott hivatkozás elsőbbséget élvez. A legutóbbi hivatkozás azonban nem rejthet el egy korábbi hivatkozást.
Egy másik példaként tekintse meg az alábbi hivatkozásokat. A második hivatkozás megváltoztatja a névtér nézetét.
- 1. hivatkozás: c:\Foo a c:\Target könyvtárra van hivatkozva, ahol a c:\Target egy könyvtár. c:\Target könyvtárban van egy Bar fájl
- Hivatkozás2: c:\Foo\Bar a következőhöz van csatolva: c:\Target2, where Target2 is a directory containing a file Cat.txt
Ebben az esetben a Hivatkozás1 létrehozása után a c:\Foo fájlsávot fog létrehozni. Azonban, a Link2 után a c:\Foo will show a directory Bar with a file Cat.txt. Hasonlóképpen, ha a c:\Target2 fájl volt, a c:\Foo\Bar egy C:\Target2 tartalommal rendelkező fájl lesz
Ha viszont a hivatkozások sorrendje az alább látható módon meg lett változtatva, akkor a c:\Foo\Bar will continue to appear as a directory showing Cat.txt a c:\Target2-ből. A háttérútvonal elsőbbséget élvez a virtuális elérési út elemeivel szemben, de maga a virtuális elérési út gyökerével szemben nem elsőbbséget élveznek.
- 1. hivatkozás: c:\Foo\Bar a következőhöz van csatolva: c:\Target2, where Target2 is a directory containing a file Cat.txt
- Link2: c:\Foo a c:\Target könyvtárhoz van csatolva, ahol a c:\Target egy könyvtár. c:\Target fájlja a Bar nevet viseli
Ahhoz, hogy egy hivatkozás sikeresen létrejöjjön, a virtuális elérési út szülőjének vagy helyileg kell léteznie, vagy az előző hivatkozásban kell megjelennie a backingPath által, vagy magának a virtuális elérési útnak kell lennie egy másik hivatkozásban.
Ha például a c:\Foo először a c:\Célhoz van csatolva, majd a c:\Foo\Bar\Baz egy háttérútvonalhoz van csatolva, a c:\Foo\Bar\Baz hivatkozás sikeres lesz, ha a c:\Foo\Bar a következő feltételek valamelyike miatt létezik:
- c:\Foo\Bar helyileg létezik, és az előző hivatkozás kivétel biztosítja, hogy a c:\Foo\Bar nem lett árnyékolva a c:\Target által (lásd a következő szakaszban szereplő kivételek), vagy
- c:\Foo\Bar az előző hivatkozás alapján létezik (azaz ha a c:\Target könyvtársávtal rendelkezik) vagy
- c:\Foo\Bar egy önmagában virtuális elérési út egy másik hivatkozásban (c:\Foo\Bar ==> valamivel)
Jegyzet
Ez azt jelenti, hogy a beágyazott horgony nélküli hivatkozásokat a legutóbb létrehozott legmélyebb hivatkozással kell létrehozni. Az árnyékhivatkozások azonban nem rendelkeznek ilyen korlátozásokkal, mivel a virtuális elérési utak már léteznek a lemezen.
Vegye figyelembe az alábbi, azonos sorrendben létrehozott hivatkozásokat:
- A C:\Foo a C:\Target elemhez van csatolva
- A C:\Foo\Bar a következőhöz van csatolva: c:\Target2
A hivatkozás létrehozása nincs hatással a háttérútvonal viselkedésére. Ezért a virtuális könyvtársáv a c:\Foo fájlban jelenik meg, és nem a c:\Target mappában. A hivatkozástábla a következőképpen fog kinézni:
- C:\Foo --> c:\Target, C:\Foo\Bar --> c:\Target2 és nem
- C:\Foo --> c:\Target, c:\Target\Bar --> c:\Target2
Kivételek a hivatkozások kötésére vonatkozóan
A létrehozott hivatkozás hatókörének korlátozásához megadható kivételek is. A kivétel elérési útjai annak a virtuális elérési útnak a leszármazottai, ahol a hivatkozás nem érvényes. A kivételi útvonalak lehetnek fájlok vagy könyvtárak, de a virtuális elérési út leszármazottjának kell lenniük. Az API-k megkövetelik, hogy a hivatkozás létrehozásakor elérhetőek legyenek a kivétel elérési útjai. A kivétel a kivétel elérési útjának összes leszármazottjára vonatkozik. Például:
- C:\Foo létezik a lemezen, és tartalmaz egy könyvtárat Bar és egy könyvtárat Baz.
- C:\Foo\Bar contains Cat.txt
- C:\Foo\Baz contains Dog.txt
- C:\Target exists on disk and contains a file Cow.txt
Ha a C:\Foo-ból C:\Targetre mutató hivatkozás jön létre a C:\Foo\Baz kivétellel, a felhasználó a következőket fogja látni:
- C:\Foo will contain the file Cow.txt a C:\Target, and the directory Baz with its child Dog.txt-ről. Vegye figyelembe, hogy a C:\Foo\Bar nem látható, mivel a hivatkozás elfedi azt.
A következő diagram a fent leírt forgatókönyvet mutatja be:
Végül a kötési hivatkozás kivételei nem vonatkoznak a horgony nélküli hivatkozásokra, mivel a horgony nélküli virtuális útvonalak definíció szerint nem rendelkeznek leszármazottaikkal, ezért nem rendelkeznek megfelelő elérési utakkal. Az API hibát ad vissza, ha a rendszer megpróbál kivételeket átadni a horgony nélküli hivatkozásnak.