GNU/Linux >> Belajar Linux >  >> Linux

Beberapa folder dan/atau file di HDD eksternal dapat diakses di Linux tetapi tidak di macOS dan Windows

Saya memposting jawaban ini hanya untuk mengatakan bagaimana masalah diselesaikan, sehingga meringkas komentar yang dibuat untuk pertanyaan awal, yang mungkin berguna bagi orang lain.

Saya telah memperbaiki masalah di Linux, di mana folder tersebut telah dibuat, cukup dengan memperpendek judul dua atau tiga file video, yang memiliki nama panjang tetapi tidak ada karakter aneh seperti koma, tanda kurung, dll. Saya juga telah mengubah foldernya nama - meskipun tidak ada yang istimewa. Mengubahnya kembali tidak mereproduksi masalah.

Jadi, nama folder memiliki karakter yang salah yang tidak terlihat seperti itu di Linux, atau karakter buruk di beberapa dari tiga file yang diganti namanya membuat seluruh folder tidak terlihat di Mac dan semua isinya tidak dapat dimainkan di Windows.

Ini adalah hal yang paling aneh, sebelum mengganti nama folder dan ketiga file, tidak ada dari file dapat diputar di Windows.

Mungkin saja, seperti yang dikatakan @Giacomo1968 dalam komentar:

‘… karakter “hantu” dalam nama file asli… Sesuatu seperti carriage return atau non-breaking space yang ditangani dengan satu cara di Linux, tetapi tersendat di sistem lain.’

Masalahnya adalah sebelum memperbaiki masalah saya telah mencoba memutar di Windows file lain selain yang pada akhirnya diubah namanya. Karakter hantu mungkin juga ada di nama folder.

Itu terjadi pada saya lagi di drive baru yang diformat sebagai exFAT dengan file lain di folder yang melaporkan kesalahan di Linux oleh pengelola file Nemo selama penyalinan (sesuatu seperti "tidak dapat membuat file"), tetapi sebenarnya semuanya tampak baik-baik saja di Linux. Folder itu terlihat tetapi tetap tidak dapat diakses sepenuhnya di Windows (saya tidak ingat persis pesan kesalahannya, sesuatu tentang file atau folder tidak ada), dan itu terlihat di Mac, kecuali satu file tunggal, yang tetap tidak terlihat. Setelah mengganti nama folder dan file dengan nama yang sama di Linux semua berjalan normal!

Saya sekarang menduga bahwa penyebab masalah awal yang dilaporkan dalam pertanyaan, dan pembuatan karakter 'hantu' yang buruk, adalah beberapa kesalahan selama proses penyalinan atau menempelkan judul teks yang disalin dari halaman internet (di mana yang tampak seperti ruang, misalnya, sebenarnya adalah sesuatu yang lain). Ini disarankan kepada saya oleh fakta bahwa saat menyalin dengan Double Commander di Linux, ia melaporkan kesalahan mendetail pada beberapa nama yang menyertakan spasi yang mungkin merupakan karakter Tab atau yang serupa.

Pada akhirnya, solusi terbaik untuk menyalin adalah menggunakan Double Commander di Linux yang dengan sangat jelas menunjukkan nama file yang bermasalah.

Salin/tempel teks internet saat memberi nama file atau folder harus dilakukan dengan hati-hati.


Cara kerja nama file/folder di Windows dibahas di situs web Microsoft. Namun, itu hanya memberikan gambaran sekilas tentang kebenaran secara keseluruhan.

NB:Saya tidak membahas aspek masalah halaman kode yang dapat muncul dari cara sistem "asing" mengakses volume NTFS. Saya pikir ini cukup tercakup dalam komentar dan jawaban lainnya. Saya akan membatasi diri saya sebagian besar pada dua aspek berikut:

  • batasan panjang nama jalur
  • kombinasi karakter yang sulit/tidak mungkin diakses dari subsistem Win32

Adapun sistem file saya akan membatasi diri pada NTFS, seperti pertanyaannya. Pertimbangkan komentar berikut dari situs web tertaut di atas:

Jangan akhiri nama file atau direktori dengan spasi atau titik. Meskipun sistem file yang mendasari mungkin mendukung nama tersebut, shell Windows dan antarmuka pengguna tidak .

