왜 Linux에 마운트해야합니까?


67

Linux에 마운트가 무엇인지 이해하고 장치 파일을 이해합니다. 그러나 왜 우리가 마운트해야하는지 이해하지 못합니다.

예를 들어, 다음 명령을 사용하여이 질문에 대한 대답에 설명 된대로 :

mount /dev/cdrom /media/cdrom

우리는 CDROM 장치를 마운트 /media/cdrom하고 결국 다음 명령으로 CDROM 파일에 액세스 할 수 있습니다

ls /media/cdrom

CDROM의 내용이 나열됩니다.

왜 마운트를 완전히 건너 뛰고 다음을 수행하지 않습니까?

ls /dev/cdrom

그리고 CDROM의 내용을 나열하십시오. 나는 " 리눅스가 어떻게 설계 되었는가? " 그러나 그렇다면 왜 그렇게 설계 되었습니까? 왜 /dev/cdrom디렉토리에 직접 액세스하지 않습니까? 장착의 실제 목적은 무엇입니까?



23
거의 모든 운영 체제가 "마운트"됩니다. 대부분의 경우 투명합니다. Windows에서 pendrive에 대해 "안전하게 제거"를 선택하면 시스템에서 자동으로 마운트 한 후 실제로 umount를 수행합니다. 리눅스는 사용자를 프로세스에서 멀리 격리시키지 않으므로 결과적으로 사용자 정의 할 수 있습니다. umsdos 파티션은 vfat와 눈에 띄는 방식이 다르지 않지만 mount -t umsdos마운트하는 데 사용 하면, 모든 Linux 권한, 소유권, 특수 파일, fifo 등이 있습니다 mount -t vfat. 일반 Windows 파티션처럼 동작합니다.
SF.


7
"리눅스에 마운트가 무엇인지 이해하고 장치 파일을 이해합니다." 분명히;)
궤도에서 가벼움 경주

5
Why not access the /dev/cdrom directory directly?디렉토리가 아니기 때문입니다.
Brandon

답변:


67

한 가지 이유는 블록 레벨 액세스가 ls작업 할 수있는 것 보다 약간 낮은 레벨이기 때문 입니다. /dev/cdrom또는 dev/sda1CD-ROM 드라이브 및 하드 드라이브의 파티션 1 일 수도 있지만 ISO 9660 / ext4를 구현하지는 않습니다 . 장치 파일 이라고하는 장치에 대한 RAW 포인터 일뿐 입니다.

마운트가 결정하는 것 중 하나는 원시 액세스를 사용하는 방법입니다-파일 시스템 논리 / 드라이버 / 커널 모듈이 읽기 / 쓰기를 관리하거나 읽을 ls /mnt/cdrom블록으로 변환 할 내용 및 해당 내용을 해석하는 방법 같은 것들로 차단합니다 file.txt.

다른 경우에는이 낮은 수준의 액세스로 충분할 수 있습니다. 방금 직렬 포트, USB 장치, tty 터미널 및 기타 비교적 간단한 장치에서 읽고 썼습니다. 나는 기본적으로 ext4 로직을 다시 구현해야하기 때문에 / dev / sda1에서 수동으로 텍스트 파일을 읽거나 쓰려고 시도하지 않을 것입니다. 스토리지 블록, 전체 블록 읽기, 변경, 전체 블록 쓰기, inode 업데이트 (아마도) 또는 저널에이 모든 것을 쓰기가 너무 어렵습니다.

이것을 직접 보는 한 가지 방법은 시도해 보는 것입니다.

[root@ArchHP dev]# cd /dev/sda1
bash: cd: /dev/sda1: Not a directory

/dev디렉토리, 당신은 할 수 cdls모든 당신이 좋아한다. /dev/sda1디렉토리가 아닙니다. 커널이 해당 장치에 대한 '핸들링'으로 제공하는 특별한 유형의 파일입니다.

보다 심층적 인 처리 방법 은 장치 파일의 wikipedia 항목을 참조하십시오 .


4
나는 / dev / sda1에 저장된 데이터에 쓰기를 시작하면 나쁜 일 이 일어날 것이라고 생각하기 때문에 세부 사항에 대해 글을 쓰고 있습니다. 따라서 물건을 덮어 쓰지 못하게하는 예방 조치 또는 추상화가 있다고 가정합니다. 그러나 요약하자면 디스크에 쓰는 방법과 위치를 정확히 알고 있다면 수동으로 디스크를 작성할 수 있습니다 /dev/sda1. 일부 도구는 swapon/swapoff및과 같은 원시 디스크와 직접 상호 작용합니다 dd.
Ehryk

