Apa perbedaan antara simbolik dan tautan keras?


Jawaban:


40

Semantik yang berbeda antara tautan keras dan lunak membuatnya cocok untuk berbagai hal.

Tautan keras:

  • tidak bisa dibedakan dari entri direktori lain, karena setiap entri direktori adalah tautan keras
  • "asli" dapat dipindahkan atau dihapus tanpa memutus tautan keras lainnya ke inode yang sama
  • hanya mungkin dalam sistem file yang sama
  • izin harus sama dengan yang ada di "asli" (izin disimpan di inode, bukan entri direktori)
  • hanya dapat dibuat untuk file, bukan direktori

Tautan simbolik (tautan lunak)

  • cukup rekam yang mengarah ke jalur file lain. ( ls -lakan menunjukkan jalur yang ditunjuk symlink ke)
  • akan rusak jika dokumen asli dipindahkan atau dihapus. (Dalam beberapa kasus sebenarnya diinginkan tautan untuk menunjuk ke file apa pun yang saat ini menempati lokasi tertentu)
  • dapat menunjuk ke suatu file dalam sistem file yang berbeda
  • dapat menunjuk ke suatu direktori
  • pada beberapa format sistem file, symlink dapat memiliki izin yang berbeda dengan file yang ditunjuknya (ini tidak umum)

1
Daftar yang bagus. Hanya ingin menambahkan bahwa Anda juga dapat mematahkan symlink jalur relatif dengan memindahkan symlink itu sendiri.
jw013

4
"[E] entri direktori adalah tautan keras." Itu poin yang sangat bagus yang belum pernah saya lihat diungkapkan sebelumnya, tetapi saya khawatir bahwa seseorang yang baru saja mulai membungkus tautannya tidak akan mendapatkannya. Bagi mereka yang berada dalam situasi ini, inilah sebuah petunjuk: Tata letak file dan direktori yang Anda lihat ketika menjalankan perintah ls tidak persis sama dengan sistem penyimpanan yang diwakilinya. Tautan keras adalah referensi ke file individual pada sistem penyimpanan. File disimpan sekali. Baca di "inode."
Mario

@ Mario: ya. Setiap entri direktori menautkan nama ke inode. Panggilan sistem untuk menghapus nama file bahkan disebut unlink(2). File "normal" (dengan jumlah tautan 1) hanyalah kasus khusus. Jika ini membantu, Anda dapat menganggap inode sebagai objek, dan nama sebagai pointer yang dihitung ulang (jumlah tautan inode adalah jumlah referensi).
Peter Cordes

1
Anda dapat menganggap tautan simbolis sebagai file teks dengan nama di dalamnya. Itu ditafsirkan sebagai tautan simbolis karena bendera khusus untuk file. Contoh tautan keras yang Anda kenal ..dan ..
Ned64

berikut ini adalah jawaban lain yang menjelaskan mengapa tautan keras tidak dapat dibuat ke direktori . Saya menemukan jawaban ini bermanfaat karena lebih ringkas dan lebih mudah dibaca.
Trevor Boyd Smith

18

Inti dari kedua jenis tautan ini adalah menyediakan cara untuk membuat file muncul di dua lokasi secara bersamaan. Ini memiliki banyak kegunaan. 9 kali dari 10 Anda ingin menggunakan tautan simbolis.

Tautan simbolis, atau "symlink" berfungsi sedikit seperti pintasan Windows. Isi symlink adalah penunjuk ke lokasi sebenarnya dari file / direktori. Jika Anda menghapus file asli, symlink akan menjadi "menggantung," dan tidak akan berfungsi. Menghapus symlink tidak menghapus file asli. Anda dapat memiliki banyak symlink ke satu file (atau bahkan symlink lainnya) yang Anda inginkan.

Tidak seperti Windows, mereka bekerja pada level sistem file, bukan pada level shell atau aplikasi, jadi hampir semua aplikasi akan "mengikuti" symlink seperti yang diharapkan. ls -aldapat digunakan sebagai cara cepat untuk melihat ke mana symlink "menunjuk" ke.

Hardlink berfungsi bahkan pada level yang lebih rendah. Hardlink adalah entri direktori aktual pada level filesystem fisik aktual. Secara teknis, entri direktori adalah hardlink, sehingga setiap file memiliki setidaknya satu hardlink di direktori di suatu tempat. Hardlink tidak terpisah dari file yang mereka tuju; jika file memiliki banyak hardlink di direktori yang berbeda, menghapus hardlink dengan utilitas seperti rmtidak akan benar-benar menghapus file, sampai semua hardlink hilang.