Sekarang, kita perlu meluruskan beberapa terminologi terlebih dahulu. Kami menangani berbagai ... lapisan, mungkin istilah yang cocok:

  • sistem file, mis. NTFS
  • Pengelola objek NT dan fasilitas kernel lainnya, tetapi jika menyangkut nama kebanyakan pengelola objek
    (jika Anda ingin melihatnya, gunakan alat seperti WinObj)
  • Subsistem Win32 (inilah yang disebut oleh pernyataan di atas sebagai "Windows shell dan antarmuka pengguna")
  • "Aspek meta" lainnya adalah versi OS, karena panjang jalur yang didukung dapat bervariasi

Metode yang bagus untuk bermain-main dengan ini adalah share Samba yang berpura-pura menjadi NTFS di sisi klien. Tetapi volume Windows NTFS juga bisa. Kami akan menggunakan Windows dan "bermain-main" dari baris perintah (tekan Menang +R dan ketik cmd , lalu tekan Enter ).

Volume NTFS lokal

Misalkan kita ingin membuat nama file yang tidak valid (perhatikan tanda titik?!):

echo NONSENSE > text.txt.

Saat mencoba ini, hasilnya memang akan menjadi test.txt , tidak test.txt. . Subsistem Win32 (csrss.exe) mencegah kami melakukan hal-hal bodoh. Hmm, menarik, ya?

Pertimbangkan pernyataan lain ini:

Jangan gunakan nama cadangan berikut untuk nama file:

CON , PRN , AUX , NUL , COM1 , COM2 , COM3 , COM4 , COM5 , COM6 , COM7 , COM8 , COM9 , LPT1 , LPT2 , LPT3 , LPT4 , LPT5 , LPT6 , LPT7 , LPT8 , dan LPT9 . Hindari juga nama-nama ini yang langsung diikuti dengan ekstensi; misalnya, NUL.txt tidak disarankan.

Hmm, NUL terdengar menyenangkan. Kita mengetahuinya dengan menjadi pengganti /dev/null pada sistem unixoid, diwarisi dari masa DOS.

echo NONSENSE > NUL

Oh, benar. Ini adalah pengganti /dev/null , sehingga output akan tertelan. Namun jangan gunakan terdengar sangat menggoda. Jadi, mari kita gunakan informasi ringkasan dari artikel blog Project Zero, bagian "Perangkat Lokal".

Selingan singkat:%CD%

Jika Anda tidak terlalu terbiasa dengan baris perintah Windows klasik (cmd.exe ), variabel khusus %CD% akan memberi kita jalur absolut ke direktori kerja saat ini. Ingatlah hal itu untuk bagian berikut. Jadi, jika saat ini Anda berada di dalam C:\test , perintah echo %CD% akan menghasilkan output C:\test . Ini adalah jalan pintas yang nyaman untuk eksperimen.

Seperti yang dapat kita peroleh dari artikel Project Zero, ada sejumlah cara untuk menghindari konversi nama jalur di tingkat subsistem Win32. Salah satu metode tersebut adalah awalan \\?\ yang secara internal langsung diterjemahkan menjadi \??\ , yang pada versi Windows yang lebih baru identik dengan \GLOBAL??\ . Ini disebut direktori objek (harap jangan tertukar dengan entitas sistem file , meskipun terminologinya serupa!). Sekali lagi, WinObj, dan alat serupa memungkinkan Anda menyelidiki ruang nama pengelola objek.

Selingan:ruang nama dan "barang" server terminal

Siapa pun yang pernah melihat riwayat Windows NT, dan Windows 10 melacak akarnya kembali ke NT, akan mengingat saat Anda harus melisensikan layanan terminal secara terpisah. Yaitu. kemampuan untuk terhubung ke satu mesin dari jarak jauh dengan pengguna yang berbeda.

Saya pikir itu adalah Windows XP yang membawa ini akhirnya untuk massa dengan memungkinkan untuk tetap masuk dengan beberapa akun pengguna secara bersamaan ("perpindahan pengguna"), dan mungkin Windows 2000 atau 2003 Server memasukkan ini dalam edisi standar, meskipun CAL diperlukan di luar "kursi" minimum yang disertakan secara default.

Disinilah perbedaan antara \?? dan \GLOBAL?? berasal. \GLOBAL?? adalah tampilan nama perangkat "DOS" yang dibagikan oleh semua sesi logon.

\?? saat ini terlihat di tautan simbolik (sekali lagi, bukan entitas sistem file! ) disebut \DosDevices , yang memberi petunjuk tentang asal-usulnya. Di sinilah nama perangkat "DOS", seperti C: atau pemetaan drive jaringan berada. Pada sistem modern C: pada gilirannya akan menjadi tautan simbolis ke \Device\HarddiskVolume1 (atau serupa). Itu kemudian biasanya aktual objek perangkat yang dibuat oleh beberapa driver di tumpukan driver penyimpanan, dalam hal ini harus menjadi driver sistem file NTFS.

