अस्थायी फ़ाइलों को / tmp या वर्तमान कार्यशील निर्देशिका में सहेजा जाना चाहिए?

76

मेरे पास एक प्रोग्राम है जिसे अस्थायी फ़ाइलों को बनाने की आवश्यकता है। यह क्लस्टर मशीनों के लिए लिखा गया है।

अगर मैंने उन फ़ाइलों को सिस्टम-वाइड अस्थायी निर्देशिका (जैसे:) में सहेजा /tmp, तो कुछ उपयोगकर्ताओं ने प्रोग्राम को विफल होने की शिकायत की क्योंकि उनके पास / tmp तक उचित पहुँच नहीं थी। लेकिन अगर मैंने उन फाइलों को कार्यशील निर्देशिका में सहेजा, तो उन उपयोगकर्ताओं ने भी शिकायत की कि वे उन रहस्यमय फाइलों को नहीं देखना चाहते थे।

कौन सा बेहतर अभ्यास है? क्या मुझे इस बात पर जोर देना चाहिए कि बचत /tmpसही दृष्टिकोण है और किसी भी विफलता का "उद्देश्य के रूप में काम करना" के रूप में बचाव करना है (यानी उचित अनुमति या पहुंच के लिए अपने व्यवस्थापक से पूछें)?

data file-handling

— SmallChess
स्रोत

3

जाँचें कि क्या कार्यक्रम में पहुँच है और यदि कोई दूसरा अस्थायी पता नहीं है

— शाफ़्ट फ्रीक

24

यदि आपके व्यवस्थापक ने एक्सेस अधिकारों को खराब कर दिया है, तो उसे निश्चित रूप से इसे ठीक करना चाहिए। यदि आपका व्यवस्थापक आपके प्रोग्राम में निष्पादन अधिकार जोड़ना भूल गया, तो आप क्या करेंगे?

— डॉक्टर ब्राउन

7

आप अधिकांश विंडोज़ सिस्टम पर नहीं पाएंगे / टैम्प करेंगे, लेकिन एक ओएस कॉल है जो आपको बताएगी कि टेम्प फाइल कहां रखी जाए।

— इयान

28

यदि कुछ लोगों की /tmpयूनिक्स जैसी प्रणाली तक पहुंच नहीं है , तो यह गलत है। महानायक को कुछ ऐसा करना चाहिए chmod 1777 /tmp।

— मुशफिल

12

इस बात से सावधान रहें कि $ TMPDIR इससे भिन्न पथ को इंगित कर सकता है /tmp/, जिसे आपको इसके बजाय उपयोग करना चाहिए। कुछ उत्तर देखें;)

— मार्सेल

141

अस्थायी फ़ाइलों को कई कारणों से ऑपरेटिंग सिस्टम अस्थायी निर्देशिका में संग्रहीत किया जाना है:

ऑपरेटिंग सिस्टम उन फाइलों को बनाना बहुत आसान बनाता है, जबकि यह सुनिश्चित करता है कि उनके नाम अद्वितीय होंगे ।
अधिकांश बैकअप सॉफ़्टवेयर जानते हैं कि अस्थायी फ़ाइलों वाली निर्देशिकाएं क्या हैं, और उन्हें छोड़ देता है। यदि आप वर्तमान निर्देशिका का उपयोग करते हैं, तो वृद्धिशील बैकअप के आकार पर एक महत्वपूर्ण प्रभाव हो सकता है यदि बैकअप अक्सर किया जाता है।
अस्थायी निर्देशिका अलग डिस्क पर या रैम में हो सकती है, जिससे पढ़ने-लिखने की पहुंच बहुत तेज हो जाती है ।
रिबूट के दौरान अस्थायी फ़ाइलों को अक्सर हटा दिया जाता है (यदि वे एक रैमडिस्क में हैं, तो वे बस खो जाते हैं)। यह अनंत विकास के जोखिम को कम करता है यदि आपका ऐप हमेशा अस्थायी फ़ाइलों को सही ढंग से नहीं हटा रहा है (उदाहरण के लिए क्रैश के बाद)।

