1

주제: 파일 업로드 관련하여

지금까지는 파일 포스팅 중에 익스플로러 에러가 없었는데,

오늘 포스팅중에 쥬크박스 거는 것이 있어서 15곡을 걸었습니다. 파일이 이미 다 올라갔구요. 그순간 익스플로러 페이지 오류나면서 창이 닫혀버려서 임시저장본을 열었는데 좀전에 업로드한 파일들은 나오지 않더군요.

그래서 중복으로 올라갈 것 같지만 어쩔 수 없어서 다시 파일들을 다 올리고 포스팅을 마쳤습니다.

혹시나 해서 데이터 백업을 해보니 이전 백업날짜후에 증가한 데이터 용량이 두배정도 뻥튀기 되어 있더라구요.

좀전의 오류가 나서 다시 올린 파일들이 같은 용량의 같은 파일임에도 파일명으로 정돈이 아닌 임의의 숫자로 리스트가 되서 그런 듯 보이는데 제가 이해하는 것이 맞느지요.

전부터 이 파일명 결정되는 문제는 수정을 안하시던데 다른 기술적인 이유가 있는건지...

그리고 attach 이 폴더만이라도 지금 스킨수정시 이미지폴더 보여주듯이 열어주시면 안됩니까?

지금 같은 경우 대략 난감해집니다. 파일명을 원래 파일데로 보여줄 수 없다면 파일용량과 업로드날짜정도로 확인할 수 있게 하는 방법은 없을지...

당신을 사랑해도 될까요?

2

답글: 파일 업로드 관련하여

킬러캐스트 작성:

전부터 이 파일명 결정되는 문제는 수정을 안하시던데 다른 기술적인 이유가 있는건지...

파일명을 한글로 하면 linux 환경에서는 깨집니다. 사용자한테 "파일명은 영문만 입력해. 알쥐?"라고 할 수도 없는 노릇이니 일괄적으로 바꿔주는 거죠.

킬러캐스트 작성:

그리고 attach 이 폴더만이라도 지금 스킨수정시 이미지폴더 보여주듯이 열어주시면 안됩니까?

지금 같은 경우 대략 난감해집니다. 파일명을 원래 파일데로 보여줄 수 없다면 파일용량과 업로드날짜정도로 확인할 수 있게 하는 방법은 없을지...

이 부분은 블로그 관리의 영역이라기 보다 계정관리의 측면이 더 강하기 때문에 블로그 관리 화면에 직접 포함시키는 것은 개념상 좋지 않은 것 같습니다. 후에 관리자 화면 플러그인 환경이 도입되면 이 기능을 활용하여 추가되는 편이 좋을 것 같군요. 그나저나 사용하지 않는 attach 파일 정리하는 기능은 필요할 것 같기도 하네요.

3

답글: 파일 업로드 관련하여

킬러캐스트 작성:

전부터 이 파일명 결정되는 문제는 수정을 안하시던데 다른 기술적인 이유가 있는건지...

중복된 파일명이 발생할 수 있기 때문에라도 파일명을 새로 작성할 수 밖에 없다고 봅니다.
(예를 들어 저 같은 경우 이미지 파일을 올릴 때 01.png 02.png 등으로 작성해서 올리는데 릴레이로 파일명이 이어서 올리는게 아니라
다음에 또 올릴 때 다시 처음부터 01.png 02png 등으로 시작할 수 있습니다. 이 때 동일 파일명이기 때문에 문제가 발생할 수 있습니다.)

하늘은 스스로 삽질하는 자를 삽으로 팬다

4

답글: 파일 업로드 관련하여

나니 작성:

중복된 파일명이 발생할 수 있기 때문에라도 파일명을 새로 작성할 수 밖에 없다고 봅니다.

킬러캐스트님이 원하시는 것은 계정에 접속해서 파일명으로 직접 파일을 알아볼 수 있으면 하는 것인데, "파일명_업로드시간.확장자" 형식으로 하면 각 파일에 고유명을 부여하면서 인식이 가능하게 할 수 있지요. "02_200606111240.jpg(2006년 06월 11일 12시 40분 38초)"처럼요. 다중업로드라면 "파일명_업로드시간_고유넘버.확장자" 형식으로 하면 고유명이 되죠. "02_200606111240_001.jpg", "02_200606111240_002.jpg", "02_200606111240_003.jpg"... 이렇게요.

graphittie (2006-07-01 21:11:23)에 의해 마지막으로 수정

5

답글: 파일 업로드 관련하여

파일명 랜덤으로 잡히는 것은 늘 봐오던 것이라 어쩔수 없다고 생각은 하면서도 질문해봤습니다. 그전에 계정상요할때는 수동으로 고칠수가 있었으니 문제가 없었는데요.

티스토리같은경우는 처음부터 계정관리가 오픈되지 않는 서비스다보니.

그럼 지금처럼 사진 한두개(그냥 놔둬두 별 상관없는 용량)가 아니라 몇십메가정도 차지하는 고용량들이 겹쳐서 중복되어서 올라가 있다면 그냥 어쩔 수없이 놔둬야 하는거군요...어찌해야 하나..일년 이년 쓰다가 이런 일이 몇번 반복되면 누적되는 용량낭비가 심해보이는데요. 어차피 복구를 해도 데이터백업을 기본으로 하기에 계속 안고 가야 하는 용량이구요. 계정관리를 오픈하지 않으면서 이 문제를 해결 할 수 있는 시스템이 나온다면 좀 더 합리적일것 같군요.