Jadi saat Anda mengklik dua kali C:\Windows\explorer.exe apa yang terjadi secara internal adalah jalur dikonversi:

  • Pada level subsistem Win32, perubahan yang biasa dilakukan adalah menambahkan \??\ .
  • Pengelola objek kemudian akan meluaskan \??\C: .
    • Pertama \??\ berakhir di ruang nama perangkat "DOS" untuk sesi logon Anda (lihat komentar di bawah)
    • Akhirnya pengelola objek menemukan sesuatu seperti \??\C: setara dengan \GLOBAL??\C: yang - seperti yang kita lihat di atas - setara dengan \Device\HarddiskVolume1 .

Manajer objek kemudian akan meneruskan sisa jalur \Windows\explorer.exe kepada pengemudi yang bertanggung jawab atas objek perangkat \Device\HarddiskVolume1 , memastikan pengemudi mengetahui objek perangkat mana yang direferensikan. Dan pengemudi itu akan tahu bagaimana di dalam ruang namanya sendiri untuk menangani sisa jalur tertentu itu.

Catatan: Saat Anda merujuk ke \?? secara internal Anda berakhir dengan tampilan perangkat "DOS" sesi logon lokal Anda. Ini paling baik dijelaskan dengan drive jaringan yang dipetakan. Katakanlah Anda memiliki huruf drive X: dipetakan untuk berbagi jarak jauh. Dan katakanlah Anda menggunakan "pengalihan pengguna" atau ini berjalan di server terminal yang gemuk di mana dua ratus pengguna lainnya masuk secara bersamaan. Kami memiliki dua masalah dalam skenario seperti itu. Meskipun drive sistem (misalnya disk fisik) dapat digunakan bersama oleh semua orang, seseorang dari bagian penjualan mungkin telah memetakan "the pangsa penjualan" sebagai X: dan seseorang dari pengembangan mungkin telah memetakan "the bagian pengembangan". Hal yang sama berlaku untuk "huruf drive" yang ditetapkan melalui subst . Ini seharusnya menjelaskan mengapa tidak boleh ada satu ruang nama global untuk nama perangkat "DOS", yang cocok untuk semua orang.

Jadi tujuan kami adalah membuat file (atau direktori) bernama NUL dan subsistem Win32 tidak mengizinkan kami. Itu hanya menelan output dan file tidak pernah dibuat di direktori kerja kami. Memanfaatkan informasi dari artikel tertaut di atas dan selingan sebelumnya, bagaimanapun, kita dapat menyiasatinya dengan menghindari konversi jalur yang mengganggu tersebut di tingkat subsistem dengan menerbitkan:

echo NONSENSE > \\?\%CD%\NUL

Sebagai pengingat, %CD% memperluas ke jalur absolut dari direktori kerja saat ini dan, dengan asumsi itu adalah C:\test , perintah di atas setara dengan echo NONSENSE > \\?\C:\test\NUL .

Dan lihatlah, dir cepat membuktikan bahwa file telah dibuat. Dan jika kami mencobanya dengan nama "reserved" lainnya, itu juga berfungsi dengan baik.

Harap perhatikan bahwa Anda juga dapat menggunakan sebenarnya formulir jalur NT asli (\?? bukannya \\? ) untuk efek yang sama:

echo NONSENSE > \??\%CD%\NUL

Rapi.

Jadi bagaimana kalau kita meninjau kembali upaya trailing dot, tetapi memberikan path lengkap tanpa mengganggu subsistem Win32?:

echo ILLEGAL TRAILING DOT > \??\%CD%\test.txt.

Voila, itu berfungsi, sebagai dir /b cepat membuktikan:

C:\test>dir /b
CON
NUL
test.txt
test.txt.

Selingan:jalur UNC (Universal Naming Convention)

Topik ini ditangani secara lebih mendetail di artikel Project Zero tersebut, tetapi cukup dikatakan bahwa ada bentuk jalur khusus yang terlihat sangat mirip dengan yang baru saja kita gunakan di atas:\\.\C:\Windows\explorer.exe akan menjadi contoh.

Ingat bahwa setiap kali Anda terjebak di layar masuk, tidak mengingat nama mesin lokal dari mesin tersebut, dan defaultnya ke domain yang menjadi anggotanya? Satu cara mudah untuk merujuk ke mesin saat ini bahkan tanpa menggunakan nama aslinya adalah .\username , memungkinkan untuk mereferensikan pengguna username pada mesin saat ini .