4
조금만 더 추가하면 마운트하면 파일 시스템이 초기화되므로 사용자에게 투명한 입 / 출력 작업의 전체 자동 처리 계층 (예 : RAM에 파일 캐싱, 작업 큐잉, 열린 파일 상태 유지)을 활성화합니다 등등). 그렇기 때문에 파일 시스템을 마운트 해제해야 손상을 피할 수 있습니다 (또는 최소한 동기화). 마운팅은 리눅스뿐만 아니라 일반적으로 사용되는 모든 플랫폼에 존재합니다. 데스크탑 환경 (KDE 또는 gnome)에서 마운트를 자동으로 처리하는 경우 MS 창에서와 같이 숨겨집니다.
오리온

6
@Ehryk (3 코멘트까지) 일반적인 Linux 시스템에서 유일한 예방 조치는 파일 시스템 권한입니다. 즉, 루트 계정을 사용하여 장치 파일에 기록해야합니다. 그렇게한다면 cat >/dev/sda1마음의 내용을 담을 수 있고 리눅스는 당신을 막을 수 없습니다. 말할 필요도없이 파일 시스템이 완전히 손상 될 수 있습니다.
David Z

5
@psusi Windows 95에서는 그렇게 할 수 없었습니다. 그러나 MS DOS 및 Windows NT에는 존재하고 숨겨져있었습니다. 최신 NT 기반 Windows에서는 확실하게 파티션을 원하는대로 마운트 및 마운트 해제 할 수 있습니다 (다른 파티션의 폴더 및 여러 폴더에 동시에). 일반적으로 기본적으로 알 수없는 모든 파티션을 마운트하여 문자를 구동합니다. 전체 경로를 사용하여 마운트하지 않고 장치에 액세스 할 수도 있습니다 (유닉스 방식과 매우 유사). 만약 잠겨 있지 않은 경우에만-물론 현재 마운트되어있는 경우입니다.
Luaan

3
@Luaan & psusi Psusi는 그 권리를 가지고 있습니다. 그러나 거의 모든 의도와 목적을 위해 Win32 API 호출자의 효과는 기본적으로 동일합니다. (Posix 호환을 위해서는 마운트 시맨틱의 에뮬레이션도 있습니다.) Win9x는 여전히 DOS 위에서 실행되기 때문에 마운트 개념을 가지고 있습니다. FAT 지원은 NT 커널이 처리하는 방식과 다소 유사한 기본 처리기로 DOS에 내장되었습니다. 그러나 CDROM과 네트워크 파일 시스템을 마운트해야했습니다. (CD 용 MSCDEX를 기억하십시오. ISO / RockRidge 파일 시스템 핸들러를 제공하여 드라이브 문자에 마운트했습니다.)
Tonny

20

기본적으로 운영 체제는 간단히 말해서 해당 장치의 파일에 액세스하는 방법을 알아야합니다.

mount "파일에 대한 액세스 권한 부여"일뿐만 아니라 드라이브에있는 파일 시스템 (읽기 전용 또는 읽기 / 쓰기 액세스 여부 등)을 OS에 알려줍니다.

/dev/cdrom저수준 장치이며 운영 체제 기능은 액세스 방법을 알 수 없습니다 ... 이상하게 포맷 된 cdrom (오디오 CD 포함)을 넣고 ls어떤 파일 (있는 경우)이 있는지 알 수 있습니다 CD-ROM을 먼저 "마운팅"하지 않습니까?

이는 많은 OS에서 (일부 배포판 및 그래픽 인터페이스의 Linux조차도) 자동으로 발생하지만 다른 OS가 드라이브를 "마운트"하지 않는 것은 아닙니다.


8

일관성을 위해

시스템의 첫 번째 하드 드라이브에 파티션이 있다고 가정하십시오. 예를 들면 다음과 같습니다 /dev/sda2. 나중에 드라이브가 충분히 크지 않다고 판단하여 두 번째 드라이브를 구입하여 시스템에 추가하십시오. 갑자기, /dev/sda그리고 현재 드라이브가됩니다 /dev/sdb. 이제 파티션이되었습니다 /dev/sdb2.

제안 된 시스템을 사용하면 이전 파티션의 데이터에 액세스하는 모든 스크립트, 응용 프로그램, 설정 등을 변경하여 이름을 변경해야합니다.