Saya tidak dapat memikirkan situasi di mana penggunaan hardlink adalah umum, atau bahkan diperlukan, kecuali Anda sengaja ingin mencegah file terhapus atau melakukan beberapa pekerjaan tingkat rendah yang aneh dengan partisi atau hal-hal terkait sistem file lainnya. EDIT: Ada ide-ide bagus di jawaban lain untuk pertanyaan ini!


Juga, symlinks memiliki izin seperti file normal, tetapi sistem operasi tidak berkonsultasi dengan mereka, itu berkonsultasi dengan file yang ditargetkan izin untuk memutuskan perilaku. Dan, jangan lakukan rantai sirkular symlink. Sangat buruk.
LawrenceC

3
Apakah ini sangat buruk? Apa yang akan terjadi? Yang paling menggairahkan yang bisa saya buat ulang adalah pesan kesalahan "Terlalu banyak level tautan simbolik".
mattdm

1
ls -lsudah cukup untuk melihat apa yang sedang dihubungkan oleh symlink, asingkatan dari --all, lihat manpage. Dan bahkan jika symlink bekerja di sistem file, ada fungsi alternatif untuk menggunakan tautan simbolik sebagai file alih-alih mengikuti.
D4RIO

4
Cara pintas Windows sebenarnya sangat berbeda dari symlink: mereka mengikuti target mereka, dan mereka juga file biasa. (Windows juga memiliki symlink, tetapi mereka tidak banyak digunakan.) Symlinks murni tekstual, teks target dibaca setiap kali Anda mengakses file. Apakah masalah perizinan symlink tergantung pada OS dan sistem file.
Gilles 'SO- stop being evil'

AFAIK, konten file symlink adalah jalur yang ditunjuk symlink, yang dapat dilihat ketika melihat ukuran file symlink: ln -s /home 1; ls -l 1menunjukkan bahwa symlink 1 memiliki panjang 5 byte, sedangkan ln -s /usr/share/ 2; ls -l 2showas yang panjangnya 2 adalah 11 byte.
daniel kullmann

13

Tautan keras sangat berguna untuk mekanisme cadangan berbasis disk, karena Anda dapat memiliki pohon direktori lengkap untuk setiap cadangan sambil berbagi ruang untuk file yang belum berubah - dan sistem file melacak penghitungan referensi, jadi ketika referensi terakhir ke versi tertentu hilang karena cadangan telah kedaluwarsa / dihapus karena alasan ruang, ruang yang digunakan secara otomatis direklamasi. Beberapa klien email juga menggunakannya untuk pesan yang diajukan ke beberapa folder, dengan alasan yang sama.


5
Mungkin mekanisme kontrol versi berbasis disk? Jika Anda mengaitkan sesuatu, maka itu bukan cadangan. Jika file asli rusak, setiap hardlink juga rusak.
D4RIO

1
Pikirkan sistem cadangan tambahan seperti Time Machine Apple. (Seharusnya jelas bahwa ini bukan cadangan jenis pemulihan bencana, tetapi cadangan "oops, saya menghapus file itu secara tidak sengaja"). Semua file yang tidak berubah dalam cadangan tambahan di-hardlink bersama-sama; ketika file diubah, inkremental berikutnya menyalinnya dan bukannya menautkan ke versi sebelumnya.
geekosaur

Terima kasih, maka sistem cadangan tambahan cukup mirip dengan sistem kontrol versi dengan cara ini = D
D4RIO

Tetapi bagaimana mekanisme cadangan tambahan mempertahankan versi file "lama"? 1) Cadangan A dibuat, itu file hardlinked F; 2) File F dimodifikasi; 3) hari berikutnya Backup B dibuat ... Sepertinya saya tidak mendapatkan sesuatu
Dmitry Pashkevich

3

Hard link hanyalah referensi ke ruang disk yang sama, itu sebabnya Anda tidak bisa menghubungkan sesuatu ke sistem file lain.

Symlink adalah file yang menghubungkan file lain (seperti pintasan Windows), mungkin dalam sistem file yang sama, mungkin tidak.