. di \\.\C:\Windows\explorer.exe harus dipahami secara serupa. Sebenarnya apa yang Anda katakan adalah \\. pada mesin saat ini \C: pada drive C: jalur akses \Windows\explorer.exe ... dan berbagai fasilitas OS saling terkait untuk mewujudkannya.

Hati-hati :Jalur UNC mengikuti serangkaian aturan yang berbeda, itulah sebabnya saya hanya menyebutkannya. Baca artikel tertaut dan tautan ke dokumentasi Microsoft jika Anda tertarik dengan detail selengkapnya.

Sekarang kita akhirnya membuat file "tidak mungkin" test.txt. , mari kita lihat, oke?

C:\test>type test.txt
NONSENSE

Apa apaan? Saya ingat dengan jelas pernah mengulang ILLEGAL TRAILING DOT ke dalam file itu.

Ah, tentu saja. Sama seperti saat kami pertama kali mencoba membuat test.txt. subsistem Win32 campur tangan lagi dan "membantu" mengubah nama kami menjadi test.txt . Jadi kita sebenarnya melihat \??\%CD%\test.txt bukannya \??\%CD%\test.txt. .

Jadi ini harus dilakukan:

C:\test>type \??\%CD%\test.txt.
ILLEGAL TRAILING DOT

Jauh lebih baik. Masalahnya adalah tidak semua program akan menangani pengalihan nama jalur Win32 secara licik seperti cmd.exe . Misalkan kita ingin membuka Notepad:

C:\test>notepad \??\%CD%\test.txt.

Sial, kita bisa melihat kotak pesan berikut:

Jadi, meskipun ada cara untuk menghindari beberapa pembatasan yang diberlakukan oleh subsistem Win32, utilitas metode ini terbatas dan dipertanyakan.

Catatan :Pembaca yang juga berkembang perangkat lunak pada/untuk Windows mungkin ingat bahwa menggunakan awalan \\?\ diizinkan untuk menghindari MAX_PATH batas (dulu 260, pada dasarnya 255 plus \\?\ dan \0 terminasi ). Sekarang Anda tahu mengapa hal ini memungkinkan kami memanfaatkan kira-kira 32767 karakter. Karena UCS-2 diganti dengan UTF-16 (menurut saya di XP), jalan yang rusak di tingkat pengelola objek hanyalah satu masalah. Lain adalah bahwa dalam UTF-16 titik kode mungkin memakan waktu lebih dari 16 bit (alias wchar_t atau WCHAR ), setelah Anda meninggalkan BMP.

Bagaimanapun, baris perintah (cmd.exe ) memberi Anda semua alat untuk mengakses dan menghapus file yang dapat Anda buat dari Windows sejak awal.

Linux/Samba berbagi, berpura-pura menjadi NTFS

Mari sekarang berangkat dari drive lokal dan pertimbangkan drive jaringan yang dipetakan Z: , disediakan oleh Samba 4.x, yang meniru drive NTFS sejauh menyangkut Windows.

Eksperimen ini menawarkan beberapa wawasan lagi, karena kami dapat membuat file sesuai dengan aturan sisi Linux dan tidak perlu khawatir tidak dapat mengaksesnya dari sisi Windows.

  • Drive yang dipetakan adalah Z: dan kita akan berada di Z:\test di sisi Windows
  • Di sisi Linux, volume diformat sebagai btrfs
    Artikel Wikipedia memberi tahu kita semua karakter selain / dan \0 (alias karakter ASCII NUL) diperbolehkan! Jadi ini pasti menyenangkan.

Berikut adalah beberapa nama file mewah yang seharusnya (atau setidaknya bisa) sulit diakses di sisi Windows, menggunakan Bash di Ubuntu 20.04 di sisi Linux untuk membuatnya:

  • :.txt (dibuat dengan echo "$RANDOM" > \:.txt )
  • ???.txt (dibuat dengan echo "$RANDOM" > \?\?\?.txt )
  • .txt (dibuat dengan echo "$RANDOM" > .txt )
  • *.txt (dibuat dengan echo "$RANDOM" > \*.txt )
  • \.txt (dibuat dengan echo "$RANDOM" > \\.txt )
  • ".txt (dibuat dengan echo "$RANDOM" > \".txt )
  • >.txt (dibuat dengan echo "$RANDOM" > \>.txt )
  • <.txt (dibuat dengan echo "$RANDOM" > \<.txt )
  • |.txt (dibuat dengan echo "$RANDOM" > \|.txt )