당신을 사랑해도 될까요?

6

답글: 파일 업로드 관련하여

킬러캐스트 작성:

그럼 지금처럼 사진 한두개(그냥 놔둬두 별 상관없는 용량)가 아니라 몇십메가정도 차지하는 고용량들이 겹쳐서 중복되어서 올라가 있다면 그냥 어쩔 수없이 놔둬야 하는거군요...어찌해야 하나..일년 이년 쓰다가 이런 일이 몇번 반복되면 누적되는 용량낭비가 심해보이는데요. 어차피 복구를 해도 데이터백업을 기본으로 하기에 계속 안고 가야 하는 용량이구요. 계정관리를 오픈하지 않으면서 이 문제를 해결 할 수 있는 시스템이 나온다면 좀 더 합리적일것 같군요.

유효하지 않은 첨부파일 정리기능은 배포판에도 필요한 기능이지만, 티스토리에는 정말 필수적인 기능이군요. TnC 개발자 분들도 이곳을 매일 모니터링 하시니 문제에 대해 인지하셨을 겁니다. 좀 기다려 보면 어떻게 해주시겠지요. 지금은 아무래도 베타니까요.

7

답글: 파일 업로드 관련하여

제가 잘못 이해했군요 ㅠㅠ

하늘은 스스로 삽질하는 자를 삽으로 팬다

8

답글: 파일 업로드 관련하여

네..감사합니다. 저역시 태터를 써본지 일년도 안된 초보지만, 다음이나 네이버의 블로그를 쓰면서는 이런 질문을 아예 하지도 않았겠죠. 제가 두서없이 질문해서 파일관리문제가 파일명정리쪽으로 잘못 이해되게 글을 쓴 느낌이네요. 한번 업로드에 1-2메가 제한이라면 겹쳐있는 파일들이 많아도 별 신경안쓰겠지만 고용량 업로드가 가능한 서비스다 보니 다른 방법이 필요하다 느꼈구요. 티스토리도 태터를 기반으로 한거기에 ftp가 열리지 않을 뿐이지 사용자가 계속 데이터를 백업하고 복구하는 절차가 늘 따라가는 부분이라. 자신의 총 용량이 1기가가 되던 2기가가되던 무한제공해 준다면야 신경쓸 건 없겠지만 나중에 그 많은 용량을 백업받고 복구할 방법이 아예 없어진다면 지금 방법은 개선의 여지가 필요한 거겠죠. 만약 데이터 복구를 지금의 서버와 웹상에서 복구가 아닌 하드디스크에서 바로 업로드 시켜서 복구 할 수 있다면 또 문제는 달라집니다. 그것도 좋은 방법이 되겠죠. 아니면 전 그냥 서버에 데이터 무조건 저장하고 거기서 복구하고 그렇게 해버릴테야~ ...... 어휴 저같은 사람 100명만 모이면 200명이 쓸 공간을 100명밖에 사용하지 못하는 일이 생겨버리네요~ 아무튼 계속 좋아지는 티스토리가 되고 있어서 기분 좋습니다.

당신을 사랑해도 될까요?

9

답글: 파일 업로드 관련하여

킬러캐스트 작성:

어휴 저같은 사람 100명만 모이면 200명이 쓸 공간을 100명밖에 사용하지 못하는 일이 생겨버리네요~ 아무튼 계속 좋아지는 티스토리가 되고 있어서 기분 좋습니다.

어차피 계정 용량은 다음쪽에서 제공하니까 서버쪽에서는 그다지 큰 문제는 되지 않을 듯도 싶습니다;; (아닌가..?)
문제라면 클라이언트의 백업 처리 시간이 길어진다는 것이죠;;
TnC든 TnF든 놀고있는 사람은 아무도 없으니까, 인지된 문제점은 반드시 해결될 겁니다^^

현재 사용중인 서버 세팅 - Apache 2.2.3 / mysql 5.0.24 / php 5.1.6
메인블로그 - http://sumomo.tistory.com/
스킨블로그 - http://mamoru.homeip.net/skin/

10

답글: 파일 업로드 관련하여

킬러캐스트 작성:

지금까지는 파일 포스팅 중에 익스플로러 에러가 없었는데,오늘 포스팅중에 쥬크박스 거는 것이 있어서 15곡을 걸었습니다. 파일이 이미 다 올라갔구요. 그순간 익스플로러 페이지 오류나면서 창이 닫혀버려서 임시저장본을 열었는데 좀전에 업로드한 파일들은 나오지 않더군요. 그래서 중복으로 올라갈 것 같지만 어쩔 수 없어서 다시 파일들을 다 올리고 포스팅을 마쳤습니다.혹시나 해서 데이터 백업을 해보니 이전 백업날짜후에 증가한 데이터 용량이 두배정도 뻥튀기 되어 있더라구요.

일단 이와 관련된 문제로 임시저장본의 첨부파일이 증발하는 문제가 있긴 하죠. sad

로직이 완벽하다는 가정하에 엄하게 처박혀 있는 파일은 없는 것이 정상이랍니다. (댕글링 오브젝트?)