यदि एप्लिकेशन और उपयोगकर्ता फ़ाइलों के साथ फ़ाइलों को संग्रहीत किया जाता है, तो कार्यशील निर्देशिका से अस्थायी फ़ाइलों को साफ़ करना आसानी से गड़बड़ हो सकता है। आप वर्तमान निर्देशिका के भीतर एक अलग निर्देशिका बनाकर इस समस्या को कम कर सकते हैं, लेकिन इससे दूसरी समस्या हो सकती है:
पथ की लंबाई कुछ प्लेटफॉर्म पर बहुत लंबा हो सकता है। उदाहरण के लिए, विंडोज पर, कुछ API के लिए पथ सीमाएँ, चौखटे और अनुप्रयोग भयानक हैं , जिसका अर्थ है कि आप आसानी से ऐसी सीमा को मार सकते हैं यदि वर्तमान निर्देशिका पहले से ही पेड़ की पदानुक्रम में गहरी है और आपकी अस्थायी फ़ाइलों के नाम बहुत लंबे हैं।
सर्वर पर, अस्थायी निर्देशिका के विकास की निगरानी अक्सर सीधे की जाती है। यदि आप एक अलग निर्देशिका का उपयोग करते हैं, तो इसकी निगरानी नहीं की जा सकती है, और पूरी डिस्क की निगरानी करने से यह आसानी से पता लगाने में मदद नहीं मिलेगी कि यह अस्थायी फ़ाइलें हैं जो अधिक से अधिक जगह लेती हैं।

पहुँच अस्वीकृत त्रुटियों के लिए, सुनिश्चित करें कि आपने ऑपरेटिंग सिस्टम को आपके लिए एक अस्थायी फ़ाइल बनाने की अनुमति दी है। उदाहरण के लिए, ऑपरेटिंग सिस्टम, यह जान सकता है कि किसी दिए गए उपयोगकर्ता के लिए, के अलावा एक निर्देशिका /tmpया C:\Windows\tempका उपयोग किया जाना चाहिए; इस प्रकार, उन निर्देशिकाओं को सीधे एक्सेस करके, आप वास्तव में एक एक्सेस अस्वीकृत त्रुटि का सामना कर सकते हैं।

यदि आपको ऑपरेटिंग सिस्टम कॉल का उपयोग करते समय भी एक्सेस से इनकार किया जाता है, तो ठीक है, इसका सीधा मतलब है कि मशीन बुरी तरह से कॉन्फ़िगर किया गया था; यह पहले से ही Blrfl द्वारा समझाया गया था । यह मशीन को कॉन्फ़िगर करने के लिए सिस्टम व्यवस्थापक पर निर्भर है; आपको अपना एप्लिकेशन नहीं बदलना होगा।

अस्थायी फ़ाइलें बनाना कई भाषाओं में सीधा है। कुछ उदाहरण:

दे घुमा के:

# The next line will create a temporary file and return its path.
path="$(mktemp)"
echo "Hello, World!" > "$path"

अजगर:

import tempfile

# Creates a file and returns a tuple containing both the handle and the path.
handle, path = tempfile.mkstemp()
with open(handle, "w") as f:
    f.write("Hello, World!");

सी#:

// Creates a file and returns the path.
var path = Path.GetTempFileName();
File.WriteAllText(path, "Hello, World!");

पीएचपी:

# Creates a file and returns the handle.
$temp = tmpfile();
fwrite($temp, "Hello, World!");
fclose($temp);

माणिक:

require "tempfile"

# Creates a file and returns the file object.
file = Tempfile.new ""
file << "Hello, World!"
file.close

ध्यान दें कि कुछ मामलों में, जैसे कि PHP और रूबी में, फ़ाइल को हैंडल बंद होने पर हटा दिया जाता है। भाषा / ढांचे के साथ बंधे पुस्तकालयों का उपयोग करने का यह एक अतिरिक्त लाभ है।

— आर्सेनी मूरज़ेंको
स्रोत

2

आपको क्या मतलब है "सुनिश्चित करें कि आप ऑपरेटिंग सिस्टम को आपके लिए एक अस्थायी फ़ाइल बनाने दें"। इसलिए उदाहरण के लिए, fopen("/tmp/mytmpfile", "w");मुझे अस्थायी फ़ाइलों को संभालने के लिए कुछ सिस्टम कॉल करना चाहिए?

