Senaryosu - NTFS Sembolik Bağlantısı mı, Bağlantı mı?

17

farklılıklar

┌───────────────┬──────────┬──────────┬──────┬──── ───────┬─────┐
│ │ Mutlak │ Göreli │ Dosya │ Dizin │ UNC │
├───────────────┼──────────┼──────────┼──────┼──── ───────┼─────┤
│ Sembolik bağlantı │ Evet │ Evet │ Evet │ Evet │ Evet │
│ Kavşak │ Evet │ - │ - │ Evet │ - │
└───────────────┴──────────┴──────────┴──────┴──── ───────┴─────┘

senaryo

Diyelim ki yeniden yönlendirmeyi oluşturmak için bir yeniden inceleme noktası oluşturuyoruz C:\SomeDir => D:\SomeDir

Bu senaryo yalnızca yerel, mutlak yollar gerektirdiğinden, bir kavşak veya simge bağlantısı işe yarayacaktır. Bu durumda, birini veya diğerini kullanmanın herhangi bir avantajı var mı?

İşletim sistemi için geriye dönük uyumluluğu göz ardı ederek Windows 7'yi varsayalım. (Vista'dan önce , Windows XP'de sembolik destek sağlayan 3. taraf bir sürücü olsa da, semboller yerel olarak desteklenmez .)

Güncelleme

Başka bir fark buldum.

Sembolik Bağlantı - Bağlantının izinleri yalnızca bağlantının kendisindeki silme / yeniden adlandırma işlemlerini etkiler, okuma / yazma erişimi (hedefe) hedefin izinlerine tabidir
Kavşak - Kavşak izinleri numaralandırmayı etkiler, hedef klasörde daha izinli ACL'ler olsa bile, kavşaktaki izinlerin iptal edilmesi bu kavşak üzerinden dosya listelemeyi reddeder

Simgeler, eski uygulamaların, %ProgramFiles%mevcut erişim izinlerini değiştirmeden, dosyaları kısıtlanmamış bir yerde depolayarak ve kısıtlı dizinde semboller oluşturarak UAC kısıtlı alanlarındaki (örneğin ) yapılandırma dosyalarına erişmesine izin verebileceğinden, izinler bunu ilginç kılar .

Güncelleme 2

Windows 8.1, bir Save As...iletişim kutusundaki metin kutusundan birine giderken sembolik dizin bağlantılarını çözer . Kavşaklar genişletilmez.

İzin farkı bilgilerine bir bağınız var mı? Bu oldukça bulmak.

— surfasb

Testim, hedef dizine okuma erişiminin (yani, dizin içeriklerinin listelenmesi), hedef dizinde bulunanlara ek olarak bağlantı noktasındaki izinlerle kısıtlandığını doğrular. Ancak, etkilenen başka hiçbir erişim görünmüyor. Özellikle, hedef dizin izinleri izin veriyorsa, bağlantı noktası izinlerinden bağımsız olarak dosyalar ve alt klasörler oluşturabilirsiniz.

— Harry Johnston

@HarryJohnston: Başlangıçta, müzakerelere silme ve yazma izinlerini engellerken bazı tutarsızlıklardan şüphelendim, ancak altındaki öğeler ve alt klasörler gayet iyi.

— surfasb

İstenmedikçe bu tam bir cevap vermeyeceğim, ancak birime bir GNU veya Windows olmayan bir sistem kullanıyorsanız, birime mount.cifsnormalde dizinler olarak görünecek, ancak bağlantılar normal dizinler olarak görülecektir. GÇ çözünürlüğünün oluştuğu nokta, yani yerel olarak Windows ana bilgisayarında.

— can-ned_food

4

NTFS sembolik bağlantılarının, aynı şekilde çalıştıklarından ancak ek işlevsellik (uzak noktalar) sağladıkları için yeni Windows işletim sistemlerindeki (Vista / 7/8) Bağlantıların yerine geçeceğini anlıyorum. Bu nedenle, yalnızca daha yeni işletim sistemleriyle çalışmanız koşuluyla, sembolik bağlantı seçeneğini kullanmamanız için hiçbir neden yoktur.

— Garrett
kaynak

