첨부파일 외부 저장소 이동 (bsplus_external_storage)

팔공산 님이 v1.9.7의 재생성 버튼을 여러 번 눌러도 특정 글의 썸네일이 끝내 고쳐지지 않아 UPDATE xe_files SET thumbnail_filename = ''로 코어 컬럼을 직접 지워서 우회 — 이 방식은 실제로 원격 이전된(로컬 원본이 이미 없는) 파일에는 위험하지만, 이 리포트를 계기로 재생성 버튼의 진짜 결함을 발견함. 후보 조회 쿼리가 "이전됨 + 썸네일 있음"만 조건으로 걸었는데, 재생성에 성공해도 썸네일은 여전히 "있는" 상태라 이 조건에서 절대 빠지지 않아 매번 map_srl 오름차순 맨 앞 30건만 반복 처리하고 뒤에 있는 파일은 버튼을 아무리 눌러도 처리되지 않는 구조였음. thumb_fixed 컬럼을 추가해 재생성 성공한 항목을 표시하고 후보 조회에서 제외 — 이제 반복해서 누르면 뒤에 있는 파일들로 순서대로 넘어감.

v1.9.7까지의 크롭 여백 수정/재생성 도구로도 팔공산 님이 "이전 후 썸네일이 예전처럼 안 나온다"고 재차 리포트. 라이믹스 코어 구조상(document.item.php의 getThumbnail()) 화면에 보이는 썸네일은 항상 thumbnail_filename(이 모듈이 만든 로컬 미리보기)을 게시판 설정의 크롭 타입으로 다시 리사이즈한 결과라, "원본 파일 그 자체"가 그대로 표시되는 경로가 코어에 없다는 걸 확인 — 대신 "잘라내지 않고 비율 그대로(레터박스)" 표시하는 옵션을 신규 추가. 관리자 설정에 체크박스 추가(기본 꺼짐), 신규 트리거 document.getThumbnail/comment.getThumbnail(before)로 이전된 첨부파일이 있는 글/댓글의 크롭 타입만 골라 'ratio'로 강제.

v1.9.5에서 앞으로 새로 만드는 로컬 미리보기의 크롭 여백 문제는 고쳤지만, 이미 만들어진 미리보기는 자동으로 다시 만들어지지 않는다는 게 팔공산 님 재테스트로 확인됨 — files/thumbnails(코어의 표시 캐시)만 지우고 재시도해도 여전했던 이유는, 이 모듈이 만들어둔 원본 미리보기 자체가 옛날(레터박스) 방식 그대로 남아있었기 때문. ensureLocalThumbnail()은 thumbnail_filename이 이미 있으면 건드리지 않고 넘어가는 구조라 자동 복구가 안 됐음. [매핑 목록 / 레거시 정리] 탭에 "기존 썸네일 재생성 (여백 문제 수정)" 버튼 신규 추가 — 기존 미리보기 삭제 + DB 값 비움 → 원격 원본 재다운로드 → v1.9.5 새 로직으로 재생성. 한 번에 최대 30건.

팔공산 님 실사용 리포트: 썸네일 표시 방식을 "크롭"으로 지정해도 이 모듈이 만든 로컬 미리보기에서는 흰 여백이 낀 채로 나오고 원본이 박스에 꽉 차게 안 잘림. 원인은 ensureLocalThumbnail()이 만드는 로컬 미리보기가 최종 썸네일이 아니라 라이믹스 코어가 실제 썸네일을 만들 때 "원본 대신 읽는 소스"인데, 이걸 고정 500×500 정사각형에 레터박스(여백) 모드로 만들고 있었던 것 — 원본이 정사각형이 아니면 흰 여백이 미리보기 자체에 박혀서, 코어가 나중에 "크롭"으로 다시 잘라도 그 여백까지 함께 잘려 들어감. 고정 정사각형 대신 원본 비율을 유지한 채 긴 변만 최대 1600px로 축소하도록 변경 — 어떤 모드로 다시 리사이즈되든 여백·왜곡 없이 정상 동작.

팔공산 님 실사용 리포트: 게시판들을 통합 이전한 뒤 어떤 게시판은 썸네일이 정상 생성되는데 어떤 게시판은 안 됨 — 안 되는 게시판도 글을 하나하나 수정저장하면 그때는 생김. 원인은 "데이터 이전 및 통합"의 두 경로(① 매핑 자체가 없던 레거시 파일 이동 ② 이미 다른 저장소로 매핑돼 있던 파일을 새 목표로 재이동) 중, v1.9.2에서 썸네일 생성 로직을 넣을 때 ②번 경로만 빠뜨렸던 것 — 이 경로가 다루는 매핑 레코드에는 애초에 파일 정보(thumbnail_filename 등)가 없어서 검토 때도 놓쳤음. 그 결과 마침 "이미 매핑돼 있던" 파일이 있던 게시판만 재이동해도 썸네일이 안 생기고, 매핑이 아예 없던 순수 레거시 게시판은 정상적으로 생겨서 "게시판마다 다르다"고 느껴진 것. ②번 경로에서 원격 원본을 임시 파일로 내려받은 직후 FileModel::getFile()로 파일 정보를 조회해 썸네일 생성을 호출하도록 추가.