EDIT: Saya akan menjelaskan sesuatu yang lebih. Setiap file yang ada memiliki minimal 1 tautan keras. Hard link adalah cara untuk mengakses konten dari inode sistem file. Anda dapat memperoleh nomor inode file dengan ls -i, dan mendapatkan jumlah hardlink dengan statsebagai berikut dalam contoh ini:

$ stat plantilla-disenos.odt 
  File: «plantilla-disenos.odt»
  Size: 12367       Blocks: 32         IO Block: 4096   fichero regular
Device: 803h/2051d  Inode: 319875      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   d4rio)   Gid: ( 1000/   d4rio)
Access: 2011-02-11 21:36:19.000000000 -0300
Modify: 2010-03-02 23:27:28.000000000 -0300
Change: 2010-04-10 17:46:27.000000000 -0300

Terima kasih @geekosaur untuk referensi ini:

Kernel harus memulai kembali terjemahan pathname-to-inode (melintasi pohon direktori) untuk memperluas symlink, sedangkan semua hard link menggunakan inode yang sama. (Anda akan sering melihat ini disebut sebagai namei, dari nama fungsi kernel yang melakukan ini di Unix tradisional.)

dan ini (diedit):

Hard link sangat berguna untuk mekanisme cadangan inkremental berbasis disk seperti Apple's Time Machine , karena Anda dapat memiliki pohon direktori lengkap untuk setiap cadangan sambil berbagi ruang untuk file yang belum berubah - dan sistem file melacak penghitungan referensi, jadi ketika referensi terakhir ke versi yang diberikan hilang karena cadangan telah kedaluwarsa / dihapus karena alasan ruang, ruang yang digunakan secara otomatis direklamasi. Beberapa klien email juga menggunakannya untuk pesan yang diajukan ke beberapa folder, dengan alasan yang sama.

Tepuk tangan


Apakah manfaat kinerja menggunakan tautan keras? Atau, mengapa Anda pernah menggunakan tautan keras alih-alih symlink?
ripper234

Kernel harus memulai kembali terjemahan pathname-to-inode (melintasi pohon direktori) untuk memperluas symlinks, sedangkan semua hard link menggunakan inode yang sama. (Anda akan sering melihat ini disebut namei, dari nama fungsi kernel yang melakukan ini di Unix tradisional.)
geekosaur

@ ripper234: Hardlink adalah solusi penghemat ruang disk. Anda tidak perlu tahu tentang sistem file untuk membuat symlink, tetapi Anda harus berpikir sebelum membuat symlink karena Anda dapat membuat loop atau jalur resolusi yang panjang, sehingga fungsi seperti statakan gagal.
D4RIO

@geekosaur: Saya menambahkan jawaban Anda ke saya karena itu sangat berguna
D4RIO

Tidak masalah. Saya sebenarnya mulai menulisnya sebagai komentar untuk Anda, tetapi komentarnya terlalu pendek.
geekosaur

3

Tautan lunak menunjuk ke nama path lain. Pathname itu mungkin ada atau tidak ada. Path tidak dicari sampai Anda mengakses symlink. Jika jalur tidak ada ketika Anda mencoba mengaksesnya, Anda memiliki symlink yang rusak.

Dengan tautan keras, Anda memiliki satu file dengan banyak nama. Anda tidak dapat mengatakan bahwa salah satunya adalah file "asli" dan yang lainnya hanya tautan ke sana. Mereka semua sama. Tidak ada yang namanya tautan keras yang rusak seperti halnya ada tautan yang rusak.

Tautan keras hanya berfungsi dalam satu sistem file. Jika Anda ingin menautkan ke file pada sistem file yang berbeda (misalnya partisi yang berbeda atau berbagi jaringan), Anda harus menggunakan tautan lunak.

Perbedaan besar lainnya adalah apa yang terjadi ketika Anda menghapus file yang ditautkan. Jika Anda menghapus salah satu dari sepasang file yang di-hardlink, kemudian membuat file baru dengan nama yang sama, Anda akan memiliki dua file yang terpisah (tautannya hilang). Jika Anda menghapus target symlink dan membuat file baru dengan nama yang sama, tautan tersebut akan mengarah ke file baru.


3

Tautan "keras" berbagi inode yang sama

$ touch foo
$ ln foo foolink # Creates a hard  link
$ ls -li foo foolink
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foo
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foolink