그러나 마운트하면이 이름이 바뀐 드라이브에 대해 동일한 마운트 포인트를 계속 사용할 수 있습니다. 당신은 수정해야 할 것 /etc/fstab(예) 시스템 말해 /media/backup지금 /dev/sdb2대신을, 그러나 그것은 단지 하나의 편집이다.

현대의 시스템은 훨씬 쉽습니다. 장치를 /dev/sda2또는 로 참조하는 대신 /dev/sdb2, 장착 할 때 장치를 참조하는 데 사용할 수있는 레이블과 UUIDS유사 c5845b43-fe98-499a-bf31-4eccae14261b하거나 친숙한 레이블 backup을 지정할 수 있습니다. 이런 식으로 새 장치를 추가 할 때 장치 이름이 변경되지 않아 관리가 훨씬 간단 해집니다.

# mount LABEL="backup" /media/backup

안전을 위해

관리자는 장치를 마운트해야하므로 장치에 대한 액세스를 제어 할 수 있습니다. 장치를 마운트 해제하면 제거 할 수 있지만 사용 중일 때는 제거 할 수 없습니다 (데이터 손실이 발생하지 않는 한). Windows 사용자 인 경우 알림 영역에서 USB 스틱을 제거해도 안전하다는 작은 녹색 아이콘을 기억하십니까? 그것은 스틱을 장착하고 마운트 해제하는 Windows입니다. 따라서 원칙은 단순한 유닉스 / 리눅스가 아닙니다.


범용 ID는 실제로 Microsoft의 GUID가 아닌 UUID입니다.
Ruslan

@Ruslan-그래서 그들은! 당시 MS 헤드를 사용했습니다. 많은 감사합니다-변경했습니다.
garethTheRed

6

나는 그것을 역사적인 이유라고 부릅니다. 다른 답변이 틀린 것은 아니지만 이야기에는 조금 더 있습니다.

Windows 비교 : Windows는 단일 컴퓨터, 단일 사용자 OS로 시작되었습니다. 그 단일 컴퓨터에는 아마도 하나의 플로피 드라이브와 하나의 하드 드라이브, 네트워크 연결, USB도없고 아무것도 없었을 것입니다. (Windows 3.11에는 기본 네트워킹 기능이 있었지만 Windows 3.1에는 없습니다 .)

Windows가 탄생 한 설정의 종류는 너무나 단순해서 화려할 필요가 없었습니다. 매번 모든 장치 (두 장치 모두)를 자동으로 마운트하면 잘못 될 수있는 것이 많지 않습니다.

반대로 Unix는 처음부터 여러 사용자가있는 서버 네트워크에서 실행되도록 만들어졌습니다.

Unix 디자인 결정 중 하나는 파일 시스템이 실제 디스크가 몇 대의 컴퓨터에 분산되어 있는지, 어떤 종류의 디스크에 관계없이, 수십 대의 컴퓨터에 관계없이 최종 사용자에게 단일의 단일 엔티티로 표시되어야한다는 것입니다. 사용자가 액세스 할 수 있습니다. 서버 유지 관리 등으로 인해 파일의 물리적 위치가 밤새 변경 되더라도 사용자 파일의 논리적 경로는 동일하게 유지됩니다.

그들은 파일을 저장 한 물리적 장치에서 논리적 파일 시스템, 파일 경로를 추상화하고있었습니다. 서버 A가 일반적으로 / home을 호스팅한다고 말하지만 서버 A는 유지 관리가 필요합니다. 서버 A를 마운트 해제하고 대신 백업 서버 B를 / home에 마운트하면 관리자 외에는 아무도 알 수 없습니다.
(유닉스가 추구 한 투명성에 맞지 않는 다른 물리적 장치 (C :, D : 등)에 다른 이름을 부여하는 Windows 규칙과 달리)

그런 종류의 환경에서는 모든 것을 시인 할 수는 없습니다.

대규모 네트워크에서는 개별 디스크와 컴퓨터가 지속적으로 작동하지 않습니다. 관리자는 필요한 장소와 다른 컴퓨터가 투명하게 동일한 파일을 호스팅을 인수하면서 하나의 컴퓨터의 제어 된 종료를 수행하는 예를 들어, 장착 무슨 말을 할 수있는 능력을.