팔공산 님 실사용 리포트: 약 1800개 파일을 이전한 뒤 백필 버튼을 눌렀더니 처음엔 몇 개가 살아나다가 그 뒤로는 지연도 없이 아무리 눌러도 효과가 없었음. 원인은 후보를 가져오는 쿼리가 map_srl 오름차순으로 가장 오래된 300건만 매번 조회하고 오프셋도 없었으며, "썸네일 없음" 조건도 SQL이 아니라 PHP에서만 걸렀던 것 — 그 결과 전체 1800건 중 처음 300건만 영원히 반복해서 들여다보는 구조였고, 301번째 이후 파일은 이 버튼으로 애초에 도달할 방법이 없었음. getBsplus_external_storageMigratedImageList.xml에 "썸네일 없음"과 "이미지 파일만(mime_type)" 조건을 SQL 단으로 옮겨, 성공적으로 고친 파일이 다음 조회부터 자동으로 빠지고 뒤 순번 파일이 자연스럽게 올라오도록 수정. 덧붙여 "목표 저장소 파일을 수동으로 지워도 매핑 목록이 안 바뀌는" 현상은 버그가 아니라 설계상 의도된 동작(원격 파일 수천 개의 실시간 존재 확인은 너무 느려서 매핑 테이블 기록만 신뢰)임을 확인해 안내.

팔공산 님 실사용 리포트: "썸네일들이 첫페이지는 보이는데 2페이지부터 보이질 않네요". 원인은 라이믹스가 thumbnail_filename이 비어있는 이미지는 게시판 목록에 처음 표시할 때 원본을 읽어 그 자리에서 썸네일을 생성하는데, 이 모듈이 원본을 원격 이동 직후 로컬에서 지워버려서 아직 한 번도 화면에 안 뜬 이미지는 그 생성이 조용히 실패하던 것 — 코드 주석엔 "썸네일은 항상 로컬에 유지"라고 적혀 있었지만 실제로 그걸 보장하는 코드가 없었음(구버전 애드온의 방식만 주석으로 옮기고 실제 로직은 이식 안 함). 원본 이동 직전 로컬 미리보기를 만들어두는 ensureLocalThumbnail()을 구버전 애드온에서 이식해 3곳(업로드 트리거·레거시 마이그레이션·데이터 통합)에 적용. 이미 이동되어 이미 망가진 이미지를 위한 "누락된 썸네일 생성" 백필 도구도 추가. 최종 검토에서 이 수정이 처음엔 core files 테이블을 raw DB 쿼리로 직접 갱신하고 있었는데(다른 모듈의 실제 이중 접두어 버그 사례와 유사한 패턴으로 지적받음 — 조사 결과 이 코드 자체는 안전했지만) 일관성을 위해 정식 쿼리 XML 방식으로 교체.

더 깊은 교차검증 도구(module.xml↔실제 코드, executeQuery↔쿼리 XML 실존 등)로 최종 재검토하던 중 발견. v1.8.0에서 SFTP 지원을 위해 번들한 phpseclib3 파일 339개는 전부 클래스 정의 파일이라 라이믹스의 __XE__ 가드가 없었는데, 확인해보니 라이믹스 코어 루트 .htaccess가 modules/ 안의 일반 .php 파일 직접 실행까지는 막아주지 않는 구조라 그 경로를 직접 요청하면 부트스트랩 없이 실행될 수 있었음. 339개 파일 각각에 가드를 넣는 대신(업스트림 라이브러리라 건드리면 이후 버전업 시 diff가 꼬임) vendor/.htaccess로 그 디렉토리 전체의 외부 HTTP 접근을 차단(PHP 내부 require/오토로더 로딩에는 영향 없음). 이 항목 외 재검토에서 추가로 발견된 실제 결함은 없음(나머지는 관리자 액션 파일 위치 관련 휴리스틱 오탐 12건과 vendor 라이브러리 내 기존 오탐들).