Ini seharusnya mencakup semua basis, sebenarnya setelah dipikir-pikir emoji bahkan mungkin tidak menjadi masalah sama sekali. Garis miring ke depan juga dilarang di NTFS, tetapi itu juga berlaku untuk btrfs/POSIX/SUS.

Bukti dari sisi Linux:

$ find -type f -printf '%P\n'
:.txt
???.txt
.txt
*.txt
\.txt
".txt
>.txt
<.txt
|.txt

Sekarang mari kita lihat apakah dan apa yang dapat kita akses di sisi Windows ...

Z:\test>dir /b
_2X68P~X.TXT
_2X68Q~5.TXT
_2X68Q~9.TXT
_2X68Q~B.TXT
_2X68Q~D.TXT
_2X68R~7.TXT
_2X68S~3.TXT
_67V3K~2.TXT
.txt

Tangkapan layar sebagai bukti:

Ohhhhh! Benar, warisan DOS Windows menyerang lagi. NTFS - kecuali jika dinonaktifkan secara aktif - memiliki kemampuan untuk membuat apa yang disebut 8.3 nama file pendek, sesuai dengan persyaratan nama file DOS.

Dan begitulah cara kami dapat mengakses nama file yang tidak valid.

Kesimpulan

Sekarang ingat, pertanyaannya adalah tentang drive NTFS eksternal, yaitu lokal. Artinya, aturan yang baru saja kami amati untuk pembagian Samba mungkin tidak berlaku di sini.

Bergantung pada driver yang digunakan untuk menyimpan file-file ini (yang dapat bervariasi menurut versi Linux/macOS, misalnya ntfs-3g atau driver pihak ketiga yang digunakan, misalnya driver Paragon) Saya melihat kemungkinan penyebab berikut yang tersisa setelah melihat eksperimen di atas:

  1. nama file berisi : , " atau ? ... ini sepertinya yang paling mungkin bagi saya, mengingat saya sendiri secara tidak sengaja menyalin dan menempelkan judul ebook, yang berisi karakter ini. Kita dapat mengesampingkan / dan karakter "terlarang" lainnya setidaknya kecil kemungkinannya.
  2. sisi Windows dan macOS melihat nama yang tidak valid, coba lihat nama DOS 8.3, tetapi tidak ada yang dibuat. Ini agak tergantung pada versi Windows yang tepat dan konfigurasinya dan karena saya tidak memiliki perangkat macOS, saya juga tidak dapat menguji skenario itu. Juga, saya tidak yakin apakah pada sistem Windows di mana nama 8.3 diaktifkan Windows akan secara retroaktif pergi dan menghasilkan nama 8.3 jika, katakanlah, pihak Linux melewatkan bagian itu. Karena jika saya ingat dengan benar driver NTFS memutuskan apakah masing-masing catatan ("atribut") akan diisi.
  3. panjang nama jalur terlampaui. Menurut saya, melebihi panjang segmen jalur adalah suatu kemustahilan, karena NTFS tidak mengizinkan Anda menyimpan lebih dari 255 nilai 16-bit untuk segmen jalur, tetapi keseluruhan panjang jalur mungkin juga telah terlampaui (lihat tautan ini).

Untuk skenario pertama, saya akan merekomendasikan menggunakan fslint di sisi Linux untuk membersihkan nama file (dan folder). Ada alat serupa lainnya dan YMMV, pilihlah.

Semoga ini membantu. Butuh waktu cukup lama untuk menuangkan pikiran saya ke dalam tulisan.

Bacaan lebih lanjut

  • Memberi Nama File, Jalur, dan Ruang Nama
  • Panduan Pasti tentang Konversi Jalur Win32 ke NT

Linux
  1. Linux – Mengapa `/dev/ptmx` Dan `/dev/pts/ptmx` Bukan File Perangkat?

  2. Linux – Direktori Standar Dan/atau Umum Pada OS Unix/linux?

  3. Apa itu file jarang di Linux

  1. Cara mengekstrak file .gz dan .tar.gz di Linux

  2. Apa itu file /dev/zero dan /dev/null di Linux?

  3. Mengapa Windows tidak mengenali file di dalam partisi Linux?

  1. Cara Mengonfigurasi Server SAMBA Dan Mentransfer File Antara Linux &Windows

  2. Cara Enkripsi dan Dekripsi file/folder di Linux menggunakan GnuPG

  3. Linux – Setelah Fs Crash Dan Menjalankan Fsck, Beberapa File Dipulihkan Tapi Tidak Ditempatkan Di Lost+found?