그렇기 때문에 역사적 관점에서 Windows와 Unix는 서로 다른 배경에서 나왔습니다. 원하는 경우 문화적 차이라고 할 수 있습니다.

  • 유닉스는 관리자가 마운트를 제어해야하는 환경에서 태어났다. 관리자는 네트워크에있는 수십 개의 저장 장치 중 어디에서 언제 마운트 할 것인지 결정해야합니다.
  • Windows는 관리자가없고 두 개의 저장 장치 만있는 환경에서 태어 났으며 사용자는 파일이 플로피 파일인지 하드 드라이브에 있는지 알 것입니다.
  • (리눅스는 물론 단일 컴퓨터 OS로 태어 났지만, 처음부터 유닉스를 가정 컴퓨터에서 최대한 가깝게 모방하도록 명시 적으로 설계되었습니다.)

최근에 OS는 서로 더 가까이 다가 가고 있습니다.

  • 리눅스는 더 많은 단일 컴퓨터, 단일 사용자 물건 (자동 마운팅과 같은)을 추가했다; 단일 컴퓨터 설정에서 자주 사용되기 때문입니다.
  • Windows는 더 많은 보안, 네트워킹, 여러 사용자 지원 등을 추가했습니다. 네트워킹이 더욱 보편화되면서 Microsoft는 서버용 OS도 만들기 시작했습니다.

그러나 두 가지가 다른 전통의 결과라고 말하기는 여전히 쉽습니다.


1
그 뿐만이 아닙니다. 장치는 파일 시스템 드라이버 (및 기타 시스템 소프트웨어)가 사용할 수있는 저수준 추상화입니다. 유닉스는 운영 체제 프로그래머를위한 운영 체제로 설계되었습니다. 예를 들어, 해당 파일 시스템 드라이버의 프로그래머. 이것이 저수준 추상화가 사용자에게 노출되는 이유입니다.
reinierpost

5

현재 배열에는 몇 가지 장점이 있습니다. 블록 특수 파일의 장점과 마운트 지점의 장점으로 그룹화 할 수 있습니다.

특수 파일은 장치를 나타내는 파일입니다. 유닉스가 만들어 낸 아이디어 중 하나는 모든 것입니다. 예를 들어, 사용자 상호 작용은 문자 특수 파일 인 tty 장치에서 파일을 읽고 쓰는 것입니다. 마찬가지로 불량 블록 검사, 디스크 파티션 또는 포맷은 파일 작업입니다. 디스크가 mfm, ide, scsi, fiberchanel 또는 다른 파일 인 경우에는 문제가되지 않습니다.

그러나 다른 한편으로는 전체 디스크를 처리하거나 파일 만 파티션하지 않고 디스크에 들어갈 수있는 것보다 많은 파일을 원할 수도 있습니다. 마운트 포인트가 있습니다. 마운트 지점을 사용하면 디렉토리에 전체 디스크 (또는 파티션)를 넣을 수 있습니다. 좋은 크기의 하드 디스크가 수백 MB 인 슬랙웨어 시절에 CD를 / usr로 사용하고 하드 디스크를 /, / usr / local 및 스왑에 사용하는 것이 일반적이었습니다. 또는 한 드라이브에 /를 넣고 다른 드라이브에 / home을 넣을 수 있습니다.

이제 CD-ROM 드라이브가 하나 뿐인 컴퓨터에 편리한 / media / cdrom에 CD를 마운트하는 것을 언급했지만 둘 이상의 CD를 가지고 있다면 어떨까요? 두 번째를 어디에 마운트해야합니까? 아니면 세번째? 아니면 15 일? / media / cdrom2 등을 확실히 사용할 수도 있습니다. 또는 / src / samba / resources / windows-install 또는 / var / www에 마운트 할 수도 있습니다.


OP는 전체를 건너 뛰지 않고 직접 mount상호 작용 하는 이유를 의미한다고 생각합니다. /dev/cd0, /dev/cd2, /dev/sda1, /dev/sda2각각 이미 지정된 '디렉토리'가 있습니다.
Ehryk

1
정확하지만 / dev / sdb9 / share / doc / package / README가 좋은 경로라고 생각하십니까? 심지어 d : / share / doc / package / README가 더 좋지만 / usr / share / doc / package / README에는 의미가 있습니다! 이것이 마운트 포인트의 값입니다.
5

3
시맨틱 사용법이 나중에 '디렉토리 시스템과 장치에 대한 원시 파일 포인터 사이에 일부 코드를 넣을 필요'의 유용한 부산물로 나온 것으로 의심됩니다. 왜냐하면 cd / ls / nano /를 사용하면 원시보다 훨씬 쉽습니다. 씁니다 : dd if=/file of=/dev/sda2 bs=4096 skip=382765832 count=84756관련 inode / FAT / 저널 업데이트는 물론입니다.
Ehryk