rhymix.org 배포 게시글 댓글(팔공산 님)에서 받은 두 가지 요청을 반영. ① 저장소 종류에 SFTP/SSH 추가 — 구버전 애드온(lua_external_file)에서 이미 검증된 phpseclib3를 이 모듈 자체 vendor/에 번들해 서버에 ssh2 확장 모듈이 없어도 동작하도록 구현, 계정 1개만 지원(SSH·SFTP는 보통 같은 계정을 쓰므로). 우선순위 슬롯도 7단계 → 8단계로 확장. ② "이 게시판 전체를 저 저장소로 모아달라"고 실행해도 실제로는 안 됐던 문제 — getConsolidationCandidates가 이미 매핑된 파일만 대상으로 삼고, 모듈 설치 이전부터 있던 매핑 없는 레거시 파일은 건드리지 못하던 구조적 갭이었음. 이미 매핑된 파일 처리 후 남는 처리 개수 한도 안에서 레거시 파일도 함께 이동하도록 수정.

외부 검토에서 지적받은 사항. streamFile()/downloadToLocal()가 strpos($real, $realStorage) !== 0로만 경로 포함 여부를 확인하고 있어, $realStorage가 /data/storage일 때 /data/storage_evil/x 같은 형제 디렉터리도 prefix가 겹쳐 통과할 수 있는 구조였음. 현재는 $remotePath가 사용자 직접 입력이 아니라 매핑 테이블 값이라 실사용 위험은 낮지만, 향후 재사용 대비 사전 방어로 구분자 포함 비교 방식으로 교체. CLI로 정상 접근/traversal 차단 양쪽 다 직접 검증.

PHP 파일 12개·쿼리 XML 16개 전부를 다시 읽으며 진행한 재검토. 4개 트리거가 catch(\Exception)로만 감싸여 있어 PHP의 Error/TypeError 계열은 놓치고 있던 것을 catch(\Throwable)로 방어 범위 확장. 점검 중 v1.7.2에서 고친 시나리오가 getMapByOriginalPath 쿼리의 status='migrated' 필터 덕에 애초에 그 경로로는 도달하지 않는다는 것도 재확인(그래도 "트리거가 끝까지 못 돌아 상태 갱신이 누락된" 케이스에는 여전히 유효한 방어). buildRemotePath()의 ltrim() 마스크 사용 방식도 더 정확한 방식으로 교체(현재 데이터로는 문제 된 적 없는 사전 예방적 수정).

새 파일 자동 저장은 여유 공간 확보량(GB) 예약분을 항상 지키는데, "데이터 이전 및 통합"으로 로컬 목표를 고른 경우엔 이 확인 없이 그냥 밀어넣고 있었음 — 반복 실행하면 백업용으로 남겨두려던 공간까지 채울 수 있었음. 파일을 올리기 직전에 여유 공간을 확인해서, 예약분 밑으로 내려가면 그 시점에서 중단하고 안내하도록 수정.

게시글/댓글을 삭제하면 코어가 files 테이블 행을 즉시 지우지만, 원격(S3/FTP) 삭제가 실패해 delete_failed로 매핑이 남아있는 파일은 권한 체크 로직이 "레코드 없음 = 확인 불필요 = 허용"으로 잘못 판단해 삭제된 게시글의 첨부파일이 URL만 알면 계속 열람 가능했음. files 행이 없으면 항상 차단하도록 수정. 같은 점검에서 배지/안내문 카운트가 1000건을 넘으면 실제보다 적게 표시되던 부정확도 함께 수정.

"다른 이용자는 Cloudflare R2 + Google Cloud를 동시에 쓰고 싶을 수도 있겠다"는 논의 끝에, S3/FTP를 각각 3개 계정까지 등록 가능하도록 확장. 1번 계정은 기존 필드 그대로 사용해 하위호환 100%.

여기저기 흩어진 파일을 목표 저장소 하나로 모으는 4번째 탭. 다운로드→업로드 왕복 작업이라 트래픽 경고 문구 포함, 한 번에 최대 30건 처리.

특정 게시판만 사이트 전체 설정과 다른 저장소를 쓰도록 지정하는 3번째 관리 탭 "저장소 지정" 추가.

단일 선택 라디오 → 1~3순위 드롭다운으로 전면 개편. "1순위=로컬, 2순위=S3, 3순위=FTP"처럼 자유롭게 조합 가능해짐. 로컬은 여유공간 사전 체크, S3/FTP는 업로드 시도 후 실패하면 자동으로 다음 순위로.

저장소 4종(사용 안 함/로컬·마운트/S3/FTP), 업로드 직후 자동 이동, 다운로드·정적 서빙 양쪽에 권한 체크 적용. 이 시점엔 저장소를 하나만 고를 수 있었음.