Jika saya mengedit foo atau bodoh, hanya ada satu file dan itu akan diperbarui. Jika saya menghapus hanya satu dari nama file, inode dan data akan bertahan, bodoh akan bertahan.

$ rm foo
$ ls -li foo foolink
ls: cannot access foo: No such file or directory
54996 -rw-r--r-- 1 bsd users 0 2011-12-11 09:06 foolink

Jika saya membuat yang sama, tetapi dengan tautan "lunak" atau simbolis, maka Ada satu file, satu inode, dan file baru dengan inode sendiri yang menunjuk ke yang pertama.

$ touch foo
$ ln -s foo foolink # Create symlink
$ ls -li foo foolink
55029 -rw-r--r-- 1 bsd users 0 2011-12-11 09:11 foo
55033 lrwxrwxrwx 1 bsd users 3 2011-12-11 09:11 foolink -> foo

Jika saya mengedit foo atau bodoh, masih ada hanya satu file dan itu akan diperbarui.

Jika saya hanya menghapus symlink, inode dan data akan tetap ada. Jika saya menghapus foo, data akan hilang, symlink akan tetap ada tetapi mengarah ke file yang tidak ada.

$ rm foo
removed `foo'
$ ls -l foo foolink 
ls: cannot access foo: No such file or directory
lrwxrwxrwx 1 bsd bsd 3 2011-12-11 09:11 foolink -> foo

1
Tapi apa gunanya kasus praktis ini?
ewwhite

1
Satu penggunaan, sama dengan "jalan pintas" Penggunaan lain, memiliki beberapa versi aplikasi pada suatu sistem memungkinkan seseorang untuk menginstal, menguji versi baru, menentukan aplikasi dengan jalur penuh, sementara symlink di bin menunjuk ke produksi. Setelah pengujian selesai, ubah symlink ke versi baru, biarkan versi lama tetap ada untuk setiap pengguna yang memiliki kode versi ketergantungan. Pikirkan perl, python, dll.
bsd

1
kasus penggunaan praktis untuk tautan keras. Saat ini di sistem file saya, saya menemukan sejumlah besar hardlink di / usr / share / zoneinfo Pikirkan semua file bernama yang mewakili zona waktu, yang semuanya identik dengan EST. Kami menghemat ruang sistem file dengan tidak memiliki salinan yang berlebihan dan memungkinkan manajemen paket yang lebih mudah tanpa menginstal / menghapus overhead manajemen symlink karena paket diinstal / dihapus. Bahkan jika ada yang dihapus, data asli tetap dipertahankan. Maaf saya tidak punya waktu untuk penjelasan yang lebih bagus.
bsd

1

Tautan keras adalah entri direktori tambahan untuk file yang sama. Itu berarti

  • Semua tautan keras ke file harus berada di sistem file yang sama (karena entri direktori tidak dapat mengarah ke file di sistem file yang berbeda), tetapi tidak harus di direktori yang sama.
  • Tidak ada perbedaan antara entri direktori asli dan tautan keras baru; dari tampilan sistem operasi, mereka hanya dua entri direktori ke file yang sama. File hanya dihapus jika semua tautan keras dihapus (dan selain itu, tidak ada proses yang tersisa yang memiliki file itu masih terbuka).
  • Jika Anda memindahkan / mengganti nama "asli", selama Anda tidak memindahkannya ke sistem file lain, tautan keras lainnya tidak akan terpengaruh; mereka masih menunjuk ke file yang sama.
  • Banyak editor tidak menulis konten baru ke file yang sama saat menyimpan, tetapi lakukan prosedur berikut:

    1. Tulis konten baru ke file baru .
    2. Ubah nama file lama menjadi nama cadangan (atau, jika tidak menyimpan cadangan dari versi file sebelumnya, cukup hapus saja).
    3. Ganti nama file yang baru ditulis dengan nama file sebelumnya.

    Skema ini berarti bahwa setiap tautan keras lain ke file yang sama sekarang tidak lagi mengarah ke file saat ini, tetapi ke versi sebelumnya (ini benar bahkan jika seandainya editor menghapus file lama, karena di bawah Unix, "menghapus" file hanya berarti menghapus tautannya; hanya jika tautan yang dihapus adalah satu-satunya tautan, file yang sebenarnya akan dihapus).

  • Karena tautan keras langsung menuju ke file, Anda dapat mengakses file itu bahkan jika Anda tidak memiliki akses ke lokasi asli file itu (misalnya karena Anda tidak memiliki izin pada direktori tempat entri aslinya) . Satu-satunya hak menentukan akses Anda adalah hak akses dari file itu sendiri (yang terkait dengan file, bukan dengan tautan; Anda tidak dapat membuat tautan keras dengan izin berbeda untuk file yang sama) dan hak akses untuk jalur tautan keras tersebut terkandung dalam (pada dasarnya, hak eksekusi direktori tempat tautan berada, dan direktori induk langsung dan tidak langsung).

Tautan simbolik, di sisi lain, menyimpan pathname (nama ke file - atau lebih tepatnya entri direktori - berpotensi menyertakan path-nya, seperti /bin/shatau subdir/foo.bar) - dari file lain. Jika pathname itu relatif, selalu diartikan relatif terhadap direktori yang berisi tautan. Itu berarti:

  • Tautan simbolis dapat merujuk ke file pada sistem file yang berbeda (bahkan ke sistem file yang tidak dengan sendirinya mendukung tautan keras atau lunak, seperti FAT).

  • Jika file asli dihapus, tautan simbolis tidak mempertahankan konten file. Kecuali ada tautan keras lain ke file yang sama, konten file akan hilang. Tautan simbolis kemudian akan dibiarkan menggantung (yaitu, merujuk pada nama path yang tidak sesuai dengan entri direktori). Di sisi lain, menghapus tautan simbolik tidak memengaruhi file asli, karena itu hanya merujuk pada pathname-nya.

  • Jika file asli dipindahkan atau diganti namanya, tautan simbolik tidak diperbarui, tetapi dibiarkan menggantung. Jika Anda memindahkan tautan simbolik, tautan itu hanya akan rusak jika berisi jalur relatif, dan jalur tersebut tidak lagi valid dari posisi baru.

  • Jika file asli diganti dengan file baru dengan nama yang sama (seperti dalam skenario editor yang dijelaskan di atas), tautan merujuk ke file baru.

Sebagian besar penggunaan tautan keras pada dasarnya adalah cara untuk memiliki salinan file tanpa harus menyimpan konten file dua kali. Ini berfungsi paling baik jika file tidak pernah diubah lagi, karena jika tidak mudah memutus tautan secara tidak sengaja (lihat skenario editor di atas). Tentu saja ada kasus di mana Anda ingin tautannya diputus, seperti dalam kasus menyimpan beberapa cadangan: Untuk file yang telah berubah dalam cadangan yang lebih baru, Anda tidak ingin salinan di cadangan yang lebih lama juga berubah.

Biasanya jika Anda menginginkan tautan, Anda akan menggunakan tautan simbolik. Salah satu contohnya adalah ketika Anda memindahkan direktori ke partisi lain (karena partisi itu sudah penuh), Anda dapat mengatur tautan lunak dari posisi lama ke yang baru, sehingga setiap program yang mencoba mengakses direktori di tempat lama akan akses saja di tempat baru. Ini tidak mungkin dengan tautan keras. Namun perlu diketahui bahwa tautan simbolik di direktori yang dipindahkan dapat rusak jika mengandung jalur relatif yang mengarah keluar dari direktori yang dipindahkan.


1

HARD LINK (Only Files) vs SOFT LINK (Files atau Directories) vs BIND (HARD LINK for Directories)

LIHAT GAMBAR INI SEBELUM MEMBACA POS
(sumber: freesoftwareservers.com )

Sementara jawaban daxelrod menjelaskan pertanyaan dengan baik, saya berpikir bahwa gambar dalam kasus ini membuat perbedaan besar, terutama bagi pemula yang belum memahami inode dan jargon Linux yang rumit.

Pikirkan ini, jika Anda "menghapus" semuanya dari drive Anda, Anda dapat menjalankan perangkat lunak untuk mengembalikan data, karena angka 1 dan 0 masih ada di sana, Anda baru saja menghapus semua Tautan Keras. Tujuan Perangkat Lunak Pemulihan adalah untuk membangun kembali Hard Links untuk memahami 0 dan 1

Saya membaca "one liner" yang hebat yang membuat semua ini masuk akal dan saya ingin berbagi!

Semua file di Linux adalah "Tautan Keras" ke 0 dan 1 pada disk. Saat Anda membuat data (0 & 1), OS membuat Hard Link di Pohon File untuk referensi tempat itu di hard disk.

Buat HARD LINK 2 dan hapus HARD LINK 1 File Asli :

Anda dapat membuat tautan keras lain dan menghapus file asli, dan Anda masih memiliki akses ke tautan keras yang baru dibuat.

Hapus FILE (HARD LINK 1) yang SOFT LINKed ke:

Jika Anda menghapus HARD LINK 1, menurut Anda apakah SOFT LINK akan berfungsi? Tidak, OS akan melaporkan kembali bahwa HARD LINK 1 tidak ada.

Hapus SOFT LINK ke HARD LINK:

Sebaliknya, jika Anda menghapus LINK LEMBUT, apakah HARD LINK akan berfungsi? Iya. Selama OS memiliki satu File KERAS KERAS akan melaporkan bahwa isi belum dihapus.

- Juga layak untuk diteliti / diperhatikan adalah BIND, cara untuk BIND dua direktori seperti menghubungkan dua direktori, tetapi transparan untuk OS (OS dapat mengetahui kapan Anda Symlink dan beberapa memiliki aturan mengenai cuaca mereka dapat mengikuti Symlinks). Ini menggunakan Mount, bukan LS dan dapat dikonfigurasi melalui FSTAB.

Apa itu BIND mount


1
Itu upaya yang cukup ambisius, terutama untuk posting pertama. Sayangnya, saya percaya bahwa menambahkan materi pada "bind" (yang tidak diminta) hanya membingungkan; terutama karena Anda tampaknya tidak melakukan banyak upaya untuk menjelaskan pemasangan "bind". Juga, saya memahami tautan simbolik yang keras dan lunak / sangat baik, dan saya hampir tidak memahami gambar Anda. Saya akan sangat terkejut jika seorang pemula dapat belajar sesuatu darinya.
G-Man Mengatakan 'Reinstate Monica'

Meskipun Anda dapat symlink direktori, itu terlihat di sistem file sebagai symlink, jika Anda BIND, itu transparan untuk OS. Ditampilkan seperti file.
FreeSoftwareServers

1
(1) Sebenarnya, pada setidaknya beberapa versi Linux, Anda dapat mengikat mount file. (2) Sementara bind mounts terlihat sangat mirip dengan tautan keras, mengatakan "Bind sama saja dengan tautan keras (kecuali Anda tidak dapat menghubungkan tautan ke direktori)" salah.
G-Man Mengatakan 'Reinstate Monica'

@ G-Man, setuju dan dihapus, hanya dengan catatan yang menyebutkan BIND
FreeSoftwareServers

@Gratis sebenarnya tautan lunak menunjuk ke nama file (hard link 1); skema, harus membuat ini jelas.
JB.

0

Tautan keras akan menyimpan file di disk hingga semua tautan keras, bahkan yang pertama ("nama file" secara teknis merupakan tautan keras), telah dihapus. Tautan lunak dapat dibiarkan "menggantung" hingga file yang ditunjuknya diganti.


0

Ini adalah pertanyaan yang sangat lama tetapi saya memiliki kasus penggunaan yang mengharuskan saya untuk menggunakan tautan keras.

Saya seorang musisi dan jadi saya memiliki banyak dan banyak file audio dari berbagai jenis pada beberapa hard drive yang terpasang pada Mac saya. Nilai terabyte. Saya memilikinya sebagian besar diatur dengan sangat baik dengan direktori symlink sehingga saya dapat menemukannya oleh penerbit konten, gaya / suara, dan kriteria lain berdasarkan pada bagaimana saya berpikir pada saat itu. Sayangnya satu program yang saya gunakan, Ableton Live, benar-benar tidak dapat melihat alias atau symlink dari browser file-nya. Satu-satunya solusi yang saya temukan adalah membuat tautan keras dari direktori yang saya inginkan agar dapat melihatnya, dan kemudian semuanya bekerja dengan baik.

Jadi, ini adalah kasus lain ketika Anda mungkin perlu menggunakan tautan keras, yang mungkin tidak terjadi pada orang lain.


Saya akan mengajukan laporan bug untuk Ableton Live. Mungkin mereka bisa memperbaikinya.
aventurin

Ya sudah ada banyak keluhan tentang masalah ini di forum abletons selama bertahun-tahun ... Mereka tampaknya tidak melakukan upaya untuk mengatasinya meskipun saya tidak tahu mengapa tidak.
Jonathan van Clute
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.