Varsayılan olarak, sunuculardaki semboller yok sayılır ve izlenenler sunucunun paylaşım düzeyi erişim kuralları tarafından kısıtlanmış olsa bile: örneğin, sunucuda paylaşılmayan bir konuma sembolik bağlantı alamazsınız. paylaşım kullanıcıya erişim vermez. Dolayısıyla sembolik bağlantılar tüm bağlamlarda bağlantı noktalarının yerini alamaz.

— Harry Johnston

2

Bağlantı noktalarının yedekleme yazılımında sembolik bağlantılardan daha geniş bir desteği olduğunu düşünüyorum. Hangi özelliği destekliyorsanız kullandığınız yedekleme programını kontrol etmelisiniz.

Desteklenmiyorsa, sembolik bağlantı / bağlantı noktası ayrı bir dizin olarak yedeklenir (ve bu şekilde geri yüklenir) veya hiç yedeklenmez.

Yedekleme sorunu dışında, özel durumunuzda (yerel dizin) birini diğerine tercih etmek için bir neden göremiyorum.

— haimg
kaynak

Bağlantı noktaları ve Simgeler, yeniden inceleme noktaları kullanılarak NTFS aracılığıyla uygulanır. MSDN'ye göre, her ikisi de API yoluyla dosya işlemleri ile aynı şekilde ele alınır.

— surfasb

2

@surfasb: Ancak semboller özellikle desteklenmiyorsa (ve böyle tanınırsa), yedeklemeden geri yükleme sırasında sembolik bağlantılar olarak yeniden oluşturulmazlar.

— haimg

Ah, çok iyi bir nokta! İleride yeterince düşünmedim.

— surfasb

Bildiğim kadarıyla, birime eski Windows işletim sistemleri tarafından erişilecekse bu daha önemlidir.

— can-ned_food

1

NTFS bağlantıları yalnızca dizinlere işaret edilirken, semboller dosyalar üzerinde de çalışır.

— user1686
kaynak

Ancak dosyalar için bunun yerine bir hardlink kullanabilirsiniz.

— paradroid

0

İşte fark ettiğim bir fark:

Komut dosyaları, taşınabilir uygulamalar, vb senkronize bir dizin var. Başlat Menüsü dizininde taşınabilir uygulamalar için kısayollar dizini gösteren bir Kavşak yapmak için bir toplu iş komut dosyası kullanın.

Bir Kavşak, kısayolların Başlat Menüsünde görünmesini sağlar. Bunun yerine bir Sembolik Bağlantı kullandığımda çalışmıyor.

— Paradroid
kaynak

Garip, bu benim için iyi çalışıyor. Makineme takılı flash sürücüler için de sembollerim var.

— surfasb

@surfasb: Tarif ettiğim şeyi yaptığınızdan emin misiniz? Başlat Menüsü dizinine sahip sembolik bir bağlantıyla gösterilen bir dizindeki kısayollar, Başlat Menümde görünmüyor. Bunun yerine bir Kavşak kullanıldığında yaparlar.

— paradroid

Bunu doğru okuduğumdan emin değilim. Başlat menüsünde, kısayol içeren bir klasöre işaret eden bir sembolik bağlantı? Hemen şimdi denedim. Hatta sembolik kısayollar ile UNC yolu üzerindeki klasöre işaret unc yolda başka bir sembolik işaret var. Tabii ki kısayolları kırar. Ancak Windows'ta "uzaktan kumandayla uzaktan" symlink geçişi varsayılan olarak devre dışıdır.

— surfasb

0

Belki yorumlarda bir yerde kaçırdım, ancak benim için Windows'taki semboller ve kavşaklar arasındaki çok önemli bir fark, her ikisini de oluşturmak için gerekli ayrıcalıklardır. Symlinks varsayılan olarak yalnızca varsayılan kullanıcıların sahip olmadığı özel izinler kullanılarak oluşturulabilirken, kavşaklar tüm varsayılan kullanıcılar OOB tarafından kolayca oluşturulabilir ve bu nedenle dirs için tercih ettiğim bağlantı türüdür.

Varsayılan olarak, Administrators grubunun üyeleri bu hakka sahiptir.

https://docs.microsoft.com/en-us/windows/device-security/security-policy-settings/create-symbolic-links

— Thorsten Schöning
kaynak