(일부 리눅스 마조히스트들은 아마도 / dev / sdb9를 작업 디렉토리로 좋아할 것이다.)
Ehryk

2
첫 번째 컴퓨터는 2 8 인치 플로피에서 cp / m을 실행했습니다. 하위 디렉토리는 전혀 지원하지 않았습니다. 디스크 당 하나의 디렉토리. 경로는 b : name.ext와 같았습니다. 시맨틱 이름 지정이라는 아이디어는 이미 확립되었습니다. 테이프 시스템도 UNIX는 이미 마운트 지점에 대한 드라이브 문자에 대한 아이디어를 거부했습니다. @ Ehryk, Windows뿐 아니라 dos에도 디렉토리에 드라이브를 마운트 할 수 있다는 것을 알고 있습니까? MS-DOS 5에서 수행했습니다. .. 내가 man 페이지를 찾고있을 때 게다가, 나는 운전하는 훨씬에 컴퓨터를 기억하고 싶지 않습니다
hildred

5

질문 제목은 다음과 같이 묻습니다. 왜 Linux에 마운트해야합니까?

이 질문을 해석하는 한 가지 방법 : Linux에서 파일 시스템을 사용 가능하게하려면 명시적인 mount명령을 실행 해야하는 이유는 무엇 입니까?

답은 없습니다.

파일 시스템을 명시 적으로 마운트 할 필요는 없으며 자동으로 파일 시스템을 정리할 수 있으며 Linux 배포는 Windows 및 Mac과 마찬가지로 대부분의 장치에서 이미이 작업을 수행합니다.

그래서 그것은 아마도 당신이 요구하려는 것이 아닐 것입니다.

두 번째 해석 : 왜 우리가 때로는 명시 적으로 실행할 필요가 mount리눅스 파일 시스템을 사용할 수 있도록 명령을? 왜 운영 체제가 항상 우리를 위해 그것을하고 사용자에게 숨길 수 있습니까?

이것은 질문 할 때 질문 텍스트에서 읽고있는 질문입니다.

마운팅을 건너 뛰지 말고 다음을 수행하십시오.

ls /dev/cdrom

CD-ROM의 내용이 나열되어 있습니까?

아마도, 당신은 의미 : 왜 그 명령이 무엇을합니까?

ls /media/cdrom

지금?

이 경우 /dev/cdrom장치 파일이 아닌 디렉토리 트리가됩니다. 실제 질문은 다음과 같습니다. 왜 장치 파일이 처음에 있습니까?

이미 주어진 것에 대한 답변을 추가하고 싶습니다.

사용자가 장치 파일을 보게되는 이유는 무엇입니까?

CD-ROM 또는 파일을 저장하는 다른 장치를 사용할 때마다 CD-ROM의 내용을 파일의 디렉토리 트리로 해석하는 소프트웨어가 사용됩니다. lsCD-ROM의 파일에 액세스하는 다른 종류의 명령이나 응용 프로그램을 사용할 때마다 호출됩니다 . 해당 소프트웨어는 파일을 CD-ROM에 쓰는 데 사용되는 특정 파일 시스템의 파일 시스템 드라이버입니다. 파일 시스템에서 파일을 나열, 읽기 또는 쓰기 할 때마다 해당 장치에서 해당 하위 수준 읽기 및 쓰기 작업이 수행되도록하는 것이 해당 소프트웨어의 역할입니다. 당신이 때마다 mount파일 시스템, 시스템을 말하는중인 파일 시스템 드라이버 장치에 사용할 수 있습니다. 이 작업을 명시 적으로 수행하는지 여부mount명령을 수행하거나 자동으로 수행되도록 OS에 맡기려면 수행해야합니다. 물론 파일 시스템 드라이버 소프트웨어가 먼저 있어야합니다.

파일 시스템 드라이버는 어떻게 작동합니까? 답은 장치 파일을 읽고 쓰는 것입니다. 왜? 당신이 이미 언급했듯이 대답 : Unix는 이런 식으로 설계되었습니다. 유닉스에서 장치 파일은 장치에 대한 일반적인 저수준 추상화입니다. 특정 장치에 대한 실제 장치 별 소프트웨어 (장치 드라이버)는 장치 파일의 작업으로 장치에서 열기, 닫기, 읽기 및 쓰기를 구현해야합니다. 이렇게하면 파일 시스템 드라이버와 같은 고급 소프트웨어는 개별 장치의 내부 작동에 대해 많이 알 필요가 없습니다. 저수준 장치 드라이버와 파일 시스템 드라이버는 서로 인터페이스하는 일반적인 방법에 동의하는 한 다른 사람들이 개별적으로 작성할 수 있으며 장치 파일의 용도입니다.