— simon

30

@ गुरका: आपको tmpfile(3)अपनी अस्थायी फ़ाइलों mktemp(3)को बनाने के लिए कॉल किया जाना चाहिए , या फ़ाइल नाम बनाने के लिए कम से कम कॉल करना चाहिए।

— TMN

3

@ टीएमएन: वे केवल पुस्तकालय के कार्य हैं जो उपयोगकर्ता स्थान में चलते हैं, और उनके पास ऑपरेटिंग सिस्टम द्वारा दी गई अनुमति त्रुटि को बायपास करने के लिए कोई जादू नहीं है।

— १

25

@musiphil tmpfile और mktemp दोनों अस्थायी फ़ाइलों के लिए पथ निर्धारित करने के लिए बाहरी चर का उपयोग करते हैं। ये संभवत: प्रति उपयोगकर्ता निर्देशिका / tmp / की तुलना में किसी अन्य निर्देशिका को इंगित करने के लिए सेट किए गए हैं। मैन्युअल रूप से / tmp / में फ़ाइल नाम बनाने का प्रयास विफल हो सकता है, जबकि tmpfile और mktemp मान्य पथ पर वापस आ जाएगा।

— पाइप

2

@musiphil: मैंने कभी नहीं कहा कि वे अनुमति की समस्या को ठीक करेंगे, मैं फ़ाइलों को बनाने के लिए सिस्टम कॉल का उपयोग करने के बारे में उनके सवाल का जवाब दे रहा था।

— टीएमएन

33

क्या मुझे बचाने के लिए जोर देना चाहिए / tmp सही दृष्टिकोण है और किसी भी विफलता के लिए "जैसा कि काम कर रहा है" के लिए बचाव (यानी उचित अनुमति के लिए अपने व्यवस्थापक से पूछें)?

इसके लिए मानक हैं, और सबसे अच्छी बात जो आप कर सकते हैं वह है उनके अनुरूप।

POSIX, जिसे किसी भी महत्व के हर गैर-मेनफ्रेम ओएस द्वारा अनुसरण किया जाता है, जिसे आप चलाने की संभावना रखते हैं, में डिफ़ॉल्ट मानों का उपयोग करके एक निर्देशिका में विशिष्ट रूप से नामित अस्थायी फ़ाइलों को बनाने के प्रावधान हैं जो पर्यावरण द्वारा पुन: कॉन्फ़िगर किए जा सकते हैं:

C stdio.hशीर्ष लेख में वैकल्पिक रूप से एक P_tmpdirमैक्रो शामिल हो सकता है जो सिस्टम की अस्थायी निर्देशिका को नाम देता है।
TMPDIRअस्थायी फ़ाइलों के स्थान को बदलने के लिए विहित पर्यावरण चर है। POSIX से पहले, अन्य चर का उपयोग किया गया था, इसलिए मैं उस या उस पहले के साथ जाना चाहता हूं TMP, TEMPDIRऔर TEMPअगर सिस्टम में कोई मौजूद नहीं है, तो मूल्य, पंटिंग और सिस्टम डिफ़ॉल्ट का उपयोग करना है।
mkstemp()और tempfile()कार्यों अद्वितीय अस्थायी फ़ाइलें उत्पन्न होगा।

यदि आपके उपयोगकर्ताओं को अस्थायी फ़ाइलों को बनाने की क्षमता से वंचित किया जा रहा है, तो सिस्टम या तो गलत है या व्यवस्थापक स्पष्ट नहीं कर रहे हैं कि उनकी नीति ऐसी चीजों पर क्या है। उन मामलों में, आप यह कहने में बहुत दृढ़ आधार पर होंगे कि आपका कार्यक्रम एक अच्छी तरह से स्थापित पोर्टेबिलिटी मानक के अनुरूप है और पर्यावरण के चर का उपयोग करके इसका व्यवहार बदला जा सकता है।

— Blrfl
स्रोत

P_tmpdirstdio.hसी भाषा विनिर्देश द्वारा परिभाषित के रूप में एक हिस्सा नहीं है । इसे POSIX या SVID द्वारा परिभाषित किया जा सकता है।

