मुझे rsync के साथ एक अजीब समस्या का सामना करना पड़ा है (बिना -c, इसलिए rsync की "त्वरित जांच" एल्गोरिथ्म को शामिल करना) पहले से ही सिंक्रनाइज़ की गई फ़ाइलों को बार-बार एक exFAT स्वरूपित ड्राइव पर कॉपी करना।
शामिल स्रोत फ़ाइलों को एक HFS मात्रा पर संग्रहीत किया जाता है और .docxशब्द दस्तावेजों से एक स्वचालित छवि निष्कर्षण प्रक्रिया द्वारा बनाया गया था और 1 जनवरी, 1980 00:00:00 का एक संशोधन समय है, जो एक्सफ़ैट टाइमस्टैम्प द्वारा समर्थित न्यूनतम समय भी होता है। प्रारूप।
rsync -aएक्सफ़ैट पर उन गंतव्य फ़ाइलों के बाद 1 जनवरी, 1980 02:00:00 का संशोधन समय है।
ऐसा लगता है कि मेरे OS X एक्सफ़ैट चालक द्वारा समर्थित न्यूनतम समय दो घंटे से बंद है।
और यही कारण है कि फाइलों को अलग-अलग मानने के लिए rsync की त्वरित जांच एल्गोरिदम का कारण बनता है।
निम्न परीक्षण इस बात की पुष्टि करता है:
# create a 10Mb exFAT disk image:
hdiutil create -size 10m -fs ExFAT -volname EXFATTEST exfattest.dmg
# attach the diskimage
hdiutil attach exfattest.dmg
# create a test file with a creation time of Jan 1, 1980 00:00:00
touch -t "198001010000.00" /Volumes/EXFATTEST/test1.txt
ls -lT /Volumes/EXFATTEST/test1.txt
-rwxrwxrwx 1 user staff 0 Jan 1 02:00:00 1980 /Volumes/EXFATTEST/test1.txt
# ^^ off by two hours
# try a file with 3am
touch -t "198001010300.00" /Volumes/EXFATTEST/test2.txt
ls -lT /Volumes/EXFATTEST/test2.txt
-rwxrwxrwx 1 user staff 0 Jan 1 03:00:00 1980 /Volumes/EXFATTEST/test2.txt
# ^^ works as expected
# unmount the disk image
hdiutil detach /Volumes/EXFATTEST/
लिनक्स पर एक समान परीक्षण यह त्रुटि नहीं दिखाता है:
truncate -s 10M exfattest.img
mkfs.exfat exfattest.img
mkdir /mnt/EXFATTEST/
mount -o loop exfattest.img /mnt/EXFATTEST/
touch -t "198001010000.00" /mnt/EXFATTEST/test.txt
ls --full-time /mnt/EXFATTEST/test.txt
rwxr-xr-x 1 root root 0 1980-01-01 00:00:00.000000000 +0100 /mnt/EXFATTEST/test.txt
# ^^ correct modification time
umount /mnt/EXFATTEST/
मेरा सरल समाधान स्रोत फ़ाइलों के निर्माण समय का उपयोग करके अद्यतन करना है touch।
हालांकि, मैं जानना चाहता हूं कि क्या यह वास्तव में बग है और अगर कोई इस त्रुटि को नए OS X रिलीज़ पर पुन: उत्पन्न कर सकता है क्योंकि Apple मेरे अभी भी पूरी तरह से ठीक चलने की जल्दी 2008 iMac को अपग्रेड करने की अनुमति नहीं देता है;)
मैं अभी भी एल Capitan पर हूँ:
sw_vers
ProductName: Mac OS X
ProductVersion: 10.11.6
BuildVersion: 15G22010
अपडेट करें:
एक्सफ़ैट तालिका का निरीक्षण करने के बाद ऐसा लगता है कि मेरा एल कैपिटन एक्सफ़ैट चालक हमेशा डेटा क्षेत्र के 0xfcलिए उपयोग करता है LastModifiedTimezoneOffset।
यह हस्ताक्षरित बाइट मूल्य 15 मिनट वेतन वृद्धि में यूटीसी से ऑफसेट निर्दिष्ट करता है। 0xfcहै -4दशमलव में और एक नकारात्मक यूटीसी एक घंटे की भरपाई के रूप में व्याख्या की जाएगी।
मुझे नहीं पता कि ड्राइवर ऐसा क्यों कर रहा है, लेकिन अगर यह -1 के स्थिर टाइमज़ोन ऑफसेट का उपयोग करता है, तो इसे हमेशा यूटीसी समय स्टैम्प से 1 घंटे घटाना होगा जब टाइमस्टैम्प को संग्रहीत करने और संग्रहीत मूल्य में 1 घंटा जोड़ने पर डिस्क से वापस टाइमस्टैम्प पढ़ना।
यह मूल रूप से काम करता है, जब तक कि UTC टाइम स्टैम्प 1 जनवरी, 1980 01:00 से छोटा नहीं होता है, क्योंकि एक्सफ़ैट पर एक फ़ाइल का न्यूनतम समर्थित समय स्टैम्प 1 जनवरी, 1980 00:00 है।
इसलिए मैं इसे एक बग मानता हूं, क्योंकि एल कैप्टन का एक्सफ़ैट चालक एक्सफ़ैट पर समर्थित न्यूनतम संभव फ़ाइल संशोधन समय स्टैम्प को सेट करने में सक्षम नहीं है।
निम्न परीक्षण इस बात की पुष्टि करता है। यह TZसिस्टम के समय क्षेत्र से स्वतंत्र रूप से यूटीसी समय क्षेत्र के उपयोग को मजबूर करने के लिए पर्यावरण चर का उपयोग करता है:
# set the minimum possible exFAT file modifification timestamp in UTC
TZ=UTC touch -t '198001010000.00' /Volumes/EXFATTEST/test.txt
# read back the stored timestamp in UTC
TZ=UTC ls -lT /Volumes/EXFATTEST/test.txt
-rwxrwxrwx 1 gollum staff 0 Jan 1 01:00:00 1980 /Volumes/EXFATTEST/test.txt
# ^^^^^^^^ ERROR: off by one hour
HFS पर इस तिथि के साथ एक फ़ाइल बनाते समय और इसे एक्सफ़ैट वॉल्यूम पर कॉपी करते समय समान त्रुटि:
# set Jan 1, 1980 00:00:00 on HFS (e.g. file in home directory)
TZ=UTC touch -t '198001010000.00' $HOME/test2.txt
TZ=UTC ls -lT $HOME/test2.txt
-rw-r--r-- 1 gollum staff 0 Jan 1 00:00:00 1980 /Users/gollum/test2.txt
# ^^^^^^^^ CORRECT!
# copy the file to the exFAT volume and check the destination date
cp -a $HOME/test2.txt /Volumes/EXFATTEST/test2.txt
TZ=UTC ls -lT /Volumes/EXFATTEST/test2.txt
-rwxrwxrwx 1 gollum staff 0 Jan 1 01:00:00 1980 /Volumes/EXFATTEST/test2.txt
# ^^^^^^^^ ERROR: off by one hour
एक और दिलचस्प परीक्षण जो मैंने किया है वह लिनक्स पर बनाई गई एक्सफ़ैट डिस्क छवि को ले रहा है (जिसमें सही समय टिकट के साथ परीक्षण फ़ाइल शामिल है) और इसे ओएस एक्स पर बढ़ते हुए:
TZ=UTC ls -lT
total 0
-rwxrwxrwx 1 gollum staff 0 Jan 1 00:00:00 1980 test.txt
# ^^^^^^^^ correct!
हालाँकि, जब इस फ़ाइल को डुप्लिकेट किया जाता है, तो तारीख एक घंटे फिर से बंद हो जाती है। तो कम से कम ओएस एक्स एक्सफ़ैट चालक समय स्टैम्प को सही ढंग से पढ़ने में सक्षम है, भले ही फाइलें गैर 0xfcटाइमज़ोन ऑफसेट का उपयोग करके संग्रहीत हों । वाह!
अब अन्य तरीके से: लिनक्स पर OS X dmg माउंट करने से OS X एक्सफ़ैट ड्राइवर की दूसरी त्रुटि का पता चलता है:
mount -o loop exfattest.dmg /mnt/EXFATTEST/
FUSE exfat 1.0.1
ERROR: bad date 1980-01-00
# ^^^ OS X stored the DAY as zero ::facepalm::
विकास में लापता कोने मामले के परीक्षण का एक और आदर्श उदाहरण है।
यह मूल रूप से मेरे प्रश्न का उत्तर है। हालांकि, मैं एक उत्तर को स्वीकार करूंगा जो मेरे निष्कर्षों को गलत साबित करता है या उनकी पुष्टि करता है और जो मेरे प्रश्न का उत्तर देता है अगर यह बग एल कैपिटान ओएस एक्स रिलीज की तुलना में नए पर होता है।
अपडेट 2:
मैं एडम हैरिसन (यूके से एक डिजिटल फोरेंसिक अन्वेषक) द्वारा एक ब्लॉग पोस्ट पर आया हूं: एक्सफ़ैट टाइमस्टैम्प व्यवहार विभिन्न ऑपरेटिंग सिस्टम के साथ संबद्ध
का हवाला देते हुए:
Ubuntu 16.04 और Ubuntu 18.04
सभी टाइमज़ोन UTC में दर्ज किए गए हैं। टाइमज़ोन फ़ील्ड लगातार 00 पर सेट हैं, यह दर्शाता है कि वे उपयोग में नहीं हैं।OSX 10.13.3 टाइमज़ोन
फील्ड्स - लगातार "FC" पर सेट है जो UTC-1 है और मुझे पता नहीं क्यों ...
इसलिए यह मेरे निष्कर्षों से मेल खाता है।