สำหรับฉันดูเหมือนว่ายังคงเป็นปัญหาของโหมด ASCII กับไบนารีแม้ว่าจะมีการทดสอบที่คุณทำกับไคลเอ็นต์เดสก์ท็อปของคุณก็ตาม เดสก์ท็อปไคลเอนต์ของคุณอาจฉลาดกว่าไคลเอนต์บรรทัดคำสั่ง FTP บนเซิร์ฟเวอร์ที่ส่ง (เซิร์ฟเวอร์ภายในเครื่องที่คุณใช้งานสคริปต์)
ตัวอย่างเช่นหากเซิร์ฟเวอร์ภายในเครื่องเป็น Windows (ซึ่งใช้ CRLF เป็นบรรทัดสิ้นสุด) และเซิร์ฟเวอร์ระยะไกลคือ Unix (ซึ่งใช้เพียง LFs เป็นการสิ้นสุดบรรทัด) และคุณไม่ได้ระบุโหมดไบนารีและซอฟต์แวร์ FTP ของคุณไม่ทำงานโดยอัตโนมัติ ตรวจสอบและทำสิ่งที่ถูกต้องจากนั้นคุณจะใช้โหมด ASCII สำหรับการถ่ายโอนซึ่งควรตัด CRs ออกจากคู่ CRLF ใด ๆ หาก tarball gzipped ของคุณมีรูปแบบไบต์ 0x0d0a ปรากฏขึ้นที่ใดก็ได้มันจะเสีย 0x0d
หากไคลเอนต์บรรทัดคำสั่ง FTP ในระบบการส่งของคุณ (ฉันเดาว่าเป็นเซิร์ฟเวอร์ในพื้นที่ของคุณ) เป็นสิ่งที่เหมือนหนึ่งในระบบของฉันสิ่งที่คุณต้องทำเพื่อทดสอบทฤษฎีนี้คือการเพิ่ม binaryคำสั่งก่อนหรือหลังcdบรรทัด:
cd $FSBACKDIR
ATTACH='for file in *$DATE.tar.gz; do echo -n -e "put ${file}\n"; done'
ftp -nv <<EOF
open $FTPHOST
user $FTPUSER $FTPPASS
binary
cd $FTPDIR
$ATTACH
quit
EOF
ความคิดสุดท้าย: ถ้าไม่ใช่ ASCII เทียบกับโหมดไบนารีหลังจากทั้งหมดฉันจะดูว่า FTP ALG ใน NAT เกตเวย์ระหว่างเซิร์ฟเวอร์ในพื้นที่และเซิร์ฟเวอร์ระยะไกลของคุณหรือไม่ (หรือระหว่างเซิร์ฟเวอร์ระยะไกลและเดสก์ท็อปของคุณ) เป็นไฟล์ กำลังขนส่ง ฉันคิดว่าอาจเป็นพร็อกซีชนิดอื่นในระหว่างโฮสต์ไม่ใช่ FTP ALG ของ NAT เกตเวย์โดยเฉพาะ