— मुसीफिल

1

@ मुसिफिल: जैसा कि (अब स्पष्ट) उत्तर से पता चलता है, यह पोसिक्स का हिस्सा है। (तकनीकी रूप से, यह एक एक्स / ओपन सिस्टम एक्सटेंशन है जिसे POSIX ने शामिल किया है। pubs.opengroup.org/onlinepubs/009695399/basedefs/stdio.h.html देखें । )

— ब्लरफ्ल

उपरोक्त सभी के साथ पूरी तरह से सहमत हैं। एक अच्छा उदाहरण लिनक्स सिस्टम है pam_tmpdir- यह सेट TMPDIRऔर TMPमजबूती और गोपनीयता के लिए प्रत्येक उपयोगकर्ता के लिए अलग है। यह TMPDIRएकल कमांड के लिए सेट करने में सक्षम होने के लिए भी उपयोगी है - यदि आपके पास गति के लिए रैम फाइल सिस्टम में आपकी सामान्य अस्थायी निर्देशिका है, तो आपको कमांड के लिए ऐसा करने की आवश्यकता हो सकती है जो विशाल अस्थायी फ़ाइलों (जैसे कि एक विशाल sort, उदाहरण के लिए) उत्पन्न करते हैं । उन मानकों / रूढ़ियों को अनदेखा न करें जो आपके उपयोगकर्ता अपेक्षा करते हैं!

— टॉबी स्पाइट

अस्थायी फ़ाइलों के स्थान के लिए निश्चित रूप से पर्यावरण की जांच करें और कभी भी हार्ड-कोड / tmp न करें। क्योंकि एक साझा tmp में सुरक्षा मुद्दे हैं, एक शमन जो मैंने अक्सर देखा है वह है प्रति उपयोगकर्ता / tmp निर्देशिकाओं को बनाने के लिए जिसमें किसी और के लिए कोई पठन-लिखित अनुमति नहीं है। यह संभव दौड़ की स्थिति और सिम्लिंक हमलों को हटा देता है।

— ज़ैन लिंक्स

9

अस्थायी फ़ाइल-निर्देशिका अत्यधिक ऑपरेटिंग सिस्टम / पर्यावरण पर निर्भर है। उदाहरण के लिए एक वेब-सर्वर-अस्थायी डीआईआर सुरक्षा कारणों से ओएस-टेम्प-डीआईआर से अलग है।

एमएस-विंडोज के तहत हर उपयोगकर्ता का अपना अस्थायी-डीआईआर है।

यदि आपको ऐसा फ़ंक्शन उपलब्ध है, तो इसके लिए आपको createTempFile () का उपयोग करना चाहिए ।

— के 3 बी
स्रोत

1

बस विंडोज में छिपी ओएस सीमाओं के प्रति सावधान रहें। हमने उस कठिन तरीके की खोज की जिसमें एक फ़ोल्डर में अधिकतम फ़ाइलों की संख्या 65,565 तक सीमित थी। ज़रूर, यह बहुत सारी फाइलें हैं, और निश्चित रूप से, आपको कभी भी ऐसा अनुमान नहीं लगाना चाहिए कि बहुत से बिछाने हैं। लेकिन क्या आप सुनिश्चित हैं कि हर ऐप समय पर और अच्छी तरह से व्यवहार करने के बाद खुद को साफ करे?

— माइक हॉफर

आह, मैंने आपकी टिप्पणी को बहुत देर से देखा है। मैंने ऊपर सिर्फ वही लिखा था। BTW सीमा मुख्य रूप से GetTimeFileName () फ़ंक्शन के यांत्रिकी के कारण है, NTFS नहीं। आपके द्वारा उल्लिखित वह फ़ोल्डर सीमा केवल FAT32 पर लागू होती है ।

— JensG

9

हालांकि, पिछले उत्तर, अधिकांश बड़े कंप्यूटर समूहों के लिए सही नहीं हैं।

कंप्यूटर क्लस्टर आमतौर पर मशीनों के लिए मानक सम्मेलनों का पालन नहीं करते हैं, आमतौर पर अच्छे कारणों के लिए, और सिसड्मिन के साथ इस पर चर्चा करने का कोई मतलब नहीं है।