따라서 파일 시스템 드라이버에는 장치 파일이 필요합니다.

그러나 왜 일반 사용자 인 경우 장치 파일을 볼 수 있습니까? 그 대답은 Unix는 운영 체제 프로그래머가 사용하도록 설계되었다는 것입니다. 사용자가 장치 드라이버 및 파일 시스템 드라이버를 작성할 수 있도록 설계되었습니다. 그것이 실제로 어떻게 쓰여지 는가입니다.

Linux의 경우에도 마찬가지입니다. 고유 한 파일 시스템 드라이버 (또는 장치 드라이버)를 작성하여 설치 한 다음 사용할 수 있습니다. 리눅스 (또는 다른 유닉스 변형)를 쉽게 확장 할 수있게한다 (그리고 실제로 리눅스가 시작된 이유) , 누군가 코드를 작성하여 지원하고 작동하게하고 Linux에 제공 할 수 있습니다.

장치 파일은 이것을 더 쉽게 만듭니다.


1
잘 설명
Shailendra


3

때문에 /dev/cdrom장치이며, 반면에 /media/cdromA는 파일 시스템 . CD-ROM의 파일에 액세스하려면 전자를 후자에 마운트해야합니다.

컴퓨터를 부팅 할 때 운영 체제가 이미 물리적 하드 디스크 장치에서 루트 및 사용자 파일 시스템을 자동으로 마운트하고 있습니다. 이것은 사용할 파일 시스템을 더 추가하는 것입니다.

모든 운영 체제에서이 작업을 수행하지만 Windows와 같이 CD-ROM을 마운트 할 때와 같은 일부 운영 체제 D:에서는 투명하게 수행합니다. 리눅스는 프로세스를 더 잘 제어 할 수있게 해줍니다.


2
나는 당신의 말에 동의하지 않습니다. /dev/cdrom장치 파일 (관련 장치와 쉽게 i / o 통신 할 수 있도록하는 특수 기능이 있음)입니다. /media/cdrom디렉토리이지만 기본적으로 다른 파일입니다 (디렉토리를 포함하여 모든 것이 Linux의 파일 임). 이제 우리 mount는 장치 파일의 내용을 파일 시스템으로 볼 수있는 특별한 능력을 갖게되었습니다. 마지막 문장에 대한 나의 이해는 위의 답변을 읽는 것입니다.
Greeso

@ 그리소 : 나는 내 대답을 기다립니다.
궤도에서 가벼움 경주

0

데스크톱 및 랩톱 UI 용 미디어가 많기 때문에 미디어 삽입시 수행해야 할 작업에 대한 모호성이 있기 때문에 사용자 직관은 사용자가 상호 작용하는 물리적 상자에 디스크를 삽입하는 것이 다르지 않기 때문입니다. 네트워크에 연결된 컴퓨터 옆의 장치에 삽입합니다.

따라서 기본적으로 미디어 UI는 두 가지 종류의 잠재적 마운트 이벤트를 유사하게 처리해야하며, 컴퓨터가 다른 UI를 사용하여 네트워크 마운트를 컴퓨터에 연결하는 것만 큼 직관적으로 네트워크 마운트를 처리 할 수있는 좋은 방법이 없습니다. 스마트 폰, 태블릿 및 웨어러블 컴퓨터와 같이 장치에 물리적 미디어를 삽입 할 가능성이 없습니다. (iPhone 인터페이스가 SIM 카드를 전환하는 데 얼마나 끔찍한 지 주목하십시오 .iOS 장치에 삽입 된 물리적 미디어의 한 종류입니다.

이 유형의 물리적 상자 (예 : Windows 98, Windows 8, Mac OS X v10.2 (Jaguar) 및 Mac OS X v10.9 (Mavericks))의 UI에 대한 다른 일반적인 접근 방식도 동일한 문제로 실행됩니다. 추가 GUI 대화 상자를 사용하여 혼동 가능성을 정리합니다 (예 : Windows 8은 일반적으로 파일 시스템, 음악 미디어 또는 적절한 경우 MP4 비디오 모음으로 마운트할지 여부에 관계없이 삽입 된 각 새 CD를 요구하도록 구성됩니다) ). Linux 또는 기타 UNIX에서 이러한 사용자 대화 상자를 사용할 수없는 이유는 없습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.