आपकी वर्तमान निर्देशिका केंद्रीय फ़ाइल सिस्टम की बात कर रही है, जिसे नेटवर्क के माध्यम से एक्सेस किया जाता है। यह न केवल धीमा है, बल्कि बाकी उपयोगकर्ताओं के लिए सिस्टम पर लोड भी डालता है, इसलिए आपको इसका उपयोग तब तक नहीं करना चाहिए जब तक कि आप बहुत अधिक नहीं लिख रहे हैं और नौकरी से दुर्घटनाग्रस्त होने पर आप इससे उबर सकते हैं।

कंप्यूटिंग नोड्स की अपनी हार्ड ड्राइव है, जो कि सबसे तेज़ फ़ाइल सिस्टम उपलब्ध है, और आपको क्या उपयोग करना चाहिए। क्लस्टर प्रलेखन आप को बताना चाहिए कि यह क्या है आम तौर पर /scratch, /tmp/[jobid]या कुछ गैर मानक वातावरण चर ( $SNIC_TMPलोगों को मैं उपयोग में से एक में)।

इसलिए, जो मैं सुझाता हूं वह इसे उपयोगकर्ता-विन्यास बना रहा है। डिफॉल्ट वह पहला व्यक्ति हो सकता है जिसके पास आपकी पहुंच है:

$TMPDIR
tmpfile
/tmp
.

लेकिन इस दृष्टिकोण के साथ कम सफलता दर की उम्मीद करें, और एक बड़ी वसा चेतावनी का उत्सर्जन सुनिश्चित करें।

संपादित करें: मैं इसे उपयोगकर्ता-सेट होने के लिए बाध्य करने के लिए एक और कारण जोड़ूंगा। मेरा एक क्लस्टर $TMPDIRसेट हो गया है /scratch, जो कि उपयोगकर्ता-योग्य है और स्थानीय हार्ड ड्राइव पर है। लेकिन, प्रलेखन का कहना है कि आप जो कुछ भी लिखते हैं /scratch/[jobid], उसे किसी भी बिंदु पर हटा दिया जा सकता है, यहां तक कि रन के बीच में भी। इसलिए, यदि आप मानकों का पालन करते हैं, और विश्वास करते हैं $TMPDIR, तो आप यादृच्छिक दुर्घटनाओं का सामना करेंगे, डीबग करना बहुत कठिन है। तो, आप स्वीकार कर सकते हैं $TMPDIR, लेकिन इस पर भरोसा नहीं।

कुछ अन्य समूहों में इस चर को ठीक से कॉन्फ़िगर किया गया है, इसलिए आप स्पष्ट रूप से विश्वास करने का विकल्प जोड़ सकते हैं $TMPDIR, अन्यथा, एक बड़ी, वसा चेतावनी का उत्सर्जन करें।

— Davidmh
स्रोत

1

पिछले जवाब कौन से हैं?

— तुलसी कोर्डोवा

2

तो यहां आप जो कह रहे हैं, वह इसलिए है क्योंकि कुछ क्लस्टर जो प्रोग्राम को बताने के लिए अच्छी तरह से स्थापित मानक का पालन करने का तुच्छ कदम नहीं उठाते हैं, जहां उनकी अस्थायी फ़ाइलों को लिखने के लिए, प्रति प्रोग्राम एक अतिरिक्त क्लस्टर-विशिष्ट अनुकूलन आवश्यक है। बहुत कमजोर चाय अगर आप मुझसे पूछें।

— ब्लरफ्ल

@ आप जितना चाहें उतना मानकों को तरंगित कर सकते हैं, और कोड लिख सकते हैं जो उनका पूरी तरह से ठीक पालन करता है, और हमेशा क्रैश करता है; आप अपने द्वारा उपयोग किए जाने वाले प्रत्येक क्लस्टर के sysadmins से लड़ने की कोशिश कर सकते हैं; या आप अपने विश्वास को स्वीकार कर सकते हैं और इसे विन्यास योग्य बना सकते हैं। इसके अलावा, एचपीसी में एक को आमतौर पर कोड की बारीकियों के लिए कोड को अनुकूलित करने की आवश्यकता होती है (उपलब्ध रैम, फाइल सिस्टम की सापेक्ष गति, एमपीआई कार्यान्वयन, संसाधनों की सामान्य उपलब्धता ...), कोई "एक आकार सभी फिट बैठता है" नहीं है।

— डेविड एमएच

@ डेविड: अंडरस्टूड, लेकिन बात नहीं। मानक इसे गैर-आश्चर्यजनक तरीके से कॉन्फ़िगर करने योग्य बनाता है । यदि मैं ज्ञात-अनुरूपता कोड को एक क्लस्टर में ले जाता हूं जहां मानक का पालन नहीं किया जाता है, तो मुझे इसे बिल्कुल एक जगह पर सेट करना होगा, जैसे कि प्रवेश बिंदु पर। ऑडिट के बाकी कोड में यह एक कम बात है, संशोधित करना और गलत होना।

— ब्लरफ्ल

1

कई अनुप्रयोगों के लिए, आपको ( $XDG_RUNTIME_DIRया $XDG_CACHE_HOMEअन्य XDG डायर nontemporary फ़ाइलों के लिए हैं) अस्थायी फ़ाइलें डालने पर विचार करना चाहिए । उनकी गणना करने के निर्देश के लिए यदि वे पर्यावरण में स्पष्ट रूप से पारित नहीं हुए हैं, तो XDG आधारित कल्पना देखें या पहले से ही उस हिस्से को लागू करने वाले पुस्तकालय को खोजें।

ध्यान दें, हालांकि, $XDG_RUNTIME_DIRयह एक नया अतिरिक्त है और सुरक्षा चिंताओं के कारण पुराने सिस्टम के लिए कोई मानक वापसी नहीं है।

यदि उनमें से कोई भी उपयुक्त नहीं है, तो /tmpसही जगह है। आपको कभी भी यह नहीं मानना चाहिए कि वर्तमान निर्देशिका लेखन योग्य है।

— o11c
स्रोत

-2

यह एक विकल्प की तरह अधिक है, लेकिन आप फ़ाइल को फ़ॉपन () के बाद अनलिंक कर सकते हैं। यह दरियाफ्त के उपयोग के पैटर्न पर निर्भर करता है।

फ़ाइलों को अनलिंक करना, अगर यह किया जा सकता है, तो कई तरीकों से मदद करता है:

फ़ाइल नहीं देखी गई है - उपयोगकर्ता इसे नहीं देखता है।
फ़ाइल को अन्य प्रक्रियाओं से नहीं देखा जाता है - गलती से फ़ाइल को संशोधित करने की अन्य प्रक्रिया नहीं है।
आसान सफाई अगर कार्यक्रम दुर्घटना।

फ़ाइलें / tmp में बनाई जानी चाहिए। अगर उपयोगकर्ता के पास वहां फ़ाइल बनाने के अधिकार नहीं हैं, तो इसका मतलब है कि सिस्टम गलत है।

उपयोगकर्ता होम निर्देशिका में फ़ाइलें नहीं बनाई जा सकतीं। उपयोगकर्ताओं के बहुत सारे, जैसे "कोई नहीं", "www-data" और कई अन्य लोगों के पास अपने घर निर्देशिकाओं में लिखने का अधिकार नहीं है, या वे भी chroot () - ed हैं। ध्यान दें कि चिरोट के वातावरण में भी / tmp अभी भी मौजूद है।

— छेद
स्रोत

हालांकि यह सामान्य रूप से एक अच्छा विचार हो सकता है, यह उन उपयोगकर्ताओं की मदद नहीं करता है जिनके पास निर्देशिका को लिखने की अनुमति की कमी है फ़ाइल को बनाया जाना है।

— 5gon12eder

4

यह प्रश्न का उत्तर भी नहीं देता है कि अस्थायी फाइलें कहां रखी गई हैं।

— 20

मेरा मानना है कि मेरा जवाब किसी तरह महत्वपूर्ण है। मैंने संपादित किया, शायद इस तरह से अधिक स्पष्ट है।

— निक