Go: प्रस्ताव: ओएस: बनाएं/खोलें/ओपनफाइल() विंडोज़ पर FILE_SHARE_DELETE सेट करें

/सीसी @एलेक्सब्रेनमैन

syscall.Open() https://golang.org/src/syscall/syscall_windows.go#L272 पर
sharemode := ... | FILE_SHARE_DELETE उपयोग करना चाहिए

यह क्यों चाहिए?

एलेक्स

FILE_SHARE_DELETE उपरोक्त कोड उदाहरण को सक्षम करता है, जो मैकोज़ और लिनक्स पर काम करता है लेकिन विंडोज़ पर विफल रहता है। इसके लिए भी आवश्यक है:

fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600)
defer fd.Close()
_, err = fd.Write(...)
err = fd.Sync()  // file now safe to share
err = os.Rename(path, path+"2")
_, err = fd.Read(...)

FILE_SHARE_DELETE उपरोक्त कोड उदाहरण को सक्षम करता है, जो मैकोज़ और लिनक्स पर काम करता है लेकिन विंडोज़ पर विफल रहता है।

हम इसके बजाय MacOS और Linux कोड को समायोजित क्यों नहीं करते?

इसके लिए भी आवश्यक है:

मुझे समझ नहीं आ रहा है कि आप क्या कहना चाह रहे हैं।

एलेक्स

@networkimprov आपको विंडोज़ पर बंद() के बाद निकालें को कॉल करना होगा।

path := "delete-after-open"
fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600)
if err != nil { panic(err) }
fd.Close()
err = os.Remove(path)            // or os.Rename(path, path+"2")
if err != nil { panic(err) }

@alexbrainman विश्वसनीय फ़ाइल I/O (डेटाबेस के लिए) करते समय, अस्थायी नाम वाली फ़ाइल बनाना, उसे लिखना, fsync करना और उसका नाम बदलना मानक अभ्यास है।

यूनिक्स पर डिफ़ॉल्ट रूप से खुली फाइलों का नाम बदला या हटाया जा सकता है। यह एक निरीक्षण की तरह लगता है कि इस क्षमता के लिए विंडोज फ्लैग सेट नहीं है। मुझे संदेह है कि हम गो टीम को लिनक्स और मैकोज़ के लिए काम करने के तरीके को बदलने के लिए मना लेंगे :-)

@mattn कृपया मेरे द्वारा वर्णित फिक्स को लागू करें और मेरे द्वारा पोस्ट किए गए कोड को आजमाएं।

मुझे संदेह है कि हम गो टीम को लिनक्स और मैकोज़ के लिए काम करने के तरीके को बदलने के लिए मना लेंगे :-)

अब जैसी चीजें हैं, मैं ठीक हूं।

एलेक्स

क्या विंडोज़ में इस सामान्य क्षमता को छोड़ने का कोई औचित्य है?

क्या आप syscall_windows.go में एक स्विच प्रदान कर सकते हैं ताकि हम प्रोग्राम शुरू होने पर यूनिक्स व्यवहार का चयन कर सकें?

मैं ठीक हूं कि हम नए एपीआई या झंडे जोड़ते हैं। लेकिन मुझे वर्तमान व्यवहार को बदलने में आपत्ति है। चूंकि FILE_SHARE_DELETE यूनिक्स व्यवहार के समान नहीं है।

#include <windows.h>
#include <stdio.h>

int
main(int argc, char* argv[]) {
  HANDLE h = CreateFile("test.txt",
      GENERIC_READ | GENERIC_WRITE,
      FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
      NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
  getchar();
  char buf[256] = {0};
  DWORD nread;
  printf("%d\n", ReadFile(h, buf, 256, &nread, NULL));
  printf("%s,%d\n", buf, nread);
  return 0;
}

विंडोज़ पर इस कोड को पूरा करें, और test.exe रूप में चलाने का प्रयास करें। जबकि यह ऐप हिट-ए-की प्रतीक्षा कर रहा है, नया cmd.exe खोलें, "test.txt" को निम्न की तरह हटाएं।

फ़ाइल को हटाया जा सकता है लेकिन प्रक्रिया के मौजूद रहने के दौरान वहीं रह जाती है। तो यह बदलाव आपकी अपेक्षा के अनुरूप काम नहीं करेगा।

मुझे एहसास है कि निर्देशिका प्रविष्टि को हटाया नहीं गया है, लेकिन दस्तावेज़ कहते हैं:

फ़ाइल को खोलने के लिए CreateFile के बाद के कॉल ERROR_ACCESS_DENIED के साथ विफल हो जाते हैं।

इसलिए मैं आपका स्क्रीन लॉग नहीं समझता।

वैसे भी, इस तरह एक स्विच ठीक रहेगा:

syscall.OpenFileShareDelete = true

मैं यह उल्लेख करना चाहता हूं कि मुझे इससे पहले काम पर काट लिया गया है।

मूल रूप से हमारे पास था:

f, err := os.Open(...)
if err != nil { ... }
defer f.Close()

// lots of code

if err := os.Rename(...); err != nil { ... }

हमारे यूनिक्स-आधारित सीआई प्लेटफॉर्म पर कोड ठीक चला, लेकिन विंडोज़ पर विस्फोट हो गया।

यह मानते हुए कि कोई अजीब दुष्प्रभाव नहीं हैं, यह अच्छा होगा यदि चीजें अभी काम करती हैं ।

IIRC, हमने यूनिक्स शब्दार्थ से अधिक निकटता से मेल खाने के लिए अतीत में GOOS=windows & plan9 व्यवहार में कुछ समायोजन किए हैं। अगर शब्दार्थ काफी करीब हैं तो मुझे ऐसा एक और मामला बनाने में कोई दिक्कत नहीं होगी। @mattn की टिप्पणी, हालांकि, सुझाव देती है कि व्यवहार पर्याप्त करीब नहीं है, इसलिए यह इसके लायक नहीं हो सकता है।

हालाँकि, मैं कुछ वैश्विक विकल्प नहीं देखना चाहता। यह सिर्फ एक डिबगिंग दुःस्वप्न की तरह लगता है।

@bradfitz
यह शायद नहीं होगा, कृपया मेरी टिप्पणी यहाँ देखें
https://groups.google.com/forum/#!topic/golang -dev/R79TJAzsBfM
या यदि आप चाहें तो मैं यहां सामग्री की प्रतिलिपि बना सकता हूं, क्योंकि एक संभावित समाधान भी है, हालांकि मैं इसे डिफ़ॉल्ट व्यवहार के रूप में लागू नहीं करूंगा, क्योंकि यह विंडोज़ प्रोग्राम के व्यवहार के अनुरूप नहीं होगा, बल्कि एक समान क्रॉस बनाने के लिए एक वर्कअराउंड होगा। -ओस अनुभव।

@guybrand गोलांग-देव सूत्र में लिखते हैं:

मेरा प्रोग्राम "my.data" नामक एक फ़ाइल लिख रहा है, और फिर दूसरे प्रोग्राम को कॉल करता है और इसके समाप्त होने की प्रतीक्षा नहीं करता है ... यह प्रोग्राम इस फ़ाइल को अपलोड करने देता है जिसमें 10 सेकंड लगते हैं (इस अन्य प्रोग्राम को "अपलोडर" कहते हैं) .
...
जब मेरा प्रोग्राम कॉल करता है। विंडोज़ पर निकालें (FILE_SHARE_DELETE चालू है):
...
अपलोडर को यह बताते हुए एक त्रुटि प्राप्त होगी कि फ़ाइल हटा दी गई है (शायद ईओएफ)।

मान लें कि "अपलोडर" "मेरा प्रोग्राम" कॉल ओएस से पहले फ़ाइल खोलता है। निकालें (), मुझे लगता है कि आपने विन एपीआई दस्तावेज़ों का खंडन किया है:

_DeleteFile किसी फ़ाइल को बंद होने पर हटाने के लिए चिह्नित करता है। इसलिए, फ़ाइल हटाना तब तक नहीं होता है जब तक कि फ़ाइल का अंतिम हैंडल बंद न हो जाए। फ़ाइल को खोलने के लिए CreateFile पर बाद की कॉल ERROR_ACCESS_DENIED के साथ विफल हो जाती हैं।

"क्रिएटफाइल के _open_osfhandle() को एक _fdopen में जोड़ना", क्या आप उदाहरण कोड को इंगित कर सकते हैं?

यदि हम FILE_SHARE_DELETE जोड़ते हैं, तो कई प्रोग्रामर गलती से इसका उपयोग यूनिक्स व्यवहार का अनुकरण करने के लिए करेंगे। इस मामले में, आप प्रत्येक ओएस के लिए बिल्ड-बाधाओं से अलग एक फ़ंक्शन बना सकते हैं। और इसे os.NewFile() वापस करना चाहिए, विंडोज़ पर FILE_SHARE_DELETE का उपयोग करें।

प्रत्येक ओएस के लिए बिल्ड-बाधाओं से अलग एक फ़ंक्शन बनाएं ... ओएस पर लौटें। न्यूफाइल (), विंडोज़ पर FILE_SHARE_DELETE का उपयोग करें

os.OpenFile() की कार्यक्षमता को बनाए रखने के लिए इस योजना को सभी को फिर से लागू करने की आवश्यकता प्रतीत होती है:

ओएस ओपनफाइल ()
ओपनफाइलनोलॉग ()
खुली फाइल()
ओपनडिर ()
नई फ़ाइल()
फिक्सलॉन्गपाथ ()
syscall.Open ()
मेकइनहेरिटसा ()

@networkimprov

@guybrand गोलांग-देव सूत्र में लिखते हैं:

मेरा प्रोग्राम "my.data" नामक एक फ़ाइल लिख रहा है, और फिर दूसरे प्रोग्राम को कॉल करता है और इसके समाप्त होने की प्रतीक्षा नहीं करता है ... यह प्रोग्राम इस फ़ाइल को अपलोड करने देता है जिसमें 10 सेकंड लगते हैं (इस अन्य प्रोग्राम को "अपलोडर" कहते हैं) .
...
जब मेरा प्रोग्राम कॉल करता है। विंडोज़ पर निकालें (FILE_SHARE_DELETE चालू है):
...
अपलोडर को यह बताते हुए एक त्रुटि प्राप्त होगी कि फ़ाइल हटा दी गई है (शायद ईओएफ)।

मान लें कि "अपलोडर" "मेरा प्रोग्राम" कॉल ओएस से पहले फ़ाइल खोलता है। निकालें (), क्या आपने विन एपीआई दस्तावेज़ों का खंडन नहीं किया है?

DeleteFile किसी फ़ाइल को बंद होने पर हटाने के लिए चिह्नित करता है। इसलिए, फ़ाइल हटाना तब तक नहीं होता है जब तक कि फ़ाइल का अंतिम हैंडल बंद न हो जाए। फ़ाइल को खोलने के लिए CreateFile के बाद के कॉल ERROR_ACCESS_DENIED के साथ विफल हो जाते हैं।

"क्रिएटफाइल के _open_osfhandle() को एक _fdopen में जोड़ना", क्या आप उदाहरण कोड को इंगित कर सकते हैं?

मुझे विन्डोज़ एपीआई के साथ एक विरोधाभास नहीं दिख रहा है, कृपया इंगित करें कि एक विरोधाभास जैसा दिखता है।

एक कोड नमूने के लिए, मैंने थोड़ा गुगल किया, और यह पाया:
http://blog.httrack.com/blog/2013/10/05/creating-deletable-and-movable-files-on-windows/

लेकिन
कृपया ध्यान दें - यह आपको आंतरिक रूप से केवल एक निक्स जैसा व्यवहार देगा, इसके साथ काम करने वाला कोई अन्य बाहरी प्रोग्राम इसे तोड़ देगा (क्योंकि यह 99% मानक विंडोज़ एपीआई का उपयोग कर रहा है)

@networkimprov
यदि आपका मतलब है "ऐसा लगता है जैसे" dir my.data "फ़ाइल प्रदर्शित करेगा, जहां तक ​​मुझे याद है कि विंडोज़ तक यह व्यवहार था .... XP या 7 (जो याद नहीं है) और तब से बदल गया है (शायद एक्सप्लोरर बस छुपाता है यह किसी भी तरह) - अगली बार जब मैं अपना विंडोज़ एनवी लॉन्च करता हूं तो मैं फिर से परीक्षण कर सकता हूं। (हर कुछ सप्ताह में होता है ...)

यदि आपका मतलब है "यह फ़ाइल के हैंडल के साथ अन्य प्रक्रियाओं की तरह लगता है, फिर भी फ़ाइल को पढ़ने और लिखने में सक्षम होगा", मैं शर्त लगाता हूं कि दूसरी बार आप इस तरह की फाइल को लिखते हैं तो आपको "ईओएफ" शैली त्रुटि मिलती है - लेकिन फिर से 100% सकारात्मक होने की पुष्टि करने की आवश्यकता है।

किसी भी मामले में, मेरा मुद्दा होगा (इस बिंदु पर - मैं "मूल" बनाम "ओएस-अज्ञेयवादी" बिंदु में "पक्ष" ले रहा हूं) - भले ही आप _fdopen शैली समाधान लागू करते हैं, आपको अपनी सेवा के बीच असंगतता मिलेगी और आपके साथ सहयोग करने वाले अन्य सभी निष्पादन योग्य, इसलिए उपयोग केवल अन्य निष्पादन योग्य (या दुर्लभ सेवाएं जो एफडी का सीधे उपयोग करते हैं) के साथ बातचीत में हो सकते हैं।

दूसरे शब्दों में - आपका ऐप "कक्षा में सबसे चतुर बच्चा" होगा - जिसे कोई अन्य बच्चा नहीं समझ सकता।
मैं बहुत से दो उदाहरणों के बारे में सोच सकता हूं:
इनपुट :
मेरा ऐप एक फ़ाइल डाउनलोड करता है, एंटीवायरस अपने हरफुल की पहचान करता है और हटा देता है/संगरोध (== नाम बदलने का प्रकार) इसे, अगर मैं fd का उपयोग करता हूं - मेरा ऐप अभी भी इसके साथ जो कुछ भी चाहता है वह करने में सक्षम होगा (जो कॉल है, लेकिन समाप्त हो सकता है) एक वायरस मार रहा है ...)
आउटपुट :
मेरा ऐप एक फ़ाइल को दूसरे ("अपलोडर" जैसे) सेवा में पाइप करता है, और इसे हटा देता है, मैंने भी परेशान किया और यह देखने के लिए एक परीक्षक लिखा कि सब ठीक काम कर रहा है - और परीक्षण पास हो जाता है।
अब मेरे गो टेस्ट के बजाय, मैं फाइलज़िला का उपयोग करता हूं, हम ट्रांसफर करते हैं, ड्रॉपबीएक्स एपीआई, जो भी हो
यह असफल होगा/उसी तरह व्यवहार नहीं करेगा जिस तरह से मेरा परीक्षण काम करता है ...

क्या आपको अभी भी लगता है कि इसे डिफ़ॉल्ट व्यवहार में बदलना समझ में आता है?

क्या विंडोज़ में इस सामान्य क्षमता को छोड़ने का कोई औचित्य है?

मैंने उस प्रश्न पर कभी विचार नहीं किया। मुझे नहीं पता।

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

एलेक्स

मुझे यह भी संदेह है, यह कई मौजूदा कार्यक्रमों को तोड़ देगा।

@alexbrainman मैंने डिफ़ॉल्ट को बदलने के बजाय इसे सक्षम करने के लिए एक स्विच का भी सुझाव दिया।

@bradfitz syscall.SocketDisableIPv6 है, जो वास्तव में syscall.Open() व्यवहार को समायोजित करने के लिए ध्वज से अलग नहीं है।

चूंकि syscall_windows*.go बताता है
func ओपन (पथ स्ट्रिंग, मोड इंट, पर्म uint32) (एफडी हैंडल, त्रुटि त्रुटि) {
....
शेयरमोड: = uint32 (FILE_SHARE_READ | FILE_SHARE_WRITE)

और type_windows*.go has
FILE_SHARE_DELETE = 0x00000004

सब काफी तैयार है, एक ही सवाल है कि झंडे को कैसे लागू किया जाए।
मुझे वैश्विक विकल्प पसंद नहीं है और साथ ही यह स्पष्ट नहीं है, और जबकि एक एकल डेवलपर को याद हो सकता है कि उसने os.DeleteUponLastHandleClosed = 1 सेट किया है, यह दीर्घकालिक या एकाधिक डेवलपर के लिए एक अच्छा अभ्यास नहीं है।
अन्य विकल्प या तो झंडे के लिए एक विशिष्ट आरक्षित संख्या निर्धारित करेंगे, जैसे:
एफडी, त्रुटि: = os.OpenFile (पथ, os.O_RDWR|os.O_CREATE|os.DELETE_WHEN_FREED, 0600)
जबकि env के लिए DELETE_WHEN_FREED 0 भी हो सकता है। खिड़कियों के अलावा,

एक अन्य विकल्प पर्म पैरामीटर का उपयोग करना होगा, जो विंडोज़ के लिए समर्थित नहीं है, यह थोड़ा अजीब हो सकता है
एफडी, त्रुटि: = ओएस। ओपनफाइल (पथ, ओएस। ओ_आरडीडब्ल्यूआर | ओएस। ओ_क्रिएट, 777)
777 आरक्षित है, इसलिए हमें या तो 1777 या -777 ro दोनों प्रणालियों के समर्थन की आवश्यकता होगी
बनाना पठनीय है DELETE_WHEN_FREED | 777

आखिरी विकल्प जिसके बारे में मैं सोच सकता हूं वह है os.OpenDeletableFile(
जो होगा os.OpenFile निक्स पर और
मोड़
शेयरमोड: = uint32 (FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE)
खिड़कियों पर

उपरोक्त सभी समाधान लागू करने के लिए सरल हैं, परीक्षण के लिए थोड़ा और समय (क्रॉस ओएस), बस एक मतदाता की जरूरत है ...

डिफ़ॉल्ट को बदले बिना या एपीआई सतह को बढ़ाए बिना इस व्यवहार का समर्थन करने का एक तरीका हो सकता है कि विंडोज़ पर flag पैरामीटर में os.OpenFile syscall.FILE_SHARE_DELETE को स्वीकार किया जाए और इसे कंप्यूटेड में फोल्ड किया जाए sharemode मूल्य। चूंकि विंडोज़ पर syscall.O_* (और इसलिए os.O_* ) झंडे वैसे भी मूल्यों का उपयोग करते हैं , उन्हें किसी भी विंडोज़-विशिष्ट झंडे से टकराने से बचने के लिए इंजीनियर किया जा सकता है जिसे कोई शामिल करना चाहता था। सौभाग्य से, वे पहले से ही syscall.FILE_SHARE_DELETE साथ टकराव से बचते हैं।

किसी भी घटना में, मैं डिफ़ॉल्ट व्यवहार को बदलने का कड़ा विरोध करूंगा। FILE_SHARE_DELETE को डिफ़ॉल्ट बनाना आपको रेस-फ्री फाइल सिस्टम ट्रैवर्सल सुनिश्चित करने में असमर्थ होने के मामले में POSIX सिस्टम के समान स्थिति में डाल देगा। यह ध्वज वैकल्पिक होने के कारण विंडोज़ को openat , renameat , readlinkat , आदि के समकक्ष की आवश्यकता नहीं है।

मैंने वास्तव में इस बारे में नहीं सोचा है कि हमें यहाँ क्या करना चाहिए, लेकिन मैं एक बात स्पष्ट करना चाहता हूँ:

क्या आप syscall_windows.go में एक स्विच प्रदान कर सकते हैं ताकि हम प्रोग्राम शुरू होने पर यूनिक्स व्यवहार का चयन कर सकें?

हम ऐसा नहीं करेंगे। इससे एक प्रोग्राम के लिए अलग-अलग व्यवहार की अपेक्षा करने वाले विभिन्न पैकेजों का उपयोग करना असंभव हो जाएगा।

@हावोक-आईओ
आपका सुझाव त्रुटि प्रवण प्रोग्राम तैयार करेगा क्योंकि syscall.FILE_SHARE_DELETE POSIX std व्यवहार से अलग है।
कृपया ध्यान दें कि syscall_windows*.go के लेखक FILE_SHARE_DELETE ध्वज (इसमें मौजूद हैं) के बारे में जानते थे और उन्होंने निर्णय लिया कि इसका उपयोग करना पसंदीदा व्यवहार नहीं होगा।
क्यों?

चलो लियाम का कोड लेते हैं, हे
एफडी स्थगित करें। बंद करें ()
हटाता/नाम बदलता है
और फिर पढ़ें/लिखें

तो वास्तविक सॉर्ट ऑर्डर है
खुला हुआ
हटाए गए के रूप में चिह्नित करें
पढ़ें/लिखें (और शायद क्रॉस प्रोसेस/क्रॉस गो रूटीन रीड राइट भी लिखें)
बंद करे

वर्तमान विंडोज़ व्यवहार डेवलपर को अलर्ट करता है "यह गलत है", डेवलपर शायद डिलीट को भी स्थगित करने के लिए धक्का देगा
यदि आप FILE_SHARE_DELETE जोड़ते हैं, तो विंडोज़ आपको "फाइल के खुलने के बावजूद डिलीट के रूप में चिह्नित करने" की अनुमति देगा, लेकिन एक अन्य प्रक्रिया / गोरोइन समवर्ती रूप से चल रही है जो फ़ाइल को डिलीट और क्लोज के बीच एक्सेस करने का प्रयास करेगी (जो शायद इस कोड में लंबा काम है) ) विफल हो जाएगा
परिणाम: एक सुसंगत "आप ऐसा कर सकते हैं" व्यवहार के बजाय - आपको "कभी-कभी - विशेष रूप से जब कई समवर्ती उपयोगकर्ता होते हैं तो यह विफल हो जाता है और मुझे नहीं पता कि क्यों।
तो आप समस्या का समाधान नहीं कर रहे हैं, बस एक विशिष्ट उपयोग के मामले को संभाल रहे हैं जिस पर डेवलपर "केवल एक बार चलाएं"
मेरा वोट निश्चित रूप से लगातार व्यवहार के लिए है ...

यह Posix से किस प्रकार भिन्न है?
एक बार हटाए गए के रूप में चिह्नित की गई फ़ाइल अब फ़ाइल तालिका पर नहीं है, यह केवल एक fd के रूप में मौजूद है, जिससे अन्य रूटीन/प्रक्रिया को उसी नाम से फ़ाइल बनाने की अनुमति मिलती है।

मुझे लगता है कि हमें "समान समाधान" की तलाश बंद कर देनी चाहिए क्योंकि ऐसे मतभेद हैं जिन्हें हम जाने के भीतर हल नहीं करेंगे (केस संवेदनशील फ़ाइल नाम? :) हम लिनक्स 5.2 को ऐसा करने देंगे ...)

कुल मिलाकर ऐसा लगता है कि एक अस्थायी फ़ाइल के लिए एक समाधान की तलाश है, यदि यह है, तो विंडोज़ GetTempFileName का समर्थन करती है जिसे "उपयोग की गई और फिर ट्रैश की गई" फ़ाइल के लिए मानक समाधान के रूप में माना जा सकता है।

यदि दूसरी ओर हम किसी डेवलपर को विंडोज़ में डिलीट को स्थगित करने की अनुमति देना चाहते हैं, तो यह संभव है, ऊपर मेरे सुझाव देखें, लेकिन डेवलपर को इसकी जिम्मेदारी लेनी

इस सुविधा का प्राथमिक उपयोग किसी खुली फ़ाइल को बनाने के बाद उसका नाम बदलना है:

fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600)
_, err = fd.Write(...)
err = fd.Sync()  // file now safe to share
err = os.Rename(path, shared_path)
// os.Close() at program exit

मुझे नहीं पता कि आप os.O_WRNDEL फ्लैग क्यों नहीं जोड़ेंगे (विंडोज़ का नाम बदलें/हटाएं; अन्य प्लेटफॉर्म पर नो-ऑप), और यूनिक्स के साथ उस मोड के अंतर को दस्तावेज करें; कि एक हटाई गई फ़ाइल उसकी निर्देशिका में बनी रहती है, लेकिन जब तक os.Close() नहीं खोली जा सकती। यह भी उल्लेख करें कि फ़ाइल को हटाने से पहले एक अस्थायी डीआईआर में ले जाना अधिक यूनिक्स जैसा व्यवहार प्रदान करता है।

@guybrand मुझे लगता है कि शायद आप मेरे प्रस्ताव को गलत समझ रहे हैं। मैं इस बात की वकालत नहीं कर रहा हूं कि FILE_SHARE_DELETE डिफ़ॉल्ट रूप से सक्षम हो - वास्तव में मैं अपनी टिप्पणी के दूसरे पैराग्राफ में उल्लिखित कारणों से इसका विरोध कर रहा हूं। मेरा प्रस्ताव एक ऐसे तंत्र के लिए था जो उपयोगकर्ताओं को FILE_SHARE_DELETE व्यवहार (प्रति-फ़ाइल आधार पर) के लिए ऑप्ट-इन करने की अनुमति देता है, जबकि अभी भी os पैकेज की फ़ाइल संरचना का उपयोग कर रहा है। यह प्रस्ताव किसी भी पैकेज की एपीआई सतह का विस्तार किए बिना ऐसा करने के लिए एक तंत्र प्रदान करता है।

मुझे नहीं पता कि आप os.O_WRNDEL ध्वज क्यों नहीं जोड़ेंगे (विंडोज़ का नाम बदलें/हटाएं; अन्य प्लेटफॉर्म पर नो-ऑप)

@networkimprov यह अनिवार्य रूप से मैं प्रस्तावित कर रहा हूं, सिवाय इसके कि एक नए ध्वज को परिभाषित करने का कोई मतलब नहीं है क्योंकि पूरी तरह से वैध पहले से मौजूद है: syscall.FILE_SHARE_DELETE । केवल कार्यान्वयन परिवर्तन इस ध्वज को विंडोज़ पर syscall.Open में देखना और यह सुनिश्चित करने के लिए चेक जोड़ना होगा कि भविष्य में syscall.O_* / os.O_* झंडे में कोई भी जोड़ इस ध्वज से नहीं टकराएगा। os.OpenFile दस्तावेज़ीकरण को तब Windows पर इस ध्वज की स्वीकृति को दर्शाने के लिए अद्यतन किया जा सकता है।

@ कहर-आईओ गलतफहमी के लिए खेद है, यह मेरा टेकआउट था:
"... syscall.FILE_SHARE_DELETE ... को कंप्यूटेड शेयरमोड में स्वीकार करने के लिए..."

मेरे दूसरे सुझाव के साथ os.O_WRNDEL मैचों को जोड़ने के अलावा "व्यवहार क्या होगा" के संदर्भ में डेवलपर के लिए पर्याप्त स्पष्ट नहीं होने के अलावा, शायद os.WADRNDEL - विंडोज़ आस्थगित नाम बदलने / हटाने की अनुमति देता है)।

@alexbrainman मैंने डिफ़ॉल्ट को बदलने के बजाय इसे सक्षम करने के लिए एक स्विच का भी सुझाव दिया

मुझे कोई दिलचस्पी नहीं हूँ। शुक्रिया।

एलेक्स

@guybrand एक खुली फ़ाइल का नाम बदलना स्थगित नहीं है, मैंने जाँच की।

माफ़ करें, मैं फिर से पूछ रहा हूँ कि आपका क्या सुझाव है? ओपनिंग फाइल को डिलीट करें? उद्घाटन फ़ाइल का नाम बदलें? दोनों?

हम में से तीन अब एक नए झंडे का सुझाव दे रहे हैं, जैसे

fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE| os._WRNDEL, 0600)

fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE| syscall.FILE_SHARE_DELETE, 0600)

हम तीनों अब एक नए झंडे का सुझाव दे रहे हैं

मुझे लगता है कि एक नया झंडा अनुचित है, विशेष रूप से वह जो कोड पढ़ने वाले किसी व्यक्ति द्वारा आसानी से पार्स करने योग्य नहीं है। syscall.FILE_SHARE_DELETE करना कहीं अधिक स्पष्ट और स्पष्ट होगा, पाठक को तुरंत संकेत देगा कि कुछ प्लेटफ़ॉर्म-विशिष्ट हो रहा है।

POSIX प्लेटफॉर्म पर इसकी अनुमति पहले से ही है। कई POSIX- विशिष्ट (और यहां तक ​​कि प्लेटफ़ॉर्म-विशिष्ट) open फ़्लैग हैं जिन्हें os पैकेज में शामिल नहीं किया गया है। उदाहरण के लिए, डार्विन के O_EVTONLY ध्वज का समर्थन करने के लिए os._DEVTONLY जैसा कुछ जोड़ने का कोई मतलब नहीं होगा, क्योंकि आप ध्वज को syscall पैकेज से सीधे os.OpenFile , जैसे:

os.OpenFile(..., os.O_RDONLY | syscall.O_EVTONLY, ...)

इस मामले में, प्लेटफ़ॉर्म-विशिष्ट फ़्लैग को अंतर्निहित open सिस्टम कॉल में पास कर दिया जाएगा।

यदि FILE_SHARE_DELETE व्यवहार वास्तव में कुछ ऐसा है जिसकी लोगों को आवश्यकता है, तो मुझे लगता है कि इसका उत्तर केवल os.OpenFile को विंडोज़ पर अंतर्निहित CreateFileW कॉल के समान थ्रेड फ़्लैग करने में सक्षम बनाना है। कम से कम FILE_SHARE_DELETE ।

एक उदाहरण कार्यान्वयन यहां पाया जा सकता

@networkimprov

हम में से तीन अब एक नए झंडे का सुझाव दे रहे हैं, जैसे

आप झंडे की क्या उम्मीद करते हैं?

@guybrand एक खुली फ़ाइल का नाम बदलना स्थगित नहीं है, मैंने जाँच की।

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

@guybrand मुझे वास्तव में os पैकेज में एक जटिल नाम और अपारदर्शी व्यवहार के साथ एक नया प्लेटफ़ॉर्म-विशिष्ट ध्वज जोड़ने का मूल्य नहीं दिखता है, जब इसके लिए एक बिल्कुल अच्छा झंडा दशकों से है ( FILE_SHARE_DELETE )। इसके लिए ध्वज के रूप में syscall.FILE_SHARE_DELETE का उपयोग करना कहीं अधिक स्पष्ट और स्पष्ट है। जैसा कि मैंने ऊपर उल्लेख किया os पैकेज में नहीं जोड़े गए हैं लेकिन फिर भी इसके द्वारा स्वीकार किए जाते हैं।

syscall.FILE_SHARE_DELETE केवल विंडोज़ है; हमें कुछ ऐसा चाहिए जो कहीं और न हो। शायद यह जीत या विन्डोज़ उपसर्ग के साथ पीकेजी ओएस में दिखना चाहिए?

@mattn कृपया ऊपर दिए गए पैच को @ havoc-io . से देखें

हमें कुछ ऐसा चाहिए जो कहीं और न हो।

@networkimprov ध्वज को कहीं और मौजूद होने की आवश्यकता नहीं है। आपका विंडोज कोड कुछ इस तरह दिखेगा:

import (
    "syscall"
    "os"
)

file, err := os.OpenFile(..., os.O_RDWR | syscall.FILE_SHARE_DELETE, ...)

हां, इस कोड को प्लेटफॉर्म पर गेट करने की आवश्यकता होगी, लेकिन आपको शायद ऐसा करने की आवश्यकता होगी, क्योंकि इस ध्वज के साथ व्यवहार POSIX सिस्टम से मेल नहीं खाएगा। या, यदि आप सभी प्लेटफार्मों पर समान कोड रखने की सुविधा चाहते हैं, तो आप अपने स्वयं के स्थिरांक को परिभाषित कर सकते हैं (विंडोज़ पर syscall.FILE_SHARE_DELETE मूल्य के साथ और गैर-विंडोज सिस्टम पर 0 साथ) और पास करें यह करने के लिए os.OpenFile । यदि आप एक प्लेटफ़ॉर्म-विशिष्ट O_* फ़्लैग लाना चाहते हैं जो os पैकेज का हिस्सा नहीं था (उदाहरण के लिए डार्विन पर O_EVTONLY O_ASYNC लिनक्स पर)।

जब मैं कोड लिखता हूं तो मुझे उम्मीद है कि यह क्रॉस प्लेटफॉर्म होगा, FILE_SHARE_DELETE syscall_* में मौजूद नहीं है केवल विंडोज़ एक (इसलिए अन्य सिस्टम पर संकलित नहीं होगा)।

क्या हम इसके रूप में 0x4 कास्ट का उपयोग कर सकते हैं:
FILE_SHARE_DELETE = 0x00000004

बदसूरत होने के अलावा,
netbsd_arm
O_NDELAY = 0x4
ओ_नॉनब्लॉक = 0x4

तो 0x4 का उपयोग करने से वह कोड बन जाएगा जो netbsd_arm.

तो या तो हम सभी प्लेटफार्मों में FILE_SHARE_DELETE जोड़ते हैं, विंडोज़ वाले 0x4 होंगे अन्य 0x0 होंगे और इस प्रकार इसे "त्यागें", या इस मुद्दे के लिए एक विशिष्ट ध्वज बनाएं।

और किसी भी तरह हमें syscall_windows* को बदलना होगा
फंक ओपन (
...
शेयरमोड: = uint32 (FILE_SHARE_READ | FILE_SHARE_WRITE | isDeleteOn)
जहां isDeleteOn जांच करेगा कि मोड में नया ध्वज शामिल है या नहीं

@ गाइब्रांड

जब मैं कोड लिखता हूं तो मुझे उम्मीद है कि यह क्रॉस प्लेटफॉर्म होगा

मैं आपको सावधान करूंगा कि सिर्फ इसलिए कि एक ही os.OpenFile कॉल कई प्लेटफॉर्म पर संकलित है, इसका मतलब यह नहीं है कि आपका कोड क्रॉस-प्लेटफॉर्म है। विंडोज़ पर कई सुरक्षा विचार हैं जिन्हें आपको FILE_SHARE_DELETE का उपयोग करते समय ध्यान में रखना होगा, और फ़ाइल जीवन चक्र के अर्थशास्त्र पॉज़िक्स और विंडोज सिस्टम के बीच इतने अलग हैं कि ऐसे परिदृश्य की कल्पना करना वाकई मुश्किल है जहां आपका फ़ाइल हैंडलिंग कोड प्लेटफ़ॉर्म के बीच कम से कम थोड़ा अलग नहीं दिखेगा। FILE_SHARE_DELETE अनिवार्य रूप से आपको एक पूर्व-POSIX.1-2008 स्थिति में डालता है, बिना किसी रेस-फ्री फाइल सिस्टम ट्रैवर्सल को सुनिश्चित करने के लिए (और POSIX के पोस्ट के लाभ के बिना- unlink ओपन के लिए फाइल एक्सेस फ़ाइलें)।

वैसे भी, आप एक ध्वज के एक मूल्य है कि चाहते हैं syscall.FILE_SHARE_DELETE विंडोज पर और 0 अन्य प्लेटफार्मों पर, आप अभी भी आसानी से ऐसा कर सकते हैं अपने खुद के निरंतर परिभाषा यह है कि निर्माण टैग के द्वारा नियंत्रित किया जाता है, और फिर साथ आपका मुख्य कोड जो os.OpenFile कॉल करता है, वह सभी प्लेटफ़ॉर्म पर समान हो सकता है (उस कस्टम फ़्लैग का उपयोग करके)।

ऐसे कई प्लेटफ़ॉर्म-विशिष्ट फ़्लैग हैं जो अन्य प्लेटफ़ॉर्म के syscall पैकेज में मौजूद हैं, लेकिन वे सभी os पैकेज द्वारा उजागर नहीं किए जा सकते हैं और उन प्लेटफ़ॉर्म पर नो-ऑप्ड नहीं किए जा सकते हैं जहां वे हैं' टी समर्थित। यदि आप प्लेटफ़ॉर्म-विशिष्ट कोड और व्यवहार चाहते हैं, तो syscall पैकेज तक पहुंचना आवश्यक है।

केवल एक चीज जो गो मानक पुस्तकालय को (संभावित रूप से) करनी चाहिए, वह है विंडोज़ पर syscall.FILE_SHARE_DELETE में syscall.Open (और फलस्वरूप os.OpenFile ) का समर्थन करना।

जैसा कि मैंने ऊपर उल्लेख किया

@mattn मैं आपकी चिंताओं से सहमत हूं - लोग सूक्ष्म प्रभावों को समझे बिना POSIX सिस्टम के रूप में विंडोज कोड "समान काम" करने के लिए ध्वज का उपयोग सुविधा के रूप में करने का प्रयास कर सकते हैं। हालांकि, मुझे लगता है कि अगर उन्हें उस झंडे तक पहुंचने के लिए syscall पैकेज में जाना पड़ता है, तो उन्हें यह समझने में समय लग सकता है कि यह क्या करता है।

@mattn , यूनिक्स जैसे व्यवहार के लिए, ऐप्स को प्लेटफ़ॉर्म-तटस्थ कोड की 2 अतिरिक्त पंक्तियों की आवश्यकता होगी:

fd, err := os.OpenFile(path, ... | syscall.FILE_SHARE_DELETE, 0600)
...
tmp_path := mkTempName()
err = os.Rename(path, tmp_path)  // works immediately; path is now available
err = os.Remove(tmp_path)

इसका दस्तावेज़ीकरण करने के लिए os.OpenFile() के दस्तावेज़ों में एक वाक्य की आवश्यकता होती है।

कृपया मुझे pkg syscall को एक पैच वितरित न करने के लिए कहें कि मेरे विंडोज़ कोड पर काम करने वाले सभी लोगों को इसे लागू करना होगा! https://github.com/golang/go/issues/32088#issuecomment -493876119 भी देखें।

मुझे लगता है कि हम सभी अधिकांश तथ्यों पर सहमत हैं, बस इसे अलग-अलग वाक्यांश दें, इसलिए मैं संक्षेप में बताने की कोशिश करूंगा, और कार्रवाई की रूपरेखा तैयार करूंगा:

1. सहमत: Windows और POSIX उपरोक्त व्यवहार में भिन्न हैं और हमें समान व्यवहार के लिए लक्ष्य बनाने का प्रयास नहीं करना चाहिए।
2. सहमत : FILE_SHARE_DELETE को ध्वज के रूप में अनुमति देने का अनुरोध उपयोगी है
3. सुझाव: टिकट को "समर्थन FILE_SHARE_DELETE" में बदलने दें, ताकि यह बग के बजाय एक सुविधा अनुरोध की तरह लगे
4. अधिकतर सहमत : फीचर प्रोग्राम स्तर पर एक डेवलपर फ्लैग होना चाहिए, न कि गो बेस पैकेज।

कार्रवाई आइटम:

1. syscall_windows.go . बदलें
   फंक ओपन (
   ...
   शेयरमोड: = uint32 (FILE_SHARE_READ | FILE_SHARE_WRITE | (मोड और FILE_SHARE_DELETE) )
2. डेवलपर जो इस व्यवहार का उपयोग करना चाहेगा, वह या तो
   file, err := os.OpenFile(..., os.O_RDWR | syscall.FILE_SHARE_DELETE, ...)
   या यदि वे चाहते हैं कि उनका कार्यक्रम क्रॉस प्लेटफॉर्म हो तो एक आंतरिक ध्वज तैयार करेगा:

mycode_windows.go
const OPENFILEFLAG = syscall.FILE_SHARE_DELETE
mycode_others.go
const OPENFILEFLAG = 0

और फिर उपयोग करें:
file, err := os.OpenFile(..., os.O_RDWR | OPENFILEFLAG, ...)

यदि यह सहमत है, तो फिक्स न्यूनतम (एक लाइनर) है, बहुत कम जोखिम के साथ

इस पर मतदान करने दें, और हम इसे शीघ्रता से ठीक कर सकते हैं

सहमत : FILE_SHARE_DELETE को ध्वज के रूप में अनुमति देने का अनुरोध उपयोगी है

मैं अभी तक इससे सहमत नहीं हूं क्योंकि मुझे समझ नहीं आ रहा है कि इस मुद्दे का उद्देश्य क्या है?

@mattn कृपया देखें https://github.com/golang/go/issues/32088#issuecomment -494305074

उद्देश्य: डेवलपर्स को खोली गई फ़ाइलों का नाम बदलने या हटाने की अनुमति दें।

क्या गुम है: syscall_windows.go वर्तमान में हार्ड कोडित है :
func Open(path string, mode int, perm uint32) (fd Handle, err error) {
...
sharemode := uint32(**FILE_SHARE_READ | FILE_SHARE_WRITE**)

प्रस्तावित परिवर्तन:
जब डेवलपर बिटवाइज़ 4 (FILE_SHARE_DELETE) के साथ एक मोड पैरामीटर पास करता है, तो शेयरमोड तदनुसार बदल जाएगा
sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | **(mode & FILE_SHARE_DELETE)** )

मैं अभी भी सोच रहा हूं कि आप नाम बदलें() या निकालें() से पहले बंद() को कॉल क्यों नहीं करते हैं। आप गो के मानक पुस्तकालय का कोड पढ़ सकते हैं। नाम बदलें () या निकालें () से पहले फाइलें बंद () द्वारा बंद कर दी जाती हैं। Renamee/Rename के बाद आपको Close() को कॉल क्यों करना चाहिए?

मुझे यकीन नहीं है कि व्यावसायिक मामला क्या है @networkimprov विचार कर रहा है, इस पर मेरा टेकआउट एक अस्थायी साझा फ़ाइल होगी - मेरा ऐप और दूसरा ऐप इस फ़ाइल का उपयोग कर रहा है, मैं यह सुनिश्चित करना चाहता हूं (भले ही मेरा ऐप क्रैश हो) यह फ़ाइल मेरे द्वारा किए जाने के बाद अब और मौजूद नहीं होगा - इसलिए मैं इसे बना देता हूं, इसे हटाएं() और जब मैं इसे बंद करता हूं या मेरा ऐप बंद होता है - फ़ाइल हटा दी जाती है।

लेकिन ऐसा लगता है कि @networkimprov नाम बदलें() का उपयोग करना चाहता है, इसलिए शायद एक अलग उपयोग केस।

जैसा कि https://github.com/golang/go/issues/32088#issuecomment -494305074 में उल्लेख किया गया है, हमें प्रोग्राम से बाहर निकलने तक एक नामित फ़ाइल को बंद करने की आवश्यकता नहीं हो सकती है।

@mattn , कृपया इस बात पर जोर न दें कि हमें कभी भी ऐसी OS सुविधा का उपयोग नहीं करना चाहिए जिसका उपयोग C और C ++ डेवलपर्स कर सकें।

मैं यह सुनिश्चित करना चाहता हूं (भले ही मेरा ऐप क्रैश हो जाए) मेरे काम पूरा होने के बाद यह फ़ाइल मौजूद नहीं रहेगी

@guybrand A defer स्टेटमेंट हर प्रकार के क्रैश में चलने की गारंटी नहीं है, इसलिए यदि आप फ़ाइल को हटाना सुनिश्चित करने का प्रयास कर रहे हैं, तो os.Remove ऑपरेशन को स्थगित करना एक विश्वसनीय तरीका नहीं है इसके बारे में जाओ। यदि आप ऐसी फ़ाइल चाहते हैं जो स्वचालित रूप से हटाई जाए, तो एक अस्थायी फ़ाइल जिसे सिस्टम हटाता है, एक बेहतर विकल्प है। यदि आप एक फ़ाइल स्थान चाहते हैं जो दो कार्यक्रमों द्वारा साझा किया गया है, तो इसे तालों द्वारा समन्वित किया जाना चाहिए (उदाहरण के लिए POSIX पर fcntl ताले और विंडोज़ पर LockFileEx / UnlockFileEx ), फ़ाइल अस्तित्व नहीं .

जैसा कि #32088 (टिप्पणी) में उल्लेख किया गया है, प्रोग्राम से बाहर निकलने तक हमें एक नामित फ़ाइल को बंद करने की आवश्यकता नहीं हो सकती है।
@mattn , कृपया इस बात पर जोर न दें कि हमें कभी भी ऐसी OS सुविधा का उपयोग नहीं करना चाहिए जिसका उपयोग C और C ++ डेवलपर्स कर सकें।

@networkimprov एक नाम बदलें-बाद-खुला ऑपरेशन एक वैध उपयोग मामला है, लेकिन यदि आप HANDLE फ़ाइल रखने वाले प्रोग्राम हैं, तो क्या आप पहले से ऐसा नहीं कर सकते हैं? FILE_SHARE_DELETE का एकमात्र उद्देश्य अन्य प्रक्रियाओं को फ़ाइल को खुला रखने के दौरान उसका नाम बदलने की अनुमति देना होगा। किसी भी स्थिति में, आप अभी FILE_SHARE_DELETE उपयोग कर सकते हैं, आपको बस मैन्युअल रूप से CreateFileW आह्वान करना होगा और परिणाम को os.NewFile भेजना होगा। आप इस लगता है कि उसका एक उदाहरण पा सकते हैं यहाँ । परिणामी HANDLE को केवल os.NewFile पास किया जा सकता है।

@mattn मैं आपसे सहमत होना शुरू कर रहा हूं कि यह झंडा एक उपयोगी उपकरण की तुलना में एक फुटगन से अधिक होगा। बस स्पष्ट होने के लिए, मुझे वास्तव में यह ध्वज नहीं चाहिए, और इसके अस्तित्व के लिए मैं केवल एक ही तर्क देख सकता हूं जो POSIX और Windows के बीच नियंत्रण की पूर्णता और समानता है। दूसरी ओर, जैसा कि मैंने ऊपर उल्लेख किया है, मैन्युअल रूप से CreateFileW (इस ध्वज निर्दिष्ट के साथ) को मैन्युअल रूप से लागू करना भी अपेक्षाकृत आसान है और फिर परिणाम को os.NewFile सौंप दें, इसलिए शायद इसकी कोई आवश्यकता नहीं है इसके लिए समर्थन जोड़ें।

@ कहर- io कोई os.File.Rename() नहीं है। यह एक अच्छा समाधान होगा, लेकिन यह अपेक्षाकृत भारी लिफ्ट है।

फिर से CreateFileW + os.NewFile (), https://github.com/golang/go/issues/32088#issuecomment -493876119 देखें।

@हावोक-आईओ

मैं यह सुनिश्चित करना चाहता हूं (भले ही मेरा ऐप क्रैश हो जाए) मेरे काम पूरा होने के बाद यह फ़ाइल मौजूद नहीं रहेगी
@guybrand हर प्रकार की दुर्घटना में एक स्थगित बयान चलने की गारंटी नहीं है
यही मेरा मतलब था, जब मैंने कहा "भले ही मेरा ऐप क्रैश हो जाए"।

इसके अस्तित्व के लिए मैं केवल एक ही तर्क देख सकता हूं कि POSIX और Windows के बीच नियंत्रण की पूर्णता और समानता है
मैं असहमत हूं कि यह "पॉज़िक्स और विंडोज़ के बीच नियंत्रण की पूर्णता और समानता" लाएगा - आईएमओ यह केवल डेवलपर को यह सोचने के लिए भ्रमित करेगा कि व्यवहार वही है जब ऐसा नहीं है, मैंने ऊपर कुछ उदाहरण दिए हैं।

CreateFileW को मैन्युअल रूप से लागू करना आसान है
यह वास्तव में एक ट्वीक है, आसान है या नहीं, और दूसरे शब्दों में कह रहा है: "हम इसका समर्थन नहीं करना चाहते हैं", जो कि एक ठीक निर्णय आईएमओ है, लेकिन अनुरोधकर्ता @networkimprov मुझे नहीं है।

FYI करें, यही कारण है कि हमने FILE_SHARE_DELETE का उपयोग करना छोड़ दिया।

सीएल: https://codereview.appspot.com/823043/

एरलांग/ओटीपी में प्रतिबद्ध: https://github.com/erlang/otp/commit/0e02f488971b32ff9ab88a3f0cb144fe5db161b2

पायथन: https://bugs.python.org/issue15244

@ कहर- io कोई os.File.Rename() नहीं है। यह एक अच्छा समाधान होगा, लेकिन यह अपेक्षाकृत भारी लिफ्ट है।
पुन: CreateFileW + os.NewFile (), # 32088 (टिप्पणी) देखें।

@networkimprov क्या आप केवल os.Rename(file.Name(), <target>) उपयोग नहीं कर सकते? डिफ़ॉल्ट रूप से FILE_SHARE_DELETE चालू न होने की यही खूबी है - आप जानते हैं कि file.Name() अभी भी किसी मान्य चीज़ की ओर इशारा करेगा क्योंकि आपके पास फ़ाइल HANDLE (कुछ आप कर सकते हैं) renameat साथ भी, पॉज़िक्स पर टी गारंटी)। CreateFileW + os.NewFile , आपकी टिप्पणी में वर्णित अधिकांश स्टैक अप्रासंगिक हो जाएगा, और makeInheritSa लगभग निश्चित रूप से कुछ ऐसा है जो आप fixLongPath पथ फ़ंक्शन होगा, जो संभवतः आपके द्वारा वर्णित उपयोग के मामलों के लिए आवश्यक नहीं होगा।

@guybrand बस मेरा मतलब स्पष्ट करने के लिए ...

पूर्णता: एपीआई सतह पूर्णता (यानी FILE_SHARE_DELETE का उपयोग करने की क्षमता यदि आप किसी कारण से इसका उपयोग करना चाहते हैं)
नियंत्रण की समता: CreateFileW माध्यम से os.OpenFile के flag पैरामीटर के माध्यम से झंडे को निर्दिष्ट करने की क्षमता। उदाहरण के लिए, मैं POSIX पर syscall.O_NOFOLLOW से os.OpenFile रूट कर सकता हूं, लेकिन मैं विंडोज़ पर syscall.FILE_FLAG_OPEN_REPARSE_POINT से os.OpenFile रूट नहीं कर सकता। हालांकि फिर से, मुझे लगता है कि यहां नियंत्रण की कुल समानता एक पाइप सपना है क्योंकि os पैकेज पॉज़िक्स एपीआई के आसपास तैयार किया गया है। जब आवश्यक हो तो मैं syscall.CreateFileW तक पहुंचकर काफी खुश हूं।

@mattn लिंक के लिए धन्यवाद। Go CL को syscall.Open() _default_ को पैच करना था। चर्चा ओपन() के लिए _flag_ को अस्वीकार करने का कोई सामान्य कारण नहीं देती है। यह नोट करता है कि एक तृतीय-पक्ष पैकेज ध्वज की कमी वाली os.File वापस कर सकता है, लेकिन यह केवल एक समस्या है यदि कॉलर उस फ़ाइल का नाम बदलने/हटाने का प्रयास करता है - एक दुर्लभ कोने का मामला।

पायथन थ्रेड नोट करता है कि आपको एक खुली फ़ाइल को हटाने से पहले उसका नाम बदलना चाहिए, जैसा कि मैंने ऊपर लिखा है।

Erlang ने पिछले छह वर्षों से file_share_delete को _default_ के रूप में रखा है।

ऊपर से जुड़े एरलांग अनुभव और पायथन धागे पर विचार करते हुए, यह स्पष्ट है कि:

1. File_share_delete डिफ़ॉल्ट रूप से क्रॉस-प्लेटफ़ॉर्म वातावरण में अच्छी तरह से काम करता है; एकमात्र चेतावनी यह है कि यदि मूल फ़ाइल नाम का पुन: उपयोग किया जा सकता है तो उपयोगकर्ता कोड को इसे हटाने (एक मामूली परिवर्तन) से तुरंत पहले एक अद्वितीय नाम पर फ़ाइल का नाम बदलना चाहिए।
2. अधिकांश विंडोज़ प्रोग्राम केवल इसलिए file_share_delete का उपयोग नहीं कर सकते क्योंकि MSVC रनटाइम केवल O_TEMPORARY के संयोजन में इसकी अनुमति देता है।

इसलिए मैं यह निष्कर्ष निकालूंगा कि syscall.Open() को डिफ़ॉल्ट रूप से file_share_delete का उपयोग करना चाहिए, और जहां आवश्यक हो (जैसे डिबगिंग) इसे अक्षम करने के लिए syscall को

यदि 1.14 चक्र के दौरान उस दृष्टिकोण के साथ समस्याएं आती हैं, तो इसके बजाय स्पष्ट ध्वज विधि लागू की जा सकती है।

इसलिए मैं यह निष्कर्ष निकालूंगा कि syscall.Open() को डिफ़ॉल्ट रूप से file_share_delete का उपयोग करना चाहिए, और जहां आवश्यक हो (जैसे डिबगिंग) इसे अक्षम करने के लिए syscall को वैश्विक ध्वज प्रदान करना चाहिए।

@networkimprov सूक्ष्म और गैर-सूक्ष्म तरीकों से मौजूदा कार्यक्रमों की एक बड़ी संख्या को तोड़ने के अलावा, तथ्य यह है कि अब इस ध्वज को पेश करना FILE_SHARE_DELETE की अनुपस्थिति पर निर्भर कार्यक्रमों के लिए एक सुरक्षा मुद्दा होगा। . विशेष रूप से, यह फाइलों और निर्देशिकाओं की अपरिवर्तनीयता पर निर्भर कार्यक्रमों के लिए कई बार-बार-चेक-टू-टाइम-ऑफ-यूज कमजोरियों को खोल देगा, जिन्हें वे खुले रख रहे हैं।

संपादित करें: आगे पढ़ने के लिए कि डिफ़ॉल्ट को बदलना एक बुरा विचार क्यों है और मौजूदा कार्यक्रमों को तोड़ना लगभग निश्चित है, कृपया Hyrum's Law देखें ।

विंडोज़ पर गो का सबसे आम मामला विकास है, लिनक्स या अन्य यूनिक्स पर

यदि आपका कोड किसी भी GOOS=windows व्यवहार पर निर्भर करता है, तो यह टूटा हुआ है और संभवतः Linux पर असुरक्षित है। इसलिए हमारे पास पहले से ही एक संभावित सुरक्षा समस्या है।

os.Rename() और .Remove() विंडोज़ पर अंतर का दस्तावेजीकरण नहीं करते हैं, इसलिए कोई भी अनुमान नहीं लगाएगा कि वे मौजूद हैं। उन्हें अभी दस्तावेज करने से मौजूदा कोड ठीक नहीं होगा। असंगति को ठीक करने और उस पर ब्लॉग पोस्ट प्रकाशित करने से कहीं अधिक मदद मिलेगी।

ध्यान दें कि फ़ाइल_शेयर_डिलीट को डिफ़ॉल्ट के रूप में अपनाने से पहले एरलांग कुछ समय के लिए आसपास रहा था।

विंडोज़ पर गो का सबसे आम मामला विकास है, लिनक्स या अन्य यूनिक्स पर

यदि आपका कोड किसी भी GOOS=windows व्यवहार पर निर्भर करता है, तो यह टूटा हुआ है और संभवतः Linux पर असुरक्षित है। इसलिए हमारे पास पहले से ही एक संभावित सुरक्षा समस्या है।

@networkimprov

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

लेकिन निश्चित रूप से ऐसा नहीं किया गया है, और इसके बजाय गो के रनटाइम और मानक पुस्तकालय पॉज़िक्स के डिफ़ॉल्ट और बुरी तरह से डिज़ाइन किए गए व्यवहार के आसपास काम करने के लिए पीछे की ओर झुकते हैं, जो विंडोज़ को मिरर करने की कोशिश कर रहा है।

साझा फ़ाइल एक्सेस के साथ स्थिति समान है। विंडोज़ को यकीनन डिज़ाइन सही मिला, और POSIX.1-2008 को अपनी डिज़ाइन सीमाओं के आसपास काम करने के लिए कई फ़ंक्शन जोड़ने पड़े।

इसके अलावा, जैसा कि @mattn ने ऊपर कई बार उल्लेख किया है, जिसमें FILE_SHARE_DELETE जब फाइलें खोलने से विंडोज़ POSIX की तरह व्यवहार नहीं करता है - अभी भी महत्वपूर्ण व्यवहार अंतर होंगे जो इस ध्वज के साथ अलग-अलग os.Remove तुलना में कहीं अधिक स्पष्ट हो जाएंगे। os.Rename व्यवहार।

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

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

मेरी राय में, यहां केवल गैर-ब्रेकिंग (और गैर-सुरक्षा-समझौता) विकल्प syscall.FILE_SHARE_DELETE के लिए syscall.Open के flag तर्क में समर्थन जोड़ना है, या केवल बल देना है जो उपयोगकर्ता FILE_SHARE_DELETE कार्यक्षमता चाहते हैं वे CreateFileW + os.NewFile । हां, इसके लिए डेवलपर्स से थोड़ा काम करने की आवश्यकता है जो इस व्यवहार को चाहते हैं, लेकिन Win32 और POSIX मौलिक रूप से अलग जानवर हैं और यह आश्चर्यजनक है कि रनटाइम और मानक पुस्तकालय उतना ही अच्छा काम करते हैं जितना वे अपने मतभेदों को दूर करने के लिए करते हैं। इन प्लेटफार्मों के बीच कई और महत्वपूर्ण अंतर हैं जो मानक पुस्तकालय में खुद को प्रकट करते हैं, उदाहरण के लिए पूरी तरह से अलग अनुमति मॉडल, तथ्य यह है कि os.File.Chmod विंडोज पर काम नहीं करता है, os.Chown पर काम नहीं करता है विंडोज, तथ्य यह है कि आंतरिक पोलर विभिन्न प्लेटफार्मों पर विभिन्न प्रकार की फाइलों का समर्थन करता है, आदि। गो के रनटाइम और मानक पुस्तकालय वे सबसे अच्छा करते हैं (और इसे अच्छी तरह से करते हैं), लेकिन वे क्रॉस-प्लेटफ़ॉर्म विकास संकट के लिए रामबाण नहीं हैं। कुछ बिंदु पर, डेवलपर्स को इन अंतरों को स्वयं ही संभालना पड़ता है। संशोधित करने के लिए एक ब्रेकिंग परिवर्तन जोड़ना (ध्यान दें कि मैंने सही नहीं कहा) एक अस्पष्ट व्यवहारिक बढ़त का मामला मेरे लिए कोई मायने नहीं रखता है।

मैं इसके लिए एक और उपयोग के मामले को साझा करना चाहता था।

वर्तमान में जब डॉकर लॉग रोटेट लॉजिक इस तरह से काम करता है कि डॉकर इंजन सक्रिय लॉग का नाम बदलकर .1 कर देगा, पुराने नाम के साथ नया बना देगा।
कोई भी क्लाइंट जो सक्रिय रूप से docker logs --follow <container> कमांड के साथ लॉग का अनुसरण कर रहा है
ध्यान देंगे कि फाइल सिस्टम घटनाओं से:
https://github.com/moby/moby/blob/916eabd459fe707b5c4a86377d12e2ad1871b353/daemon/logger/loggerutils/logfile.go#L552 -L593

यह तर्क भी है जो विंडोज़ को उन घटनाओं को तुरंत नोटिस करता है:
https://github.com/moby/moby/blob/916eabd459fe707b5c4a86377d12e2ad1871b353/daemon/logger/loggerutils/logfile.go#L670 -L676

यह सब लिनक्स पर अच्छी तरह से काम करता है, लेकिन विंडोज लॉग रोटेट पर त्रुटि The process cannot access the file because it is being used by another process. विफल हो जाती है यदि लॉग के बाद कोई क्लाइंट है (समस्या: https://github.com/moby/moby/issues/39274 )

चूंकि उन क्लाइंट की संख्या होना संभव है जो लॉग का अनुसरण कर रहे हैं, पहले उन सभी खुली फ़ाइल हैंडल को इकट्ठा करना और फ़ाइल घुमाने से पहले उन्हें बंद करना बहुत मुश्किल होगा, इसलिए मैं वास्तव में syscall.FILE_SHARE_DELETE लिए समर्थन प्राप्त करना अच्छा देखना चाहता हूं

नमस्ते! त्वरित पृष्ठभूमि: मैं क्रोम सीआई इंफ्रास्ट्रक्चर पर काम करता हूं। हम अपने लो लेवल वर्कर कोड को गो में पोर्ट कर रहे हैं। हम प्रति दिन विंडोज़ पर सैकड़ों हजारों परीक्षण आमंत्रण चलाते हैं।

मैंने सभी टिप्पणियां पढ़ ली हैं और मुझे आशा है कि निम्नलिखित प्रत्येक व्यक्ति की राय का एक स्पष्ट और सही सारांश है।

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

हमारे माइग्रेशन के हिस्से के रूप में, हमें FILE_SHARE_DELETE की आवश्यकता है, आंशिक रूप से लॉग फ़ाइल के रोटेशन के कारण, #39274 के समान। ऐसा होता है यह #25965 अंक के लिए भी एक समस्या है।

मैं सहमत हूं कि @ianlancetaylor पूरे https://codereview.appspot.com/823043/ में प्रस्तावित है, यह एक अच्छा विचार नहीं है। एक फ़ाइल हैंडल को लॉक फ़ाइल के रूप में उपयोग करते समय इस प्रस्ताव को ध्यान में रखने वाली एक तत्काल समस्या है। हम इस व्यवहार का उपयोग करते हैं। और क्या @ कहर-आईओ ने कहा। तो चलिए इसे भी नज़रअंदाज कर देते हैं।

पुन: स्थापित करने के लिए, मैं इस शेष टिप्पणी में इन प्रस्तावों को नज़रअंदाज़ करने जा रहा हूँ:

• बिल्कुल पॉज़िक्स की तरह व्यवहार करने की कोशिश कर रहा है, जो काम नहीं करेगा
• वैश्विक व्यवहार को ऑप्ट-आउट के रूप में बदलें (या कोई ऑप्ट-आउट नहीं!), जो उपयोगकर्ताओं को तोड़ता है

यह हमें प्रति-कॉल ध्वज के साथ एक नाम के साथ छोड़ देता है जो स्पष्ट रूप से विंडोज़-विशिष्ट है। ठीक यही @guybrand का प्रस्ताव है।

पूरे सम्मान के साथ, मुझे @mattn आपत्ति समझ में नहीं आ @guybrand का प्रस्ताव उचित है। हाँ फ़ाइल साझा करने के संबंध में विंडोज़ अलग तरह से व्यवहार करता है। यह फ़ाइल हटाने के अधिकार की तरह है, यह विंडोज़ पर बहुत अलग है । यह पहले से ही कई तरह से अलग है। विंडोज़-विशिष्ट ध्वज के लिए इस रुख पर आपत्ति करना कि "डेवलपर्स अपने व्यवहार को गलत समझ सकते हैं" एक तथ्य नहीं है, यह एक राय है। आप मानते हैं कि डेवलपर्स नहीं जानते कि वे क्या कर रहे हैं या एमएसडीएन पर दस्तावेज़ीकरण नहीं पढ़ेंगे। यह सामान्य मामले के लिए एक उचित आपत्ति है, लेकिन वैकल्पिक ध्वज के रूप में वैध उपयोग के मामले को अवरुद्ध करने के आधार पर मजबूत नहीं है।

विडंबना यह है कि जब तक यह समस्या हल नहीं हो जाती, तब तक #25965 को ठीक करने के लिए मुझे CreateFileW सीधे कॉल करने के लिए 'गो रन' को बदलना होगा क्योंकि हमें FILE_FLAG_DELETE_ON_CLOSE की भी आवश्यकता है।

धन्यवाद!

मैं सिर्फ यह जानना चाहता हूं कि यह जानने के लिए मामला कैसे मौजूद हो सकता है कि क्या हमें नई विशेषताओं के साथ फ़ाइल खोलने/बनाने के लिए नया फ़ंक्शन (golang.org/x/sys?) लागू करना चाहिए, या मूल व्यवहार बदलना चाहिए। वर्तमान में, जहाँ तक मैं उपरोक्त टिप्पणियों से जान सकता हूँ:

1. लॉगिंग के लिए हटाने योग्य (नाम बदलने योग्य) फ़ाइल बनाना।
2. अस्थायी फ़ाइल के लिए फ़ाइल बनाना जो बंद होने पर हटा दी जाएगी।

1 के लिए, इसे विशेषताओं के साथ फ़ाइल बनाने/खोलने के लिए नए फ़ंक्शन से प्रदान किया जा सकता है। और हम logger.SetOutput(file) का उपयोग करके फ़ाइल को सेट कर सकते हैं।

2 के लिए, नए फ़ंक्शन के साथ भी बना/खोल सकते हैं।

BTW, मैं अनुमान लगा रहा हूँ #25965 इस मुद्दे पर संबंधित नहीं है। शायद, यह विंडोज़ की सीमा है।

(किसी भी स्थिति में, हम उस निर्देशिका को नहीं हटा सकते हैं जहाँ इस विशेषता के साथ खोली गई फ़ाइल मौजूद है)

@mattn क्या आप व्यापार को बीच में समझा सकते हैं:

• golang.org/x/sys में एक पूरी तरह से नया फ़ंक्शन जोड़ना
• OpenFile() के लिए एक नए ध्वज (पहले से परिभाषित!) का समर्थन करना। [1]

मुझे समझ में नहीं आता कि हम दूसरे के बजाय पहले का पक्ष क्यों लें।

[1] मुझे अभी एहसास हुआ कि मैंने यहाँ os.OpenFile () के व्यवहार को बदल दिया है, लेकिन समस्या ओपन () को कॉल करती है।

सबसे पहले, syscall पैकेज पहले से ही बंद है। तो मैं syscall पैकेज को बदले बिना इसे ठीक करने का एक तरीका ढूंढ रहा हूं।

BTW, मैं अनुमान लगा रहा हूँ #25965 इस मुद्दे पर संबंधित नहीं है। शायद, यह विंडोज़ की सीमा है।

(किसी भी स्थिति में, हम उस निर्देशिका को नहीं हटा सकते हैं जहाँ इस विशेषता के साथ खोली गई फ़ाइल मौजूद है)

@mattn यह पूरी तरह सच नहीं है। FILE_SHARE_DELETE ध्वज आपको उन फ़ाइलों को किसी अन्य फ़ोल्डर में ले जाने की अनुमति देगा ताकि आप मूल को हटा सकें। इसका सरल पावरशेल उदाहरण यहां दिया गया है:

# Create folder and open new file with FILE_SHARE_DELETE flag
New-Item -Type Directory -Path C:\folder1
$file = [System.IO.File]::Open("C:\folder1\test.txt", "Create", "ReadWrite", "Delete")

# Create temp folder and move all open files to there
New-Item -Type Directory -Path C:\folder1-removing
Get-ChildItem -Path C:\folder1 -Recurse | Move-Item -Destination C:\folder1-removing\

# Remove original folder
Remove-Item -Path C:\folder1

# Trigger removal for files on temp folder (NOTE! Those will exist on disk until they are closed).
Get-ChildItem -Path C:\folder1-removing -File -Recurse | Remove-Item -Force

# Close file and remove temp folder
$file.Close()
Remove-Item -Path C:\folder1-removing

सबसे पहले, syscall पैकेज पहले से ही बंद है। तो मैं syscall पैकेज को बदले बिना इसे ठीक करने का एक तरीका ढूंढ रहा हूं।

@mattn अगर यह केवल एपीआई के जमे हुए होने का मुद्दा है, तो जैसा कि मैंने ऊपर उल्लेख / डेमो किया है, syscall.Open को समझने के लिए समायोजित किया जा सकता है syscall.FILE_SHARE_DELETE , एपीआई को बदले बिना इस मुद्दे को हल करना।

यदि यह एक कार्यान्वयन फ़्रीज़ है, तो परिवर्तन golang.org/x/sys/windows के Open फ़ंक्शन में किया जा सकता है और फिर internal/syscall पैकेज में वेंडर किया जा सकता है। file_windows.go कोड पहले से ही internal/syscall कार्यों का उपयोग कर रहा है। तब एकमात्र असंगति यह होगी कि syscall.Open इस ध्वज को नहीं समझेंगे, लेकिन निम्न-स्तरीय विंडोज एपीआई कार्यक्षमता का उपयोग करने वाले अधिकांश लोग वैसे भी golang.org/x/sys/windows का उपयोग कर रहे हैं, और शायद CreateFile का उपयोग कर रहे हैं। Open CreateFile बजाय Open ।

सिस्कल पैकेज "लॉक-डाउन" शुरू करने वाले प्रस्ताव में कहा गया है:
_मुख्य भंडार go.sys संकुल पर निर्भर नहीं होगा_

इसलिए x/sys बदलने से os.OpenFile() के कॉलर्स को मदद नहीं मिलेगी। लेकिन आंतरिक/syscall Open() जोड़ सकता है, और os.OpenFile() इसे कॉल करेगा।

@maruel , डॉकर प्रोजेक्ट, और संभवतः कई अन्य लोगों ने os.Rename() & .Remove() के लिए खोली गई फ़ाइलों के लिए यूनिक्स व्यवहार ग्रहण किया क्योंकि पैकेज "os" में उनके लिए विंडोज-विशिष्ट व्यवहार का उल्लेख नहीं है, फिर भी __पंद्रह उल्लेख__ का है अन्य विंडोज़ व्यवहार।

कोर रिपॉजिटरी go.sys पैकेज पर निर्भर नहीं होगी
लेकिन आंतरिक/syscall Open() जोड़ सकता है, और os.OpenFile() इसे कॉल करेगा।

@networkimprov ठीक है, मैं गलत धारणा है कि के तहत किया गया internal/syscall के vendored सबसेट था golang.org/x/sys , लेकिन किसी भी तरह से मुझे लगता है कि यह सही रणनीति (जोड़ने है internal/syscall/windows.Open )। बेशक, यह इस धारणा के तहत होगा कि फ्रीज के कारण syscall.Open का व्यवहार अपरिवर्तनीय है। आदर्श रूप से इसे सीधे संशोधित किया जा सकता है, संभावित रूप से golang.org/x/sys/windows.Open में संबंधित परिवर्तनों के साथ।

हालांकि syscall पैकेज जम गया है, हम बग्स को ठीक करने या गंभीर कमियों को दूर करने के लिए इसे बदल सकते हैं। विशेष रूप से हम इसे ओएस पैकेज के बेहतर समर्थन के लिए बदल सकते हैं।

लेकिन अगर लोग सीधे syscall.Open कॉल कर रहे हैं, तो उन्हें x/sys/windows पैकेज का उपयोग करना चाहिए, न कि syscall पैकेज का।

लेकिन अगर लोग सीधे syscall.Open कॉल कर रहे हैं, तो उन्हें x/sys/windows पैकेज का उपयोग करना चाहिए, न कि syscall पैकेज का।

मुझे नहीं लगता कि किसी को भी फोन करने के लिए देख रहा है syscall.Open सीधे - यह केवल चर्चा का लक्ष्य है, क्योंकि यह underlies os.OpenFile (ताकि के लिए समर्थन जोड़ने FILE_SHARE_DELETE में syscall.Open ध्वज का उपयोग करने के लिए समर्थन जोड़ता है os.OpenFile )।

धन्यवाद। os पैकेज में परिवर्तनों का समर्थन करने के लिए syscall पैकेज को बदलना ठीक है।

धन्यवाद @ianlancetaylor और @havoc-io। मैंने ऊपर जो उल्लेख किया है, उससे अधिक औपचारिक प्रस्ताव:

• FILE_SHARE_DELETE (और अंततः FILE_FLAG_DELETE_ON_CLOSE को संभावित अनुवर्ती कार्रवाई के रूप में) स्वीकार करने के लिए os.OpenFile() को अनुमति देने के स्पष्ट इरादे से syscall.Open() को संशोधित करें।
• केवल-विंडोज़ के नए फ़्लैग का वर्णन करने के लिए os.OpenFile() दस्तावेज़ अपडेट करें।
• POSIX और Windows के बीच व्यवहार में अंतर को स्पष्ट करने के लिए os.OpenFile(), os.Rename() और os.Remove() दस्तावेज़ों को अपडेट करें।

तीसरा बिंदु @networkimprov चिंता का @mattn से सहमत होना शुरू कर रहा हूं कि ये मामले अधिक दस्तावेज की गारंटी देने के लिए पर्याप्त सूक्ष्म हैं। मुझे लगता है कि नाम बदलें और निकालें के लिए दस्तावेज़ में तुरंत सुधार किया जा सकता है, किसी भी व्यवहार परिवर्तन की प्रतीक्षा करने की आवश्यकता नहीं है।

मंजूरी मिलने पर मैं इसमें योगदान करने को तैयार हूं।

यह हमें प्रति-कॉल ध्वज के साथ एक नाम के साथ छोड़ देता है जो स्पष्ट रूप से विंडोज़-विशिष्ट है।

क्या आप नए ओएस का प्रस्ताव करते हैं। खुला झंडा? फिर ध्वज को सभी ओएस द्वारा समर्थित किया जाना चाहिए - यह ओएस पैकेज का एक संपूर्ण बिंदु है - ओएस स्वतंत्र होना चाहिए। तो उस झंडे का शब्दार्थ क्या होगा? और आपको कुछ नए परीक्षणों की आवश्यकता होगी जो दस्तावेज के रूप में ध्वज कार्यों को सत्यापित करते हैं।

मैं नहीं देखता कि आप syscall पैकेज का उपयोग करके जो भी कोड चाहते हैं उसे क्यों नहीं लिख सकते हैं। मुझे नहीं लगता कि आपका कोड अन्य विंडोज प्रोग्राम के साथ अच्छी तरह से सह-अस्तित्व में होगा। और शायद यह विशेष परिस्थितियों में ठीक है। लेकिन मैं नहीं चाहता कि लोग इस कार्यक्षमता का हल्के ढंग से उपयोग करें - इसलिए यह मानक पुस्तकालय का हिस्सा नहीं होना चाहिए।

एलेक्स

@alexbrainman
कृपया इसे देखें

@alexbrainman
कृपया इसे देखें

मैंने देखा। मैं अभी भी नहीं देखता कि आपके सभी प्रस्तावित परिवर्तन अन्य OSes पर कैसे कार्य करेंगे? अपने प्रस्तावित परिवर्तन को लागू करने के लिए आपको कौन से परीक्षण करने होंगे?

एलेक्स

के हवाले से यह

जबकि env के लिए DELETE_WHEN_FREED 0 भी हो सकता है। खिड़कियों के अलावा

तो - अन्य ओएस पर परीक्षण करने के लिए कुछ भी नहीं, इसके लिए कॉल करें:
एफडी, त्रुटि: = os.OpenFile (पथ, os.O_RDWR|os.O_CREATE|os.DELETE_WHEN_FREED, 0600)
विंडोज़ में कास्ट को 4 . में अनुवादित किया जाएगा
एफडी, त्रुटि: = os.OpenFile (पथ, os.O_RDWR|os.O_CREATE| 4 , 0600)
जबकि अन्य ( 0 )
एफडी, त्रुटि: = os.OpenFile (पथ, os.O_RDWR|os.O_CREATE| 0 , 0600)

अन्य OSes पर परीक्षण करने के लिए कुछ भी नहीं

मैं नहीं देखता कि हम नए ओएस पैकेज कॉन्स या वेरिएबल को कैसे जोड़ सकते हैं जो केवल विंडोज़ पर प्रयोग योग्य है।

c:\>go doc os
package os // import "os"

Package os provides a platform-independent interface to operating system
functionality. 
...
The os interface is intended to be uniform across all operating systems.
Features not generally available appear in the system-specific package
syscall.

एलेक्स

एलेक्स ने आपकी आपत्ति का जवाब सबसे पहले यहां बताया था https://github.com/golang/go/issues/32088#issuecomment -494157514

एक परीक्षण तुच्छ है

_, err := os.OpenFile(path, os.O_CREATE | syscall.FILE_SHARE_DELETE, 0);
err = os.Rename(path, path+"2")

हम उस बिंदु पर हैं जहां कोई पैच सबमिट कर सकता है; मुझे संदेह है कि @ianlancetaylor इसे स्वीकार करेगा।

मैंने #32188 के हिस्से के रूप में FILE_SHARE_DELETE की स्थापना की जांच की, लेकिन पाया कि इसे सेट करने से os.Rename और io.ReadFile कॉल से त्रुटियों की दर आनुभविक रूप से कम नहीं हुई; वैसे भी एक पुन: प्रयास लूप की अभी भी आवश्यकता थी।

मुझे एक ऐसा परीक्षण देखने में बहुत दिलचस्पी होगी जो इस ध्वज को स्थापित करने से एक महत्वपूर्ण अवलोकन योग्य अंतर प्रदर्शित करता है, क्योंकि मैं वास्तव में इसके प्रभावों को स्वयं नहीं समझता।

मैंने कुछ साल पहले FILE_SHARE_DELETE का प्रयोग किया है, और इसने व्यवहार किया
अलग ढंग से।
मैं शायद अपने विंडोज़ एनवी को फिर से लॉन्च कर सकता हूं। और इसे देखो, अगर यह मदद करेगा,
लेकिन यह ~ 1.3 या तो होगा।

सोम, 10 जून 2019 को 17:44 बजे, ब्रायन सी। मिल्स नोटिफिकेशन @github.com
लिखा था:

मैंने FILE_SHARE_DELETE को #32188 . के हिस्से के रूप में सेट करने की जांच की
https://github.com/golang/go/issues/32188 , लेकिन पाया कि इसे सेट करना
os.Rename और . से त्रुटियों की दर को अनुभवजन्य रूप से कम नहीं किया
io.ReadFile कॉल; वैसे भी एक पुन: प्रयास लूप की अभी भी आवश्यकता थी।

मुझे एक ऐसा परीक्षण देखने में बहुत दिलचस्पी होगी जो एक महत्वपूर्ण प्रदर्शित करता है
इस ध्वज को स्थापित करने से देखने योग्य अंतर, क्योंकि मैं वास्तव में नहीं हूं
इसके निहितार्थ स्वयं समझें।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/32088?email_source=notifications&email_token=ABNEY4VVIVJ2IEWQPWCWBZTPZZSETA5CNFSM4HNPNYIKYY3PNVWWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJZ71KT मुद्दा
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABNEY4STTW7U526HPO6TUHDPZZSETANCNFSM4HNPNYIA
.

@bcmills , #32188 पढ़ रहा हूं, मुझे पता चला है कि आप नाम बदलने के दौरान _was not open_ फ़ाइल पर os.Rename() से त्रुटियां देख रहे थे? मुझे लगता है कि कोई एनटीएफएस जर्नल को पीछे छोड़ सकता है, जो मुझे लगता है कि सभी निर्देशिका परिवर्तन ऑप्स के लिए लिखा गया है, और इस तरह एक त्रुटि उत्पन्न करता है; लेकिन मुझे नहीं पता कि यह क्या त्रुटि होगी।

Syscall.Open() में FILE_SHARE_DELETE को सक्षम करने के लिए यहां अनुरोध os.Rename() को खुली फाइलों पर काम करने की अनुमति देना है। मैंने Win7 पर 1.12 के साथ उस ध्वज का परीक्षण किया है, यह काम करता है; और इसके बिना विफल रहता है।

मैंने विशेष रूप से "लोड के तहत" विंडोज़ पर os.Rename() का परीक्षण नहीं किया है, लेकिन fsd को सक्षम करने के बाद से खोली गई फ़ाइलों पर os.Rename() से कोई अप्रत्याशित त्रुटि नहीं देखी है, अगर मैं करता हूं तो मैं इसकी रिपोर्ट करूंगा।

मुझे लगता है कि आप os.Rename() से उस फ़ाइल पर त्रुटियां देख रहे थे जो नाम बदलने के दौरान खुली नहीं थी?

हां।

मुझे नहीं पता कि यह क्या त्रुटि होगी।

आनुभविक रूप से, जो त्रुटियां मैं देख रहा हूं ( MoveFileEx , ReplaceFile , और/या CreateFile ) वे हैं ERROR_ACCESS_DENIED , ERROR_SHARING_VIOLATION , और ERROR_FILE_NOT_FOUND ।

Syscall.Open() में FILE_SHARE_DELETE को सक्षम करने के लिए यहां अनुरोध os.Rename() को खुली फाइलों पर काम करने की अनुमति देना है। मैंने Win7 पर 1.12 के साथ उस ध्वज का परीक्षण किया है, यह काम करता है; और इसके बिना विफल रहता है।

सही; संबंधित समस्याओं मैं हल करने के लिए कोशिश कर रहा हूँ करने के लिए समवर्ती कॉल अनुमति देने के लिए कर रहे हैं os.Rename सफल होने के लिए, और करने के लिए कॉल की अनुमति के लिए io.ReadFile के साथ समवर्ती os.Rename सफल होने के लिए। मौजूदा हैंडल के साथ काम करने के लिए एक एकल os.Rename प्राप्त करना सही दिशा में एक कदम हो सकता है, लेकिन मुझे नहीं लगता कि यह उस तरह के उपयोग के मामलों के लिए पर्याप्त है जिसके लिए हम POSIX rename ।

मुझे एक ऐसा परीक्षण देखने में बहुत दिलचस्पी होगी जो इस ध्वज को स्थापित करने से एक महत्वपूर्ण अवलोकन योग्य अंतर प्रदर्शित करता है, क्योंकि मैं वास्तव में इसके प्रभावों को स्वयं नहीं समझता।

@bcmills PowerShell उदाहरण जैसा कि मैं लिखता हूं कि Go . की तुलना में बहुत तेज है

New-Item -Type Directory -Path C:\folder1
for($i=0; $i -le 1000; $i++)
{
    $temp = [System.IO.File]::Open("C:\folder1\test.txt", "Create", "ReadWrite", "Delete")
    Set-Variable -Name "file$i" -Value $temp -Force
    $TempName = "C:\folder1\test.txt." + (New-Guid).Guid
    Rename-Item -Path C:\folder1\test.txt -NewName $TempName
    Remove-Item -Path $TempName -Force
}

कि समाप्त होने के बाद वहाँ हजार हो जाएगा test.txt.??? के अंतर्गत फ़ाइलें C:\folder1 लेकिन जब आप करीब PowerShell उन फ़ाइलों को हटा दिया जाएगा।

तो क्या FILE_SHARE_DELETE ध्वज वास्तव में आपको खुली फ़ाइलों का नाम बदलने/स्थानांतरित करने/निकालने की अनुमति देता है लेकिन आपको अभी भी यह सुनिश्चित करने की आवश्यकता है कि गंतव्य फ़ाइल नाम अद्वितीय हैं क्योंकि वे डिस्क पर तब तक मौजूद रहेंगे जब तक हैंडल खुले हैं।

विंडोज़ में "पॉज़िक्स नाम बदलें" असंभव है, और शायद यही कारण है कि आपको मिलने वाली त्रुटियां हैं।

पॉज़िक्स:

फ़ाइल "फ़ाइल नाम" बनाएँ
"फ़ाइल नाम" से पढ़ें/लिखें
"फ़ाइल नाम" हटाएं

फ़ाइल "फ़ाइल नाम" बनाएँ
...
"फ़ाइल नाम" हटाएं

काम करेगा, क्योंकि प्रत्येक निर्माण फ़ाइल में एक भिन्न fd होगा।

खिड़कियाँ:
फ़ाइल "फ़ाइल नाम" बनाएँ
"फ़ाइल नाम" से पढ़ें/लिखें
"फ़ाइल नाम" हटाएं

फ़ाइल "फ़ाइल नाम" बनाएं - बूम, उल्लंघन साझा करना

पुनर्निर्माण करना बहुत आसान होना चाहिए ...

तब FILE_SHARE_DELETE क्या कर सकता है?
फ़ाइल के खुले होने पर डिफर्ड डिलीट की अनुमति दें।

बस, इतना ही।

सोम, 10 जून 2019 को 19:32 बजे, ओली जनातुइनेन नोटिफिकेशन @github.com
लिखा था:

मुझे एक ऐसा परीक्षण देखने में बहुत दिलचस्पी होगी जो एक महत्वपूर्ण प्रदर्शित करता है
इस ध्वज को स्थापित करने से देखने योग्य अंतर, क्योंकि मैं वास्तव में नहीं हूं
इसके निहितार्थ स्वयं समझें।

जैसा कि मैंने लिखा है https://github.com/bcmills PowerShell उदाहरण
गो की तुलना में बहुत तेज

नया-आइटम-प्रकार निर्देशिका-पथ C:folder1for($i=0; $i -le 1000; $i++)
{
$temp = [System.IO.File]::Open("C:folder1test.txt", "Create", "ReadWrite", "Delete")
सेट-वेरिएबल-नाम "फ़ाइल$i" -मूल्य $temp-Force
$TempName = "सी:folder1test.txt।" + (नया-गाइड)।गाइड
नाम बदलें-आइटम-पथ C:folder1test.txt-NewName $TempName
निकालें-आइटम-पथ $TempName-Force
}

उसके समाप्त होने के बाद हजार test.txt होंगे।??? के तहत फ़ाइलें
सी: फ़ोल्डर 1 लेकिन जब आप पावरशेल बंद करते हैं तो वे फाइलें हटा दी जाएंगी।

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

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/32088?email_source=notifications&email_token=ABNEY4WSTWIUVNVHLYMBFY3PZZ62DA5CNFSM4HNPNYIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXH248GORT समस्या
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABNEY4VS5XF3EXB6QPBWVQ3PZZ62DANCNFSM4HNPNYIA
.

io को कॉल की अनुमति दें। ओएस के साथ रीडफाइल समवर्ती। सफल होने के लिए नाम बदलें

@bcmills मुझे लगता है कि किसी को हमेशा

परीक्षण स्क्रिप्ट के उस पहलू को Windows syscall.Open() में सही ढंग से एक बग मिला। लेकिन इस धागे में टिप्पणी करने वाला कोई और नहीं चाहता कि यह ठीक हो :-( तो हाँ, स्क्रिप्ट को पैच करें।

टीएलडीआर:
syscal_windows.go में मामूली सुरक्षित परिवर्तन और अपेक्षा के अनुरूप काम करता है।

व्याख्या की:
तो, यहाँ मैंने जो किया है, उम्मीद के मुताबिक काम करता है, और कोई जोखिम नहीं (आईएमओ)

1. ट्विक syscal_windows.go

func Open(path string, mode int, perm uint32) (fd Handle, err error) {

sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | (mode & FILE_SHARE_DELETE))

जोड़ है: "| (मोड और FILE_SHARE_DELETE)"
अगर डेवलपर मोड और 4 सेट नहीं भेजेगा (वह क्यों - यह पहले कभी काम नहीं कर रहा था ...) - कुछ भी नहीं बदला है, इसलिए एक कोड

os.OpenFile(filename,os.O_RDWR|os.O_CREATE, 0600)

ठीक वैसा ही व्यवहार करेगा जैसा वह परिवर्तन से पहले करता है, केवल डेवलपर्स जो करेंगे

os.OpenFile(filename,os.O_RDWR|os.O_CREATE  | 4 , 0600)

बदलाव को "महसूस" करेंगे

1. कोड चलाया

package main

import (
    "fmt"
    "os"
)

func main() {
    filename := "./myfile"
    if f ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{
        fmt.Printf("Open file %s error : %s" , filename, err.Error())
    } else if _,err:= f.WriteString("bla bla") ;err!=nil{
        fmt.Printf("writing to %s returned error : %s" , filename, err.Error())
    } else if err := os.Remove(filename);err!=nil{
        fmt.Printf("removing %s returned error : %s" , filename, err.Error())
    }
}

और यह काम किया

1. |4 के बिना कोड चलाया और यह विफल रहा
2. एक छोटे से जोड़ के साथ कोड चलाया:

package main

import (
    "fmt"
    "os"
)

func main() {
    filename := "./myfile"
    if f ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{
        fmt.Printf("Open file %s error : %s" , filename, err.Error())
    } else if _,err:= f.WriteString("bla bla") ;err!=nil{
        fmt.Printf("writing to %s returned error : %s" , filename, err.Error())
    } else if err := os.Remove(filename);err!=nil{
        fmt.Printf("removing %s returned error : %s" , filename, err.Error())
    } else if secondF ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{
        fmt.Printf("reOpen file %s error : %s" , filename, err.Error())
    } else {
        secondF.Close()
    }
}

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

हमें बस इतना करना है (बोल्ड में):
syscal_windows.go:
शेयरमोड: = uint32 (FILE_SHARE_READ | FILE_SHARE_WRITE | (मोड और FILE_SHARE_DELETE) )

मैंने #32188 के हिस्से के रूप में FILE_SHARE_DELETE की स्थापना की जांच की, लेकिन पाया कि इसे सेट करने से os.Rename और io.ReadFile कॉल से त्रुटियों की दर आनुभविक रूप से कम नहीं हुई; वैसे भी एक पुन: प्रयास लूप की अभी भी आवश्यकता थी।

मुझे एक ऐसा परीक्षण देखने में बहुत दिलचस्पी होगी जो इस ध्वज को स्थापित करने से एक महत्वपूर्ण अवलोकन योग्य अंतर प्रदर्शित करता है, क्योंकि मैं वास्तव में इसके प्रभावों को स्वयं नहीं समझता।

@bcmills अब आप इसके लिए https://github.com/olljanat/go/commit/3828f1a5d0ebb69b4c459d5243799ded36ac1ee8 से यूनिट/रिग्रेशन परीक्षण पा सकते हैं, वर्तमान में यह विंडोज़ पर The process cannot access the file because it is being used by another process. त्रुटि में विफल रहता है और FILE_SHARE_DELETE बाद काम करना शुरू कर देता है

ध्यान दें! कि विंडोज़ पर आपको अभी भी उस चरण की आवश्यकता है जो लॉग example.log.1 फ़ाइल को यादृच्छिक/अद्वितीय नाम पर ले जाता है क्योंकि अन्य क्यों example.log से example.log.1 नाम बदलना Access is denied. त्रुटि में विफल हो जाएगा FILE_SHARE_DELETE ध्वज सक्षम होने पर भी। वह प्लेटफ़ॉर्म विशिष्ट चीज़ है जिसका डेवलपर को ध्यान रखने की आवश्यकता है।

/सीसी @jhowardmsft @jterry75 @jstarks @ddebroy FYI करें; आपको इसमें भी दिलचस्पी हो सकती है।

@kevpar - FYI करें क्योंकि आप इसके आसपास भी काम कर रहे हैं

यदि थ्रेड में शामिल होने वाला कोई भी व्यक्ति os.OpenFile() में विंडोज़-ओनली फ़्लैग के माध्यम से उपलब्ध बनाम इसे डिफ़ॉल्ट बनाने के लिए कारण (जैसे मौजूदा कोड टूटा हुआ) आवाज दे सकता है, तो पाइप अप करें!

@networkimprov IMO इसे विंडोज़-ओनली फ्लैग के साथ संभाला जाना चाहिए क्योंकि डेवलपर को कुछ अन्य विंडोज़ विशिष्ट चीजों को भी संभालने की आवश्यकता होती है, जैसे कि मेरे लॉग रोटेट उदाहरण पर।

हालाँकि जैसा कि मैं देख सकता हूँ कि Microsoft के कुछ कर्मचारियों को चर्चा के लिए आमंत्रित किया गया था, इसलिए यह देखना दिलचस्प है कि क्या वे इसे अलग तरीके से रखते हैं।

क्या किसी ने बीटीडब्ल्यू ने इसका नया समाधान विकसित करना शुरू कर दिया है? कोई स्वयमसेवक?

@olljanat
यदि यह एक ध्वज के रूप में ठीक है, तो फिक्स एक लाइनर है, कृपया पढ़ें:
https://github.com/golang/go/issues/32088#issuecomment -500562223

मैं यहां विंडोज टीम के नजरिए का प्रतिनिधित्व करने की कोशिश करूंगा... हम इसके बजाय हमेशा FILE_SHARE_DELETE सेट करें, बिना किसी विकल्प के। सामान्य तौर पर, विंडोज़ में/से पोर्टिंग को आसान बनाने के लिए, हम लिनक्स के साथ सुसंगत व्यवहार को प्राथमिकता देंगे, और मुझे नहीं लगता कि विंडोज़ उपयोगकर्ता या सॉफ़्टवेयर डिफ़ॉल्ट !FILE_SHARE_DELETE व्यवहार को नियम के अपवाद होने के लिए पर्याप्त क्यों पसंद करेंगे।

एक दिलचस्प नोट, @mattn की टिप्पणी के विपरीत: विंडोज के सबसे हाल के संस्करण में, हमने "POSIX" डिलीट करने के लिए DeleteFile (NTFS पर) को अपडेट किया, जहां फाइल को सभी ओपन की प्रतीक्षा करने के बजाय नेमस्पेस से तुरंत हटा दिया जाता है। फ़ाइल को बंद करने के लिए हैंडल। यह अभी भी FILE_SHARE_DELETE का सम्मान करता है, लेकिन अब अन्यथा POSIX अनलिंक जैसा व्यवहार करता है। यह कार्यक्षमता WSL ​​के लिए जोड़ी गई थी और इसे Windows सॉफ़्टवेयर के लिए भी डिफ़ॉल्ट रूप से उपयोग करने योग्य माना गया था।

दूसरे शब्दों में, यदि आप विंडोज़ के नवीनतम संस्करण पर मैटन का परीक्षण कार्यक्रम और डेल, डीआईआर, आदि का अनुक्रम चलाते हैं, तो आप फ़ाइल को हटाने के तुरंत बाद नामस्थान से फ़ाइल गायब होते देखेंगे, न कि परीक्षण कार्यक्रम से बाहर निकलने के बाद। बिल्कुल लिनक्स की तरह।

इसलिए विंडोज़ में ही, इसके काफी बड़े एपकॉम्पैट जोखिम के साथ, हम विंडोज़ में गैर-विंडोज सॉफ़्टवेयर के पोर्टिंग को आसान बनाने के लिए छोटे बदलाव कर रहे हैं। मैं वास्तव में गो को भी ऐसा करने के लिए प्रोत्साहित करता हूं।

@jstarks , मुझे सही साबित करने के लिए धन्यवाद। मैंने उस स्थिति के लिए इस धागे में एक टन गर्मी ली है।

यदि कोई विंडोज़ परिनियोजन वर्तमान अनिर्दिष्ट व्यवहार पर निर्भर करता है, तो मैं fsd को अक्षम करने के लिए एक वैश्विक विकल्प का सुझाव दूंगा।

@ianlancetaylor क्या आप सहमत हैं?

चूंकि CreateFile का डिफ़ॉल्ट व्यवहार यह है कि प्रारंभिक फ़ाइल को हटा नहीं सकता है, मुझे लगता है कि हमें डिफ़ॉल्ट व्यवहार रखना चाहिए। कोई मूल व्यवहार चाहता है। उदाहरण के लिए, ऐसे प्रोग्रामर हो सकते हैं जो जांच कर रहे हैं कि उनका एप्लिकेशन फ़ाइल को हटाने के लिए संभव नहीं तरीके से काम कर रहा है।

पायथन का व्यवहार गो के वर्तमान व्यवहार के समान है। और मैंने कभी नहीं सुना है कि पायथन के पास उस व्यवहार को बदलने की योजना है जो खुली फाइलों को हटा नहीं सकता है।

मैंने इस मुद्दे पर गंभीर राय विकसित करने के लिए समय नहीं लिया है, लेकिन मुझे नहीं लगता कि वैश्विक विकल्प एक अच्छा विकल्प है। हमें या तो वर्तमान व्यवहार रखना चाहिए (और शायद अन्य व्यवहार का चयन करने के लिए ध्वज जोड़ें) या हमें व्यवहार बदलना चाहिए (और शायद मूल, वर्तमान, व्यवहार का चयन करने के लिए ध्वज जोड़ें)।

डिफ़ॉल्ट व्यवहार को बदलना है या नहीं, इस संबंध में, मुझे लगता है कि हमें यह पूछना होगा कि क्या यह अधिक संभावना है कि व्यवहार बदलने से यूनिक्स और विंडोज सिस्टम पर चलने के लिए लिखा गया एक गो प्रोग्राम ठीक हो जाएगा या क्या यह अधिक संभावना है कि व्यवहार बदल रहा है विंडोज सिस्टम पर चलने के लिए लिखे गए गो प्रोग्राम को तोड़ देगा। इसका जवाब मुझे नहीं पता।

जैसा कि @mattn सुझाव देता है कि यह पूछने लायक भी है कि अन्य भाषाएं क्या करती हैं।

यदि यह डिफ़ॉल्ट हो जाता है, और कोई भी विंडोज़ परिनियोजन इस पर निर्भर करता है, तो मुझे लगता है कि वे एक os.OpenFile() ध्वज और संक्रमणकालीन उद्देश्यों के लिए वापस स्विच करने के लिए एक वैश्विक विकल्प दोनों चाहते हैं।

IPv6 को अक्षम करने का एक वैश्विक विकल्प है, पिछली बार मैंने जाँच की थी।

प्रभाव का पता लगाने का एक तरीका है इसे टिप पर बदलना (और ब्लॉग पर घोषणा करना?) और देखें कि क्या रिपोर्ट किया गया है।

अंक पाठ में पायथन और एरलांग दोनों का उल्लेख किया गया है:
Erlang ने इसे छह साल पहले डिफ़ॉल्ट बना दिया था: erlang/ otp@0e02f48
MSVC रनटाइम की सीमाओं के कारण पायथन चाहता था, लेकिन नहीं कर सका: https://bugs.python.org/issue15244

मैं यहां विंडोज टीम के नजरिए का प्रतिनिधित्व करने की कोशिश करूंगा... हम इसके बजाय हमेशा FILE_SHARE_DELETE सेट करें, बिना किसी विकल्प के। सामान्य तौर पर, विंडोज़ में/से पोर्टिंग को आसान बनाने के लिए, हम लिनक्स के साथ सुसंगत व्यवहार को प्राथमिकता देंगे, और मुझे नहीं लगता कि विंडोज़ उपयोगकर्ता या सॉफ़्टवेयर डिफ़ॉल्ट !FILE_SHARE_DELETE व्यवहार को नियम के अपवाद होने के लिए पर्याप्त क्यों पसंद करेंगे।

विंडोज के सबसे हाल के संस्करण में, हमने "POSIX" डिलीट करने के लिए DeleteFile (NTFS पर) को अपडेट किया, जहां फाइल के सभी खुले हैंडल के बंद होने की प्रतीक्षा करने के बजाय फ़ाइल को नेमस्पेस से तुरंत हटा दिया जाता है। यह अभी भी FILE_SHARE_DELETE का सम्मान करता है, लेकिन अब अन्यथा POSIX अनलिंक जैसा व्यवहार करता है। यह कार्यक्षमता WSL ​​के लिए जोड़ी गई थी और इसे Windows सॉफ़्टवेयर के लिए भी डिफ़ॉल्ट रूप से उपयोग करने योग्य माना गया था।

@jstarks जो बहुत ही रोचक विवरण है। क्या ऐसा कुछ है जिसकी हम उम्मीद कर सकते हैं कि Microsoft पुराने OS संस्करणों में भी वापस आ जाए? मुझे लगता है कि विशेष रूप से विंडोज सर्वर 2019 के बारे में जो नवीनतम है, अभी जारी एलटीएससी संस्करण है जो अभी भी लंबे समय तक समर्थित रहेगा।

जैसे कि माइक्रोसॉफ्ट ऐसा करता है तो मैं डिफ़ॉल्ट रूप से FILE_SHARE_DELETE को गो पर भी सक्षम करना पसंद करूंगा।

जावा, सी #, और अन्य सभी प्रमुख भाषाएं जिन्हें मैं डिफ़ॉल्ट ओएस व्यवहार लेने के बारे में जानता हूं। मेरी राय में, डिफ़ॉल्ट व्यवहार को ओएस कार्यान्वयनकर्ता पर छोड़ दिया जाना चाहिए। यदि विंडोज़ वास्तव में फ़ाइलों को खोलने के संबंध में पॉज़िक्स को लेना चाहता है, तो उन्हें वह जोखिम उठाना चाहिए और ऐसा करना चाहिए जैसा उन्होंने DeleteFile के लिए किया था।

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

https://github.com/apache/hadoop/search?q=getShareDeleteFileInputStream&unscoped_q=getShareDeleteFileInputStream

@jstarks

कहते समय

विंडोज के नवीनतम संस्करण में, हमने "POSIX" डिलीट करने के लिए DeleteFile (NTFS पर) को अपडेट किया, जहां फ़ाइल को नेमस्पेस से तुरंत हटा दिया जाता है।

क्या आपका मतलब यह है कि खुली फ़ाइल केवल fd और नीचे दिए गए कोड के रूप में रहती है:

package main

import (
    "fmt"
    "os"
)

func main() {
    filename := "./myfile"
    if f ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{
        fmt.Printf("Open file %s error : %s" , filename, err.Error())
    } else if _,err:= f.WriteString("bla bla") ;err!=nil{
        fmt.Printf("writing to %s returned error : %s" , filename, err.Error())
    } else if err := os.Remove(filename);err!=nil{
        fmt.Printf("removing %s returned error : %s" , filename, err.Error())
    } else if secondF ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{
        fmt.Printf("reOpen file %s error : %s" , filename, err.Error())
    } else {
        secondF.Close()
    }
}

पर असफल नहीं होगा

} else if secondF ,err := os.OpenFile(filename,os.O_RDWR|os.O_CREATE|4, 0600);err!=nil{

सुझाए गए फिक्स को लागू करने के बाद?

यदि ऐसा है, तो यह वास्तव में अच्छा है!

डिफ़ॉल्ट व्यवहार को बदलना है या नहीं, इस संबंध में, मुझे लगता है कि हमें यह पूछना होगा कि क्या यह अधिक संभावना है कि व्यवहार बदलने से यूनिक्स और विंडोज सिस्टम पर चलने के लिए लिखा गया एक गो प्रोग्राम ठीक हो जाएगा या क्या यह अधिक संभावना है कि व्यवहार बदल रहा है विंडोज सिस्टम पर चलने के लिए लिखे गए गो प्रोग्राम को तोड़ देगा। इसका जवाब मुझे नहीं पता।

विंडोज़ पर कोई problem to be fixed यूनिक्स प्रोग्राम नहीं चल रहा है। विंडोज़ यूनिक्स से अलग तरह से खोली गई फाइलों को हटाने का काम करती है। यह फ़ाइल नाम केस संवेदनशीलता के समान है: यूनिक्स केस संवेदनशील है, और विंडोज़ केस असंवेदनशील है। दोनों मतभेदों के बारे में हम कुछ नहीं कर सकते।

और, जबकि जॉन ने आश्वासन दिया है कि माइक्रोसॉफ्ट चीजों को बदलने की कोशिश कर रहा है, मैं तब तक इंतजार करूंगा जब तक कि बदलाव यहां न हो। और बहुत सारे विंडोज उपयोगकर्ता अभी भी विंडोज 7 और अन्य सभी विंडोज संस्करण का उपयोग करते हैं। जॉन क्या आप विंडोज 7 को भी अपडेट करेंगे?

मुझे लगता है कि हमें माइक्रोसॉफ्ट को बदलाव को संभालने देना चाहिए। यदि हम गो उपयोगकर्ताओं को ठीक करते हैं, तब भी गैर-गो डेवलपर रहेंगे। तो माइक्रोसॉफ्ट को इससे कोई फर्क नहीं पड़ता।

साथ ही, FILE_SHARE_DELETE की अपनी पहेलियां हैं। उदाहरण के लिए, https://bugs.python.org/issue15244 पढ़ना

वास्तव में, यह बिल्कुल यूनिक्स के समान शब्दार्थ नहीं है।

फ़ाइल को हटाने के बाद आप उसी नाम की फ़ाइल नहीं बना सकते हैं या उस निर्देशिका को हटा नहीं सकते हैं जब तक कि हैंडल बंद न हो जाए।

हालाँकि, कोई फ़ाइल को हटाने से पहले फ़ाइल को कहीं और (जैसे रूट डायरेक्टरी) ले जाकर उसके आसपास काम कर सकता है।

शायद ऐसे और भी बहुत से लोग हैं जिनके बारे में हम नहीं जानते। हमने FILE_SHARE_DELETE का बिल्कुल भी उपयोग नहीं किया है। क्या आप प्रस्ताव करते हैं, हम डिफ़ॉल्ट रूप से FILE_SHARE_DELETE का उपयोग करने के लिए Go libs को बदलते हैं, और फिर उपयोगकर्ताओं द्वारा उनके टूटे हुए प्रोग्राम के बारे में शिकायत करने की प्रतीक्षा करते हैं?

जैसा कि @mattn सुझाव देता है कि यह पूछने लायक भी है कि अन्य भाषाएं क्या करती हैं।

मैंने केवल मिंगव सी की जाँच की - यह गो की तरह ही व्यवहार करता है। एक बार फ़ाइल को fopen के साथ खोलने के बाद, इसे तब तक हटाया नहीं जा सकता जब तक fclose को कॉल नहीं किया जाता है। मुझे आश्चर्य होगा यदि कोई Microsoft विकास उपकरण (C, C++, C#, VB और अन्य) भिन्न हैं।

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

एलेक्स

7 साल पहले जोड़ा गया, मेरा मानना ​​है:
https://sourceforge.net/p/mingw-w64/code/HEAD/tree/stable/v3.x/mingw-w64-headers/include/ntdef.h#l858

अब तक, किसी ने भी गो ऐप के ऐसे मामले पोस्ट नहीं किए हैं जो वर्तमान अनिर्दिष्ट विंडोज व्यवहार पर निर्भर करते हैं। लेकिन हमने गो ऐप्स के कम से कम 4 मामले सुने हैं जो इसके कारण विंडोज़ पर विफल हो गए।

जैसा कि ऊपर कहा गया है, os.Remove() के बाद फ़ाइल नाम के पुन: उपयोग के लिए एक सरल समाधान है, जिसे हमें दस्तावेज़ करना चाहिए:
os.Rename(path, unique_path); os.Remove(unique_path)

अब तक, किसी ने भी गो ऐप के ऐसे मामले पोस्ट नहीं किए हैं जो वर्तमान अनिर्दिष्ट विंडोज व्यवहार पर निर्भर करते हैं।

इन लोगों को यह भी नहीं पता होता है कि गो बग्स की रिपोर्ट करना संभव है।

आपको उम्मीद नहीं करनी चाहिए कि ये उपयोगकर्ता इस उम्मीद में बदलाव के लिए गो इश्यू लिस्ट की निगरानी करेंगे कि कुछ उन्हें प्रभावित करेगा। उनके पास जीने के लिए जीवन है। यह हम पर है कि हम उन उपकरणों को न तोड़ें जिनका वे उपयोग करते हैं।

एलेक्स

एलेक्स, यह स्पष्ट है कि आप अनुनय-विनय कर रहे हैं। फिर मुझे आगे दो संभावित रास्ते दिखाई देते हैं ताकि लोग गो में पोर्टेबल कोड लिख सकें:

1. Open लिए एक नया ऑप्ट-इन फ़्लैग, जिसका अर्थ है विंडोज़ के लिए FILE_SHARE_DELETE और अन्य OSes के लिए अनदेखा किया जाता है। इसके बाद हम किसी को भी कोड लिखने के लिए प्रोत्साहित करेंगे जो POSIX शब्दार्थ को इस ध्वज को हर जगह पारित करने की अपेक्षा करता है; या,
2. एक नया गो पैकेज posix (कहीं रेपो में) एक फ़ंक्शन के साथ, Open , जो CreateFile को FILE_SHARE_DELETE के साथ लपेटता है लेकिन अन्यथा os.Open रूप में व्यवहार करता है। गैर-विंडोज प्लेटफॉर्म पर, यह सीधे os.Open कॉल करेगा। फिर हम हर जगह os.Open बजाय posix.Open का उपयोग करने के लिए POSIX शब्दार्थ की अपेक्षा करने वाले कोड लिखने वाले किसी भी व्यक्ति को प्रोत्साहित करेंगे।

इन दोनों दृष्टिकोणों के लिए लिनक्स डेवलपर्स को विंडोज़ पर पॉज़िक्स व्यवहार को संरक्षित करने के लिए अतिरिक्त कार्रवाई करने की आवश्यकता होती है, लेकिन कम से कम ये एक-ऑफ क्रिएटफाइल रैपर लिखने से बेहतर होते हैं (जैसे हमने अभी कंटेनर के लिए किया था)।

एलेक्स, यह स्पष्ट है कि आप अनुनय-विनय कर रहे हैं।

मैं राजी नहीं हूं। लेकिन आपको मुझे मनाने की जरूरत नहीं है, आपको गो टीम को मनाने की जरूरत है। वे निर्णय ले रहे होंगे।

1. Open लिए एक नया ऑप्ट-इन फ़्लैग, जिसका अर्थ है विंडोज़ के लिए FILE_SHARE_DELETE और अन्य OSes के लिए अनदेखा किया जाता है। इसके बाद हम किसी को भी कोड लिखने के लिए प्रोत्साहित करेंगे जो POSIX शब्दार्थ को इस ध्वज को हर जगह पारित करने की अपेक्षा करता है; या,

मुझे यह विकल्प भी पसंद नहीं है।

सबसे पहले, ओएस पैकेज किसी भी ओएस के लिए उपलब्ध सुविधा प्रदान करने वाला है। OS विशिष्ट कुछ भी syscall, या golang.org/x/sys/windows, या जो भी अन्य पैकेज हमें पसंद हो, उसमें जाना चाहिए।

दूसरा, मुझे चिंता है कि मैं अपने प्रोग्राम में FILE_SHARE_DELETE फ़ाइल प्रकार के साथ समाप्त हो जाऊंगा, भले ही मैं नहीं चाहता। कल्पना कीजिए, अगर मैं बाहरी पैकेज आयात करता हूं जो FILE_SHARE_DELETE फ़ाइल मोड का उपयोग करने का निर्णय लेता है। मुझे कैसे पता चलेगा, कि मेरा कुछ कोड FILE_SHARE_DELETE का उपयोग करता है? मुझे पैकेज स्रोत कोड grep करना होगा। या पैकेज प्रलेखन को अपने उपयोगकर्ताओं को चेतावनी देनी होगी। मुझे लगता है, यह भी हो सकता है, अगर कुछ पैकेज लेखक सीधे syscall.CreateFile का उपयोग FILE_SHARE_DELETE करते हैं। लेकिन, मुझे लगता है, अगर ओएस पैकेज के लिए FILE_SHARE_DELETE धन्य है, तो यह अधिक सामान्य होगा। मुझे संदेह है, लिनक्स उपयोगकर्ता, जो विंडोज के बारे में कुछ नहीं जानते हैं, डिफ़ॉल्ट रूप से इस ध्वज का उपयोग अपने लिनक्स प्रोग्राम पोर्ट को विंडोज़ के लिए "आसान" बनाने के लिए करेंगे।

तीसरा, हमें FILE_SHARE_DELETE ध्वज का दस्तावेजीकरण करना होगा। हम केवल POSIX नहीं कह सकते। हमें यह बताना होगा कि झंडा क्या करता है। सरल शब्दों में। यह भी याद रखें:

वास्तव में, यह बिल्कुल यूनिक्स के समान शब्दार्थ नहीं है।

फ़ाइल को हटाने के बाद आप उसी नाम की फ़ाइल नहीं बना सकते हैं या उस निर्देशिका को हटा नहीं सकते हैं जब तक कि हैंडल बंद न हो जाए।

हालाँकि, कोई फ़ाइल को हटाने से पहले फ़ाइल को कहीं और (जैसे रूट डायरेक्टरी) ले जाकर उसके आसपास काम कर सकता है।

https://github.com/golang/go/issues/32088#issuecomment -504321027 से। हमें उसका भी दस्तावेजीकरण करना होगा। और अन्य सभी कार्यक्षमता जो FILE_SHARE_DELETE ध्वज लाती है।

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

2. एक नया गो पैकेज posix (कहीं रेपो में) एक फ़ंक्शन के साथ, Open , जो CreateFile को FILE_SHARE_DELETE के साथ लपेटता है लेकिन अन्यथा os.Open रूप में व्यवहार करता है

मैं नहीं देखता कि यह कैसे संभव है। लेकिन, यदि यह संभव है, तो आपको स्वयं पैकेज बनाने में सक्षम होना चाहिए। उदाहरण के लिए, github.com/jstarks/posix के रूप में। नहीं? हम पैकेज को golang.org/x/sys/windows/posix या कुछ और के तहत जोड़ सकते हैं, लेकिन मुझे ज्यादा अंतर नहीं दिखता।

एलेक्स

ओएस पैकेज किसी भी ओएस के लिए उपलब्ध सुविधा प्रदान करने वाला है ...
हमें FILE_SHARE_DELETE ध्वज का दस्तावेजीकरण करना होगा। हम सिर्फ पॉज़िक्स नहीं कह सकते ...
हमें FILE_SHARE_DELETE के लिए नए परीक्षण जोड़ने होंगे। ये परीक्षण क्या होंगे?

इन सभी को ऊपर संबोधित किया गया था।

अगर मैं बाहरी पैकेज आयात करता हूं जो FILE_SHARE_DELETE फ़ाइल मोड का उपयोग करने का निर्णय लेता है। मुझे कैसे पता चलेगा

इसे डिफ़ॉल्ट बनाने और इसे अक्षम करने के लिए वैश्विक ध्वज प्रदान करने के लिए यह एक और तर्क है।

मैंने प्रभावित विंडोज़ ऐप्स की तलाश के लिए गोलांग-नट्स पर पोस्ट किया; मैं इसे दृश्यमान बनाए रखने के लिए इसे हर कुछ दिनों में पिंग करूंगा। यदि वह बहुत अधिक सतह पर नहीं आता है, तो इसे 1.14 के लिए टिप पर डिफ़ॉल्ट बनाकर चीजों को स्पष्ट करना चाहिए।
https://groups.google.com/d/topic/golang-nuts/8BiP_mPoCd4/discussion

इसे डिफ़ॉल्ट बनाने और इसे अक्षम करने के लिए वैश्विक ध्वज प्रदान करने के लिए यह एक और तर्क है।

बीटीडब्ल्यू। उस ध्वज को Linux पर क्या करना चाहिए? Afau हम वास्तव में लिनक्स में फ़ाइलों को खोलने के लिए कार्यक्षमता को भी याद करते हैं कि उन्हें अन्य प्रक्रियाओं द्वारा हटाया नहीं जा सकता है? इस https://gavv.github.io/articles/file-locks/#open -file-description-locks-fcntl के आधार पर इसे लिनक्स के आधुनिक संस्करणों पर लागू करना संभव होना चाहिए।

ध्वज (जैसे var OpenWithout_FILE_SHARE_DELETE = false ) को syscall_windows.go में परिभाषित किया जाएगा, क्योंकि यह syscall.Open() के व्यवहार को प्रभावित करता है।

कुछ Linux-विशिष्ट के लिए एक ध्वज का एक अलग नाम होगा, और syscall_linux.go में परिभाषित किया जाएगा। ऑफहैंड मुझे नहीं पता कि इसकी निर्देशिका पर अनुमतियों के अलावा लिनक्स पर एक खुली फ़ाइल को हटाने से कैसे रोका जाए। आपके द्वारा प्रदान किया गया लिंक "सलाहकार" लॉकिंग का वर्णन करता है।

@jstarks इससे पहले कि हम FILE_SHARE_DELETE ध्वज को पेश करने पर विचार करें, हमें यह भी तय करना होगा कि चल रही निष्पादन योग्य फ़ाइल को हटाने में असमर्थता के बारे में क्या करना है। मुझे नहीं लगता कि FILE_SHARE_DELETE झंडा यहां हमारी मदद कर सकता है। यह कर सकते हैं? यदि हम निष्पादन योग्य फ़ाइल को हटाना लागू नहीं कर सकते हैं जो अभी भी चल रही है, तो हम किसी भी POSIX संगतता का दावा नहीं कर सकते। और FILE_SHARE_DELETE झंडा आधा समाधान जैसा दिखता है।

इससे भी अधिक, कभी-कभी हम उस प्रक्रिया की निष्पादन योग्य फ़ाइल को हटाने में विफल हो जाते हैं जो समाप्त भी हो जाती है। उदाहरण के लिए, विवरण के लिए #25965, #19491 और #32188 देखें। मूल रूप से हम WaitForSingleObject को प्रोसेस हैंडल पर सिग्नल होने तक कॉल करते हैं। लेकिन यह गारंटी नहीं देता कि निष्पादन योग्य फ़ाइल को हटाया जा सकता है। फ़ाइल को हटाने का प्रयास करने से पहले हमें 5 मिलीसेकंड प्रतीक्षा जोड़नी पड़ी। और वह भी हमेशा काम नहीं करता - https://github.com/golang/go/issues/25965#issuecomment -482037476

इसके अलावा, इस मुद्दे से असंबंधित, लेकिन, यह देखते हुए कि मुझे आपका ध्यान है, हो सकता है कि आप विंडोज़-आर्म पोर्ट को पुनर्जीवित करने में हमारी सहायता कर सकें। विवरण के लिए #32135 देखें। मूल रूप से @ jordanrh1 पोर्टेड विंडोज़-आर्म पर जाएं, लेकिन हमारे पास अब विंडोज़-आर्म बिल्डर नहीं है। इसलिए हम यह भी नहीं जानते कि पोर्ट अभी भी काम कर रहा है या टूटा हुआ है। यदि आप हमें बिल्डर चलाने में मदद कर सकते हैं, तो शायद हम विंडोज़-एम पोर्ट का समर्थन करने का प्रयास कर सकते हैं। अन्यथा पोर्ट हटा दिया जा सकता है - https://github.com/golang/go/wiki/PortingPolicy मुझे नहीं पता, अगर कोई विंडोज 10 आईओटी पर गो प्रोग्राम चलाने में दिलचस्पी रखता है, लेकिन हमारे पास पहले से ही यह समर्थन है। इसे सिर्फ इसलिए खोना दुखद होगा क्योंकि हमारे पास काम करने वाला बिल्डर नहीं है।

शुक्रिया।

एलेक्स

अस्थायी निष्पादन योग्य हटाने के लिए इस सुझाए गए समाधान पर ध्यान दें: https://github.com/golang/go/issues/25965#issuecomment -495636291

गोलंग-नट्स पोस्ट से कोई परिणाम नहीं; एक नया सूत्र शुरू किया:
https://groups.google.com/d/topic/golang-nuts/aRvSo3iKvJY/discussion

कम से कम एक गैर-काल्पनिक चिंता जो मुझे लगता है कि जांच की जानी चाहिए, वह फ़ाइल लॉकिंग और उस पर भरोसा करने वाले कार्यक्रमों पर प्रभाव होगा।

प्रत्येक फ़ाइल हैंडल को FILE_SHARE_DELETE साथ खोलना प्रभावी रूप से LockFileEx के शब्दार्थ को POSIX सलाहकार तालों से कमजोर कर देगा, क्योंकि निर्दिष्ट FILE_SHARE_DELETE किसी भी फ़ाइल को हटाया जा सकता है, भले ही कोई लॉक हो उस फ़ाइल के एक क्षेत्र पर आयोजित किया गया। ¹

बेशक यह केवल LockFileEx कॉल पर लागू होगा, जो डिस्क्रिप्टर के साथ os.File.Fd से लौटाया गया है, लेकिन यह वही है जो सबसे लोकप्रिय गो फ़ाइल लॉकिंग लाइब्रेरी में किया गया है (जिसमें वर्तमान में 33 ज्ञात आयातक हैं , जिसमें डॉकर भी शामिल है) , gVisor, और Kubernetes)। यह टेराफॉर्म में भी किया जाता है, और LockFileEx का उपयोग अन्य गो कोड के भार में किया जाता है।

मुझे अभी भी लगता है कि यह बदलाव सबसे अच्छे मामले में (और सबसे खराब स्थिति में एक सीवीई-फैक्ट्री) एक गैर-सलाह प्रयास की तरह लगता है। मैं वास्तव में नहीं देखता कि कैसे होने वाले स्पष्ट कोड टूटने से नकली लाभ होता है।

मुझे यह भी लगता है कि अधिकांश गोलंग-नट्स उपयोगकर्ता इस परिवर्तन के प्रभावों को पूरी तरह से समझने नहीं जा रहे हैं। गो टीम की अनुमति से, गोलांग-देव पर एक पोस्ट चर्चा उत्पन्न करने में अधिक प्रभावी हो सकती है (विशेषकर चूंकि यह एक मुख्य परिवर्तन है)। वास्तव में, यह तकनीकी रूप से गो टूलचैन को प्रभावित करता है, जो उपरोक्त तरीके से LockFileEx का भी उपयोग करता है ।

¹ हां, मुझे पता है कि कुछ विंडोज़ लॉक प्रवर्तन अभी भी पॉज़िक्स की तुलना में अधिक मजबूत होंगे, लेकिन यदि आप फ़ाइल को न्यूक कर सकते हैं, तो संसाधन आरक्षण के लिए लॉक फ़ाइल का उपयोग विंडो से बाहर हो जाता है।

जब मैंने इस मुद्दे को खोला तो मैंने गोलांग-देव को पोस्ट किया।
https://groups.google.com/d/topic/golang-dev/R79TJAzsBfM/discussion

क्या आपके द्वारा सूचीबद्ध पुस्तकालयों में से कोई भी GOOS=windows व्यवहार पर निर्भर करता है? आपने बार-बार दावा किया है कि यह परिवर्तन मौजूदा कोड को तोड़ देगा, लेकिन कभी कोई सबूत नहीं दिया।

कृपया सनसनीखेज असमर्थनीय बयान देना बंद करें। यह कुछ भी स्पष्ट नहीं करता है, और मुझे यह आपत्तिजनक लगता है।

जब मैंने इस मुद्दे को खोला तो मैंने गोलांग-देव को पोस्ट किया। https://groups.google.com/d/topic/golang-dev/R79TJAzsBfM/discussion

ऐसा लगता है कि वहां मौजूद सभी लोगों ने अपने-अपने कारणों से इस विचार को खारिज कर दिया (उनमें से सभी इस धागे में पहले बताए गए लोगों के समान हैं), लेकिन अगर अब इस बदलाव को गो 1.14 में लागू करने के लिए विचार किया जा रहा है, तो उस पर एक अनुवर्ती कार्रवाई धागा उपयोगी हो सकता है (इस चर्चा के लिए एक अनुस्मारक लिंक के साथ)।

क्या आपके द्वारा सूचीबद्ध पुस्तकालयों में से कोई भी GOOS=windows व्यवहार पर निर्भर करता है? आपने बार-बार दावा किया है कि यह परिवर्तन मौजूदा कोड को तोड़ देगा, लेकिन कभी कोई सबूत नहीं दिया।

निश्चित रूप से कहने के लिए इसके लिए पूर्ण सुरक्षा मूल्यांकन ( बहुत सारे कोड) की आवश्यकता होगी। मुझे लगता है कि मैंने निश्चित रूप से पर्याप्त सबूत प्रदान किए हैं कि लोग व्यवहार पर भरोसा कर रहे हैं जो इस ध्वज की शुरूआत के साथ स्पष्ट रूप से बदल जाएगा। और वह GitHub पर सार्वजनिक रूप से उपलब्ध कोड है।

कृपया सनसनीखेज असमर्थनीय बयान देना बंद करें। यह कुछ भी स्पष्ट नहीं करता है, और मुझे यह आपत्तिजनक लगता है।

यदि लिंक और कोड पर्याप्त समर्थन नहीं कर रहे हैं, तो मुझे नहीं पता कि आपकी पुस्तक में क्या होगा। आपको ऐसा कोड नहीं मिलेगा जो इस परिवर्तन के कारण संकलित करना बंद कर दे, लेकिन आपको निश्चित रूप से ऐसा कोड मिलेगा जो इसके साथ अलग तरह से व्यवहार करता है, और बहुत से लोग उस कोड को "टूटा हुआ" मानते हैं क्योंकि व्यवहार में उन परिवर्तनों के कारण।

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

जैसा कि मैंने ऊपर बताया, FILE_SHARE_DELETE के साथ फ़ाइल को हटाने में UNIX की एक जैसी विशेषता नहीं है। उदाहरण के लिए, कृपया इन चरणों का प्रयास करें।

main.c

#include <windows.h>
#include <stdio.h>

int
main() {
  // ensure delete the file
  DeleteFile("test.txt");

  // create test.txt with FILE_SHARE_DELETE
  HANDLE h = CreateFile("test.txt",
      GENERIC_READ | GENERIC_WRITE,
      FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
      NULL, OPEN_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
  puts("waiting 10sec, please run watch.exe on another cmd.exe");
  Sleep(10000);
  if (DeleteFile("test.txt")) {
    puts("deleted");
  }
  getchar();
  return 0;
}

घड़ी.सी

#include <stdio.h>
#include <shlwapi.h>

int
main() {
  // waiting test.txt will be removed.
  while (PathFileExists("test.txt")) {
    puts("watching...");
    Sleep(1000);
  }
  // now test.txt should not exists. So this is possible to create new file
  system("notepad test.txt");
  return 0;
}

मेकफ़ाइल

all : main.exe watch.exe

watch.exe : watch.c
    gcc -o watch.exe watch.c -lshlwapi

main.exe : main.c
    gcc -o main.exe main.c

सबसे पहले, कृपया main.exe चलाएँ और अगला watch.exe चलाएँ। UNIX पर, अनलिंक(2) फ़ाइल को तुरंत हटा दें। तो एक अन्य प्रक्रिया जो फ़ाइल को देख रही है वह एक ही फ़ाइल नाम के साथ नई फ़ाइल बना सकती है। लेकिन विंडोज़ पर, notepad.exe एक त्रुटि संवाद "एक्सेस उल्लंघन" दिखाता है क्योंकि विंडोज़ फ़ाइल को तुरंत नहीं हटाता है। मैं आपको नहीं बता सकता कि इससे क्या होगा। सुरक्षा का मसला? महत्वपूर्ण फाइलें खो गईं? क्षमा करें, मुझे नहीं पता।

@ हैवोक-आईओ विंडोज़ बंद होने तक एक खुली फाइल को नहीं हटाएगा, और केवल खुली फाइलों के लिए ताले रखेगा। तो लॉकिंग का उपयोग os.Remove() की विफलता पर निर्भरता नहीं दर्शाता है। कृपया ऐसे उदाहरण प्रदान करें जो विशेष रूप से उस विफलता पर निर्भर करते हैं।

मैं अगले सप्ताह गोलांग-देव सूत्र को पिंग करूँगा। दो पीपीएल ने इसका जवाब दिया; किसी ने इस मुद्दे को नहीं पढ़ा था, और न ही कोई उदाहरण दिया था।

सनसनीखेज, असमर्थनीय दावे "स्वस्थ प्रतिरोध" नहीं हैं।

@ हैवोक-आईओ विंडोज़ बंद होने तक एक खुली फाइल को नहीं हटाएगा, और केवल खुली फाइलों के लिए ताले रखेगा। तो लॉकिंग का उपयोग os.Remove() की विफलता पर निर्भरता नहीं दर्शाता है। कृपया ऐसे उदाहरण प्रदान करें जो विशेष रूप से उस विफलता पर निर्भर करते हैं।

@networkimprov आप दो अलग-अलग प्रकार के लॉकिंग का

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

यदि LOCKFILE_FAIL_IMMEDIATELY ध्वज को छोड़ दिया जाता है, तो लॉक फ़ाइलों का उपयोग पाइपलाइन कमांड के लिए भी किया जा सकता है, जिससे LockFileEx लॉक अधिग्रहण के लिए अपनी बारी का इंतजार कर सकता है। यदि लॉक फ़ाइल अनजाने में हटा दी जाती है, तो यह एक साथ कई कमांड निष्पादित करने का कारण बन सकती है जिसे पाइपलाइन किया जाना चाहिए था।

सनसनीखेज, असमर्थनीय दावे "स्वस्थ प्रतिरोध" नहीं हैं।

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

कृपया WinAPI दस्तावेज़ों की समीक्षा करें; विंडोज़ बंद होने तक एक खुली फ़ाइल को नहीं हटाएगा, और केवल खुली फाइलों के लिए LockFileEx() लॉक रखता है, इसलिए फ़ाइल बंद होने पर लॉक जारी नहीं रह सकता है, भले ही हटाए जाने के बावजूद। डिलीट के बाद एक लॉक (यानी ओपन) फाइल को खोलने के प्रयास में एक त्रुटि दिखाई देगी, इसलिए कोई दूसरा लॉक हासिल नहीं किया जा सका। लॉक पर प्रतीक्षा कर रहे थ्रेड में फ़ाइल खुली होती है, इसलिए हटाए जाने से बाधित नहीं होगी।

जब तक मैं दस्तावेज़ों को गलत तरीके से नहीं पढ़ता, आपके पिछले दो परिदृश्य असमर्थित हैं। और यह सनसनीखेज और असमर्थित था: "यह परिवर्तन ऐसा लगता है ... सबसे खराब स्थिति में एक सीवीई-कारखाना। मैं वास्तव में नहीं देखता कि स्पष्ट कोड टूटने से होने वाले अस्पष्ट लाभ कैसे होते हैं।"

@networkimprov समस्या यह है कि संसाधन-प्रतिबंधित लॉक फ़ाइलें आमतौर पर फ़ाइल पथ पर आधारित होती हैं। फ़ाइल बंद होने तक अंतर्निहित फ़ाइल ऑब्जेक्ट को हटाया नहीं जा सकता है, लेकिन यदि DeleteFile माध्यम से हटा दिया जाता है, तो यह फाइल सिस्टम ¹ पर पिछले पथ पर पहुंच योग्य नहीं होगा, और यह अन्य लॉक फ़ाइलों को बनाने की अनुमति देगा उस पथ पर, लॉक फ़ाइल के उद्देश्य को नकारते हुए।

मुझे नहीं लगता कि यह एक सनसनीखेज टिप्पणी थी - यह बहुत स्पष्ट लगता है कि ऐसा कुछ सुरक्षा समस्या का कारण बन सकता है यदि कोड कुछ ओएस इनवेरिएंट पर निर्भर है जो अब सत्य नहीं हैं। और यहां लाभ बहुत अस्पष्ट लगते हैं (जैसा कि कई लोगों ने टिप्पणी की है: यह विंडोज़ व्यवहार को पॉज़िक्स के साथ संरेखित नहीं करता है) और टूटना बहुत स्पष्ट प्रतीत होता है (यह कम से कम कुछ लॉकिंग व्यवहार तोड़ता है)।

¹ कम से कम ऐसा लगता है जब परीक्षण और इस टिप्पणी के आधार पर।

पुन: "विंडोज के नवीनतम संस्करण में, हमने https://github.com/golang/go/issues/ से 'POSIX' डिलीट करने के लिए DeleteFile (NTFS पर) को अपडेट किया, जहां फ़ाइल को नेमस्पेस से तुरंत हटा दिया गया"।

पुन: लाभ, मुझे लगता है कि आपको पूरे सूत्र की समीक्षा करनी चाहिए।

AFAIK विंडोज का वह संस्करण जारी नहीं किया गया है।

@networkimprov मेरा मानना ​​​​है कि यह विंडोज 10 पर पहले से ही मामला है। मुझे लगता है कि मैं LockFileEx साथ लॉक की गई फ़ाइल को निकालने में सक्षम हूं यदि फ़ाइल खोलते समय FILE_SHARE_DELETE को CreateFileW निर्दिष्ट किया जाता है।

DeleteFileW() उस परिदृश्य में कोई त्रुटि नहीं देगा। आप कैसे जानते हैं कि इसे फाइल सिस्टम से तुरंत हटा दिया गया था, बनाम फाइल/ऐप पर हटा दिया गया था? क्या आपने फ़ाइल को हटाने के बाद उसे खोलने/फिर से बनाने का प्रयास किया?

वास्तव में, यह तकनीकी रूप से गो टूलचेन को प्रभावित करता है, जो _also_ उपरोक्त तरीके से LockFileEx का उपयोग करता है।

go कमांड के भीतर हम बहुत अधिक POSIX शब्दार्थ चाहते हैं, और किसी भी तरह से FILE_SHARE_DELETE की अनुपस्थिति पर भरोसा नहीं करना चाहिए। वास्तव में, मैंने cmd/go/internal/robustio पैकेज को विशेष रूप से _काम करने के लिए जोड़ा है जिस तरह से विंडोज़ फ़ाइल-लॉकिंग पॉज़िक्स से विचलित हो जाती है।

@ianlancetaylor मैंने गोलांग-नट्स और -देव को बार-बार पोस्ट किया है जो किसी भी परियोजना से टिप्पणी मांग रहा है जो वर्तमान (अनियंत्रित) विंडोज syscall.Open() व्यवहार पर निर्भर करता है। एक भी उपयोग का मामला सामने नहीं आया है।

चूंकि कई उपयोग के मामले जिन्हें FILE_SHARE_DELETE की आवश्यकता है, ऊपर दिखाई दिए हैं (और चूंकि Microsoft ने विशेष रूप से अनुरोध किया है कि हम इसका उपयोग करें), आइए इस ध्वज को पूर्व-रिलीज़ 1.14 में डिफ़ॉल्ट रूप से सेट करें, और चक्र के दौरान मूल व्यवहार सतह के लिए किसी भी उपयोग के मामलों का पुनर्मूल्यांकन करें।

जैसा कि इस थ्रेड में पहले सुझाया गया था, कोई व्यक्ति जिसे इस ध्वज के बिना एक open() कॉल की आवश्यकता है, वह CreateFileW() & os.NewFile() का उपयोग करके अपना स्वयं का रोल कर सकता है।

क्या हम इसके लिए कम से कम एक घुंडी का पर्दाफाश कर सकते हैं?

विंडोज़ पर लॉग रोटेशन को लागू करने के लिए यह बहुत उपयोगी है।

विंडोज़ पर लॉग रोटेशन को लागू करने के लिए यह बहुत उपयोगी है।

मुझे यकीन नहीं है लेकिन मुझे लगता है कि यह काम नहीं करेगा क्योंकि FILE_SHARE_DELETE फ़ाइल का हैंडल बंद नहीं होने पर मूल फ़ाइल नाम के साथ नई फ़ाइल बनाने की अनुमति नहीं देता है।

@ रैंडम-लियू क्या आप ओपन() पर fsd को सक्षम करने या इसे अक्षम करने का तरीका पूछ रहे हैं?

@mattn यह मेरे लिए काम करता है। os.Rename पुरानी लॉग फ़ाइल के बाद, मैं ओरिजिनल नाम के साथ एक नई लॉग फ़ाइल बना सकता हूं, और लॉग फ़ाइल को फिर से खोलने के लिए डेमॉन को सूचित कर सकता हूं।

@networkimprov मैं FILE_SHARE_DELETE को सक्षम करने का एक तरीका चाहता हूं। मैं वर्तमान में सीधे syscall.CreateFile का उपयोग कर रहा हूं।

मेरा विंडोज़ संस्करण:

Major  Minor  Build  Revision
-----  -----  -----  --------
10     0      17763  0

@ रैंडम-लियू लेकिन मुझे लगता है कि हम इसका उपयोग यूनिक्स व्यवहार को अनुकरण करने के लिए नहीं कर सकते हैं।

https://github.com/golang/go/issues/32088#issuecomment -510345908

बाहरी एप्लिकेशन मूल फ़ाइल नाम तक नहीं पहुंच सकता।

मैटन, उस बिंदु को दोहराते रहने की कोई आवश्यकता नहीं है। यह पहले ही कहा जा चुका है कि जब हैंडल बंद होने से पहले फ़ाइल नाम को पुन: प्रयोज्य किया जाना चाहिए, तो हमें इसे हटाने से पहले फ़ाइल का नाम बदलने की आवश्यकता (विंडोज़ पर) का दस्तावेजीकरण करना चाहिए।

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

@ianlancetaylor पुनः प्रयास करें :

मैंने इस मुद्दे को रिलीज अवरोधक के रूप में चिह्नित किया है।

@bcmills क्या मैं आपको CL पोस्ट करने में दिलचस्पी

यह पंक्ति: https://golang.org/src/syscall/syscall_windows.go#L291
बस जरूरत है: sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE)

संपादित करें: इसे सत्यापित करने के लिए एक परीक्षण एक फ़ाइल बनाएगा, फिर इसे बंद करने से पहले इसका नाम बदलने का प्रयास करें।

हमें जल्द ही इसकी आवश्यकता है ताकि फ्रीज से पहले किसी भी मुद्दे के सामने आने का समय हो...

इसके अलावा os.Remove() दस्तावेज़ों में उल्लेख होना चाहिए कि विंडोज़ पर, फ़ाइल बंद होने से पहले फ़ाइल नाम को पुन: उपयोग के लिए उपलब्ध होने की आवश्यकता होने पर हटाए जाने से पहले एक खुली फ़ाइल का नाम बदला जाना चाहिए। Windows किसी खुली हुई फ़ाइल को बंद होने तक डिलीट नहीं करता है।

ऐसा लगता है कि विंडोज़ का नवीनतम संस्करण https://github.com/golang/go/issues/32088#issuecomment -502850674 को पूरा करता है। विवरण के लिए https://github.com/papertrail/go-tail/pull/10#issuecomment -529460973 देखें। अब हम हटाए गए फ़ाइल के नाम का पुन: उपयोग करने में सक्षम हैं, भले ही पुरानी फ़ाइल में अभी भी खुले हैंडल हों, बशर्ते कि वे हैंडल FILE_SHARE_DELETE साझाकरण मोड के साथ खोले गए हों। हटाने से पहले नाम बदलने की जरूरत नहीं है। शायद गो में डिफ़ॉल्ट रूप से FILE_SHARE_DELETE सेट करना समझ में आता है?

यही इरादा है; हमें सीएल जमा करने के लिए बस किसी की जरूरत है। (मैं चाहता हूं, लेकिन मैं सीएलए पर हस्ताक्षर नहीं कर सकता।)
मेरी पिछली दो टिप्पणियाँ आवश्यक परिवर्तनों का वर्णन करती हैं...

@jstarks @jordanrh1 @thaJeztah

प्रश्न:
हम एक सुसंगत व्यवहार कैसे प्राप्त करते हैं?
यदि प्रोग्राम "नवीनतम विंडोज़" पर चलता है तो यह "लंबित डिलीट" फ़ाइल के समान नाम वाली फ़ाइल बनाने की अनुमति देगा, पुराना संस्करण त्रुटि पर टूट जाएगा।

यह वास्तव में कह सकता है: "परीक्षा उत्तीर्ण / क्यूए लेकिन अधिकांश लक्ष्यों पर काम नहीं करता", और
भविष्य में "आमतौर पर काम करता है, और कभी-कभी नहीं" (अब से 2 साल दूर एक डेवलपर "फ़ाइल पहले से ही बाहर निकलें" त्रुटि को पुन: उत्पन्न करने में सक्षम नहीं होगा)।

हमें यह पता लगाने की आवश्यकता है कि 'पुराने' संस्करणों की पहचान कैसे करें और या तो उनके लिए डिफ़ॉल्ट व्यवहार को बदलें या त्रुटि में सुधार करें यदि "कोई लंबित विलोपन है" - मुझे यकीन नहीं है कि हम यह कैसे कर सकते हैं।
और अगर हम नहीं कर सकते, तो हम असंगति से कैसे निपटते हैं।

@guybrand जैसा कि ऊपर बताया गया है, हम यह दस्तावेज करेंगे कि विंडोज़ पर "फ़ाइल बंद होने से पहले फ़ाइल नाम को पुन: उपयोग के लिए उपलब्ध होने की आवश्यकता होने पर हटाए जाने से पहले एक खुली फ़ाइल का नाम बदला जाना चाहिए।"

यह पुराने और नए विंडोज संस्करणों के साथ-साथ पॉज़िक्स के लिए भी काम करता है।

यह एक अलग दृष्टिकोण की तरह लगता है: "हमेशा पुन: उपयोग करने से पहले नाम बदलें, यहां तक ​​​​कि नए विंडोज़ या पॉज़िक्स पर भी"
मुझे यह पसंद है - यह एक सामान्य अभ्यास का समर्थन करता है जो हर जगह सफल होगा।

बदलें https://golang.org/cl/194957 इस मुद्दे का उल्लेख करता है: syscall: allow FILE_SHARE_DELETE on syscall.Open on Windows

golang-nuts धागा यहाँ है , और इसका कोई जवाब नहीं था। ऐसा लगता है कि कोई भी जो golang-nuts पढ़ता है और इस व्यवहार के बारे में जानता है, उस पर भरोसा नहीं कर रहा है।

golang-dev धागे यहां और यहां हैं , और बाद वाले (सबसे हाल के धागे) को भी कोई आपत्ति नहीं है।

@alexbrainman -2'd CL निर्णय की स्पष्ट कमी के आधार पर इसे लागू करने के लिए, इसलिए मैंने इस मुद्दे को NeedsDecision रूप में पुनः लेबल किया है ताकि हम एक स्पष्ट दिशा प्राप्त कर सकें।

व्यक्तिगत रूप से, मेरे लिए निर्णय स्पष्ट प्रतीत होता है: यह देखते हुए कि इस धागे पर माइक्रोसॉफ्ट के लोग FILE_SHARE_DELETE (https://github.com/golang/go/issues/32088) का उपयोग करने के लिए डिफ़ॉल्ट व्यवहार को बदलने के समर्थन में हैं। #issuecomment-502850674), और यह कि golang-nuts पर कोई भी किसी भी तरह से परवाह नहीं करता है, मुझे लगता है कि हमें यह करना चाहिए।

इस सूत्र पर मैंने जो आपत्तियाँ देखी हैं, वे दो श्रेणियों में आती हैं:

1. @alexbrainman की चिंता (https://github.com/golang/go/issues/32088#issuecomment-504321027) और @mattn (https://github.com/golang/go/issues/32088#issuecomment-494417146) ऐसा लगता है कि चूंकि व्यवहार अभी भी POSIX से मेल नहीं खाएगा, इसलिए POSIX शब्दार्थ की अपेक्षा करने वाले उपयोगकर्ता भ्रमित हो सकते हैं। (लेकिन यह पहले से ही मामला है कि विंडोज़ पर Open पॉज़िक्स सेमेन्टिक्स प्रदान नहीं करता है, इसलिए मेरे लिए यह चिंता प्रस्तावित परिवर्तन से स्वतंत्र लगती है।)

2. @ havoc-io की चिंता (https://github.com/golang/go/issues/32088#issuecomment-510314947) ऐसा प्रतीत होता है कि FILE_SHARE_DELETE विंडोज़ पर चलने पर फ़ाइल-लॉकिंग पैकेज द्वारा प्रदान किए गए इनवेरिएंट को कम कर देगा . लेकिन यह तर्क मेरे लिए थोड़ा भ्रमित करने वाला लगता है, क्योंकि एक उदाहरण के रूप में रखा गया ठोस पैकेज ( github.com/gofrs/flock ) स्पष्ट रूप से नोट करता है कि "लॉकिंग व्यवहार प्रत्येक प्लेटफॉर्म पर समान होने की गारंटी नहीं है", और एक त्वरित ऑडिट से कोई भी ठोस उदाहरण लॉकिंग और फ़ाइल हटाने के बीच विंडोज़-विशिष्ट इंटरैक्शन पर भरोसा नहीं करता है।

https://github.com/golang/go/issues/32088#issuecomment -498690757 में टिप्पणी मुझे साज़िश करती है, हालांकि:

मैं सहमत हूं कि @ianlancetaylor पूरे https://codereview.appspot.com/823043/ में प्रस्तावित है, यह एक अच्छा विचार नहीं है। एक फ़ाइल हैंडल को लॉक फ़ाइल के रूप में उपयोग करते समय इस प्रस्ताव को ध्यान में रखने वाली एक तत्काल समस्या है। हम इस व्यवहार का उपयोग करते हैं।

@maruel , क्या आप इस बारे में कुछ और विवरण दे सकते हैं कि आपका प्रोग्राम फ़ाइल-लॉकिंग और फ़ाइल हटाने या नाम बदलने के बीच विंडोज़-विशिष्ट इंटरैक्शन पर कैसे निर्भर करता है?

हम क्रोम इंफ्रा में फ़ाइल उपस्थिति का उपयोग लॉकिंग तंत्र के रूप में करते हैं। मैं कहूंगा कि इस उपयोग के मामले के बारे में ज्यादा चिंता न करें। व्यवहार में जो मैं समझता हूं उससे O_CREATE + FILE_FLAG_DELETE_ON_CLOSE शब्दार्थ इस आवश्यकता के लिए पर्याप्त हैं और इसे Global\\ नेमस्पेस में एक म्यूटेक्स से बदला जा सकता है, जो हम पहले से ही पायथन कोड बेस में करते हैं।

इस समाधान का उल्लेख नहीं है:

path := "delete-after-open"
fd, err := os.OpenFile(path, os.O_RDWR|os.O_CREATE, 0600)
if err != nil { ... }
// defer statements are executed in LIFO
defer os.Remove(path)            // or defer os.Rename(path, path+"2")
if err != nil { ... }
defer fd.Close()

इसकी दो कमियां हैं:

• बंद करें () ओपन के ठीक बाद नहीं है ()
• त्रुटि कोड पुनर्प्राप्त करना अधिक जटिल है

@iwdgo यह समाधान एकल प्रक्रिया उपयोग के लिए है। ऊपर की अधिकांश चर्चा कई प्रक्रियाओं से समवर्ती पहुंच के बारे में है। यही ध्वज को महत्वपूर्ण बनाता है।

मुद्दे के पुनर्मूल्यांकन देखे :

Mingw-w64 ने इसे सात साल पहले डिफ़ॉल्ट बना दिया था:
https://sourceforge.net/p/mingw-w64/code/HEAD/tree/stable/v3.x/mingw-w64-headers/include/ntdef.h#l858

Erlang ने इसे छह साल पहले डिफ़ॉल्ट बना दिया था: erlang/ otp@0e02f48

जिस समय उन्होंने इस पर विचार किया, उस समय MSVC रनटाइम की सीमाओं के कारण पायथन इसे अपना नहीं सका: https://bugs.python.org/issue15244

एक दूसरे गोलंग-नट्स थ्रेड ने भी कोई आपत्ति नहीं देखी:
https://groups.google.com/d/topic/golang-nuts/aRvSo3iKvJY/discussion

क्या आप Open() के लिए डिफ़ॉल्ट रूप से FILE_SHARE_DELETE बनाना चाहते हैं? हमारी चर्चा यह नहीं होनी चाहिए।

1. @alexbrainman ( #32088 (टिप्पणी) ) की चिंता ... ऐसा लगता है कि व्यवहार अभी भी POSIX से मेल नहीं खाएगा ...

मेरी मुख्य चिंता लोगों के कार्यक्रमों को तोड़ना है। जैसा कि https://codereview.appspot.com/8203043/#msg10 पर कहा है।

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

हम यहां गो 1.0 प्रोग्राम के व्यवहार को चुपचाप नहीं बदल सकते, शायद लोग
वास्तव में इस पर निर्भर हैं।

यहां गो 1.0 संगतता वादे का क्या हुआ? जहां https://golang.org/doc/go1compat में यह कहा गया है, कि यदि आप go-nuts पर अपने इरादे की घोषणा करते हैं, तो खुले फ़ाइल व्यवहार को बदलना ठीक है?

एक बार जब हम गो 2 को पेश कर देते हैं तो शायद हम इस व्यवहार को बदल सकते हैं? क्या हम मौजूदा कोड को टूटने से बचाने के लिए मॉड्यूल का उपयोग कर सकते हैं? क्या मुझे यह मान लेना गलत है कि किस मॉड्यूल के लिए डिज़ाइन किया गया था?

व्यक्तिगत रूप से, मेरे लिए निर्णय स्पष्ट प्रतीत होता है: यह देखते हुए कि इस धागे पर माइक्रोसॉफ्ट के लोग FILE_SHARE_DELETE का उपयोग करने के लिए डिफ़ॉल्ट व्यवहार को बदलने के समर्थन में हैं ...

यदि आपके लिए Microsoft इस विषय में प्राधिकरण है, तो आपको यह देखना चाहिए कि Microsoft विकास उपकरण क्या करते हैं।

मैंने इस प्रोग्राम का उपयोग किया है https://play.golang.org/p/4ZPmV6Df3SD जैसा कि @mattn ने https://github.com/golang/go/issues/32088#issuecomment -493753714 पर पोस्ट किया है मैंने इसे हाल ही में C कंपाइलर के साथ बनाया है।

Microsoft (R) C/C++ ऑप्टिमाइज़िंग कंपाइलर संस्करण 19.16.27030.1 x64 के लिए
कॉपीराइट (सी) माइक्रोसॉफ्ट कॉर्पोरेशन। सर्वाधिकार सुरक्षित।

और, जब मैं प्रोग्राम चलाता हूं, तो प्रोग्राम के अस्तित्व में आने तक मैं C:\Users\Alex\AppData\Local\Temp\a.txt फ़ाइल को हटा नहीं सकता था।

इसी तरह के सी # प्रोग्राम के साथ https://play.golang.org/p/SuM2iWYpZir मैंने हाल ही में इस्तेमाल किया

माइक्रोसॉफ्ट (आर) विजुअल सी# कंपाइलर संस्करण 2.10.0.0 (बी9एफबी1610)
कॉपीराइट (सी) माइक्रोसॉफ्ट कॉर्पोरेशन। सर्वाधिकार सुरक्षित।

इसी तरह यह सी प्रोग्राम https://play.golang.org/p/6HgxePzEW_W हाल ही में मिंगव के साथ बनाया गया है

जीसीसी (x86_64-win32-seh-rev0, MinGW-W64 प्रोजेक्ट द्वारा निर्मित) 7.3.0
कॉपीराइट (सी) 2017 फ्री सॉफ्टवेयर फाउंडेशन, इंक।

समान प्रभाव रखते हैं। तो उन उपकरणों में से किसी में भी डिफ़ॉल्ट रूप से FILE_SHARE_DELETE ध्वज सेट नहीं है।

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

एलेक्स

क्या आप Open() के लिए डिफ़ॉल्ट रूप से FILE_SHARE_DELETE बनाना चाहते हैं?

इरादा os.Open को डिफ़ॉल्ट रूप से FILE_SHARE_DELETE का उपयोग करना है। यह https://golang.org/cl/194957 योजना है।

एलेक्स

मेरी मुख्य चिंता लोगों के कार्यक्रम तोड़ने को लेकर है

अब तक, कोई भी प्रोग्राम के एक भी उदाहरण को इंगित नहीं कर सकता है जो टूट जाएगा क्योंकि यह गो के साथ खोली गई फ़ाइल का नाम बदलने/निकालने का प्रयास करते समय त्रुटि प्राप्त करने पर निर्भर करता है। लेकिन ऐसे दस्तावेज मामले हैं जहां वर्तमान व्यवहार विंडोज़ पर गो ऐप्स को तोड़ देता है।

यहां गो 1.0 संगतता वादे का क्या हुआ?

os.Rename() और .Remove() के लिए गो डॉक्स इस विंडोज फीचर के बारे में चुप हैं, लेकिन अन्य विंडोज-विशिष्ट व्यवहार के 15 उल्लेख हैं। BTW, Go 2 ने भेज दिया है: https://blog.golang.org/go2-here-we-come

जीसीसी (x86_64-win32-seh-rev0, MinGW-W64 प्रोजेक्ट द्वारा निर्मित) 7.3.0

आप जीसीसी के साथ किसके सी-लिब का उपयोग कर रहे हैं - शायद माइक्रोसॉफ्ट का? Mingw-w64 v6.0 पर है और इसमें FILE_SHARE_VALID_FLAGS में FILE_SHARE_DELETE शामिल है।

जैसा कि पुन: पायथन के ऊपर दस्तावेज किया गया है, अतीत में एमएसवीसी रनटाइम ने अज्ञात कारणों से कुछ CreateFile() ध्वज संयोजनों को अस्वीकार कर दिया था। मुझे नहीं पता कि यह अभी भी मामला है, लेकिन यही कारण है कि एमएस ने अपना सी-लिब फॉपेन() नहीं बदला है।

मुझे उस बदलाव का कोई लाभ नहीं दिख रहा है।

ऊपर कई लोगों द्वारा लाभों को बार-बार समझाया गया है; विशेष रूप से खुली फ़ाइल पर os.Rename() को अनुमति देना।

एक प्रस्ताव के रूप में चिह्नित करना क्योंकि चर्चा आसानी से परिवर्तित नहीं हो रही है।

इस मुद्दे और अब तक की चर्चा को संक्षेप में प्रस्तुत करने का प्रयास करने के लिए:

• यूनिक्स सिस्टम पर, यदि एक प्रक्रिया किसी फ़ाइल को खोलती है, तो दूसरी प्रक्रिया उस फ़ाइल को हटा सकती है। मूल प्रक्रिया फ़ाइल का उपयोग करना जारी रख सकती है (इसका अब कोई नाम नहीं है), जिसमें पढ़ना और लिखना शामिल है, जो सफल होता है। फ़ाइल सामग्री को डिस्क से तब तक नहीं हटाया जाता जब तक कि अंतिम खुला संदर्भ समाप्त नहीं हो जाता।

• विंडोज़ सिस्टम पर, डिफ़ॉल्ट रूप से, यदि एक प्रक्रिया फ़ाइल खोलती है, तो दूसरी प्रक्रिया _cannot_ उस फ़ाइल को हटा देती है। एक फ़ाइल को केवल तभी हटाया जा सकता है जब कोई अन्य प्रक्रिया खुली न हो। FILE_SHARE_DELETE ध्वज इस व्यवहार को बदलता है: यदि फ़ाइल के सभी खुले संदर्भ FILE_SHARE_DELETE के साथ खोले गए थे, तो दूसरी प्रक्रिया DeleteFile को कॉल कर सकती है, और यह विफल होने के बजाय सफल होगी।

FILE_SHARE_DELETE के साथ विंडोज़ व्यवहार अभी भी यूनिक्स से काफी अलग है। एमएसडीएन पेज कहता है:

DeleteFile फ़ंक्शन विफल हो जाता है यदि कोई एप्लिकेशन ऐसी फ़ाइल को हटाने का प्रयास करता है जिसमें सामान्य I/O के लिए अन्य हैंडल खुले हैं या स्मृति-मैप की गई फ़ाइल के रूप में (FILE_SHARE_DELETE को अन्य हैंडल खोले जाने पर निर्दिष्ट किया जाना चाहिए)।

DeleteFile फ़ंक्शन किसी फ़ाइल को बंद होने पर हटाने के लिए चिह्नित करता है। इसलिए, फ़ाइल हटाना तब तक नहीं होता है जब तक कि फ़ाइल का अंतिम हैंडल बंद न हो जाए। फ़ाइल को खोलने के लिए CreateFile के बाद के कॉल ERROR_ACCESS_DENIED के साथ विफल हो जाते हैं।

अर्थात्, फ़ाइल _name_ को फ़ाइल सिस्टम से तब तक नहीं हटाया जाता जब तक कि खुले संदर्भ समाप्त नहीं हो जाते। यह यूनिक्स से अलग है, जहां खुले संदर्भ बंद होने से पहले नाम गायब हो जाता है। इसलिए यदि आप उसी नाम की फ़ाइल को फिर से बनाने की तैयारी में फ़ाइल को हटा रहे थे, जो यूनिक्स में काम करती है लेकिन विंडोज़ में नहीं, FILE_SHARE_DELETE के साथ भी नहीं।

मूल सुझाव syscall को बदलना था। इस ध्वज को हमेशा सेट करने के लिए खोलें। यह देखते हुए कि syscall को कर्नेल इंटरफ़ेस के करीब माना जाता है, उस ध्वज को जोड़ने से ऐसा लगता है कि यह जगह से बाहर है। लेकिन हम इसके बजाय विचार कर सकते हैं कि क्या इसे os.Open / os.OpenFile के दौरान सेट किया जाना चाहिए।

@alexbrainman ने तर्क दिया है कि यूनिक्स और विंडोज अलग हैं, अगर हम इस ध्वज को सेट करते हैं तो भी वे अलग रहेंगे, और इसलिए हमें उपयोगकर्ताओं की पीठ के पीछे यह बदलाव करके मामले को भ्रमित नहीं करना चाहिए।

माइक्रोसॉफ्ट के @jstarks का कहना है कि माइक्रोसॉफ्ट हमें FILE_SHARE_DELETE को स्वचालित रूप से सेट करना पसंद करेगा और विंडोज़ का "सबसे हालिया संस्करण" (अस्पष्ट जो, या यदि इसे जारी किया गया है) DeleteFile से वापसी पर गायब होने वाले नाम के यूनिक्स अर्थशास्त्र को गायब करने के लिए DeleteFile को बदल देता है। तो अगर हमने ऐसा किया, तो उस नवीनतम विंडोज़ पर, हमें वास्तव में यूनिक्स और विंडोज़ में वही व्यवहार मिलेगा।

@networkimprov का तर्क है कि हमें बदलाव करना चाहिए और प्रोग्राम के कोई वास्तविक उदाहरण नहीं हैं जो टूट जाएंगे।

@alexbrainman अभी भी असंबद्ध लगता है।

@mattn ने यह भी सुझाव दिया है कि हमें ध्वज को स्वचालित रूप से सेट नहीं करना चाहिए, क्योंकि (कम से कम जब तक हर कोई नवीनतम विंडोज का उपयोग नहीं करता) यह अभी भी यूनिक्स से अलग होगा।

कुल मिलाकर, पैकेज ओएस एक पोर्टेबल एपीआई देने की कोशिश कर रहा है, और ऐसा लगता है - विशेष रूप से विंडोज़ परिवर्तन के साथ - ध्वज को स्वचालित रूप से सेट करने से उसमें मदद मिलेगी। उपयोगकर्ताओं के लिए व्यवहार को कम आश्चर्यजनक बनाने में मदद करने के लिए, विशेष रूप से O_CLOEXEC (क्लोज़-ऑन-एक्सेक) में अन्य फ़्लैग्स भी हैं जिन्हें हम स्वचालित रूप से os.Open में सेट करते हैं। इस ध्वज को os.Open में सेट करने के कारण विंडोज़ पर टूटने वाला कोई भी प्रोग्राम यूनिक्स पर भी टूट जाएगा, है ना?

खासकर जब से माइक्रोसॉफ्ट में कम से कम एक इंजीनियर का कहना है कि हमें इसे सेट करना चाहिए, ऐसा लगता है कि पैकेज ओएस में सेट करना ठीक रहेगा। जो लोग ध्वज सेट नहीं चाहते हैं वे अभी भी पैकेज syscall पर वापस आ सकते हैं।

@alexbrainman और @mattn , मान लीजिए कि हमने ध्वज को os.Open में सेट किया है। हम जानते हैं कि कुछ कार्यक्रम बेहतर काम करेंगे। क्या आपके पास वास्तविक (या संभावित) कार्यक्रमों के विशिष्ट उदाहरण हैं जो टूट जाएंगे? क्या यूनिक्स पर पहले से ही उन कार्यक्रमों को तोड़ा नहीं जाएगा? धन्यवाद।

@rsc , आपके इनपुट के लिए धन्यवाद। पैकेज "ओएस" में इसे सक्षम करना मेरे लिए काम करता है। यदि इसे अपनाया जाता है, तो FILE_SHARE_DELETE को सक्षम करने के लिए एक syscall.Open() ध्वज पूर्णता के लिए प्रदान किया जाना चाहिए।

अपने सारांश को स्पष्ट करने के लिए, प्रक्रिया की सीमाएँ कोई कारक नहीं हैं; प्रभाव एक ही प्रक्रिया के भीतर समान हैं। और ध्वज फ़ाइल का नाम बदलने को भी प्रभावित करता है; ध्वज के साथ यह फ़ाइल हटाने के विपरीत तुरंत पूरा हो जाता है। (और यह हटाने के तुरंत बाद फ़ाइल नाम उपलब्धता के लिए एक वैकल्पिक हल की अनुमति देता है।)

धन्यवाद @networkimprov। हां, मैं समझता हूं कि प्रक्रिया सीमाएं पूरी तरह से प्रासंगिक नहीं हैं; यह सिर्फ स्थितियों का वर्णन करना आसान बनाता है।

मैंने शीर्षक बदल दिया है और अंक पाठ में कार्य योजना को संशोधित किया है:

a) os.Create/Open/OpenFile() को विंडोज़ पर हमेशा file_share_delete को सक्षम करना चाहिए,
बी) विंडोज़ पर syscall.Open() को एक ध्वज स्वीकार करना चाहिए जो file_share_delete को सक्षम बनाता है, और
सी) विंडोज़ पर सिस्कल को नए ध्वज के लिए निरंतर निर्यात करना चाहिए।

os.Remove() के लिए दस्तावेज़ यह भी ध्यान दें कि विंडोज़ पर एक खुली फ़ाइल को हटाने के बाद फ़ाइल नाम का पुन: उपयोग करने के लिए, किसी को यह करना होगा: os.Rename(path, unique_path); os.Remove(unique_path) ।

संभावना है कि एक उपयोगकर्ता है जो वर्तमान गो के os.Open व्यवहार का उपयोग करके विशेष प्रसंस्करण को लागू करता है, इनकार नहीं किया जा सकता है।

लेकिन ऐसे दस्तावेज मामले हैं जहां वर्तमान व्यवहार विंडोज़ पर गो ऐप्स को तोड़ देता है।

यह क्या हैं? इश्यू नंबर क्या हैं? और break शब्द से आपका क्या मतलब है? वे कब टूट गए?

आप जीसीसी के साथ किसके सी-लिब का उपयोग कर रहे हैं - शायद माइक्रोसॉफ्ट का? Mingw-w64 v6.0 पर है और इसमें FILE_SHARE_VALID_FLAGS में FILE_SHARE_DELETE शामिल है।

मुझे नहीं पता। मैंने अभी-अभी इंटरनेट से x86_64-7.3.0-release-win32-seh-rt_v5-rev0.7z फ़ाइल डाउनलोड की है। आप इसके लिए गूगल कर सकते हैं। यह संस्करण 7.3 का है।

मुझे उस बदलाव का कोई लाभ नहीं दिख रहा है।

लाभों को ऊपर बार-बार समझाया गया है,...

आपने अपने उद्धरण में से personally शब्द छोड़ दिया है। मैं अपनी जरूरतों के बारे में बात करता हूं। और इसमें मेरा गो प्रोजेक्ट योगदान भी शामिल है।

इस मुद्दे और अब तक की चर्चा को संक्षेप में प्रस्तुत करने का प्रयास करने के लिए:

आपने यह नहीं कहा कि विंडोज़ पर Microsoft डेवलपर टूल डिफ़ॉल्ट रूप से यह फ़्लैग प्रदान नहीं करते हैं। मेरी टिप्पणी देखें https://github.com/golang/go/issues/32088#issuecomment -531713562

आपने गो 1 संगतता के बारे में मेरी टिप्पणी को भी अनदेखा कर दिया

यहां गो 1.0 संगतता वादे का क्या हुआ? जहां https://golang.org/doc/go1compat में यह कहा गया है, कि यदि आप go-nuts पर अपने इरादे की घोषणा करते हैं, तो खुले फ़ाइल व्यवहार को बदलना ठीक है?

यह परिवर्तन गो 1.0 संगतता वादे में कैसे फिट बैठता है?

कुल मिलाकर, पैकेज ओएस एक पोर्टेबल एपीआई देने की कोशिश कर रहा है, और ऐसा लगता है - विशेष रूप से विंडोज़ परिवर्तन के साथ - ध्वज को स्वचालित रूप से सेट करने से उसमें मदद मिलेगी।

मैं सहमत हूं कि इस बदलाव का उद्देश्य लोगों को यूनिक्स सॉफ्टवेयर को विंडोज़ में पोर्ट करना है।

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

और यहां तक ​​​​कि यूनिक्स सॉफ़्टवेयर को विंडोज़ में पोर्ट करने वाले लोगों के लिए, यह परिवर्तन आईएमएचओ बहुत खराब काम कर रहा है। मेरी टिप्पणी से We still won't be able to delete executable files while process is running. We will still have problems deleting directories if any process have their current directories set there. भाग देखें https://github.com/golang/go/issues/32088#issuecomment -531713562

उपयोगकर्ताओं के लिए व्यवहार को कम आश्चर्यजनक बनाने में मदद करने के लिए, विशेष रूप से O_CLOEXEC (क्लोज़-ऑन-एक्सेक) में अन्य फ़्लैग्स भी हैं जिन्हें हम स्वचालित रूप से os.Open में सेट करते हैं। इस ध्वज को os.Open में सेट करने के कारण विंडोज़ पर टूटने वाला कोई भी प्रोग्राम यूनिक्स पर भी टूट जाएगा, है ना?

मुझे नहीं पता कि आपका यहाँ क्या मतलब है। विंडोज़ पर O_CLOEXEC का अर्थ फ़ाइल हैंडल को बाल प्रक्रिया में भागने से रोकना है। और O_CLOEXEC हमेशा विंडोज़ पर os.Open में सेट होता है। तो विंडोज़ पर चाइल्ड प्रोसेस द्वारा os.Open के साथ कोई फ़ाइल नहीं खोली जा सकती है। तो क्या? यह वाजिब लगता है।

क्या यूनिक्स पर पहले से ही उन कार्यक्रमों को तोड़ा नहीं जाएगा?

मैं आपका प्रश्न नहीं समझता।

क्या आपके पास वास्तविक (या संभावित) कार्यक्रमों के विशिष्ट उदाहरण हैं जो टूट जाएंगे?

मुझे नहीं पता, अगर मेरे पास ऐसे कार्यक्रम हैं। कहना असंभव है। मेरे द्वारा लिखे गए सभी कार्यक्रम मुझे याद नहीं हैं। मुझे याद नहीं है कि वे क्या करते हैं।

लेकिन मैं कल्पना कर सकता हूं कि एक विंडोज़ सेवा पूर्वनिर्धारित फ़ाइल खोलती है, मान लें कि c:\mysvc.txt , और इसे खुला रखता है। एक अन्य प्रोग्राम की कल्पना करें जो जांचता है कि सेवा जीवित है, और यदि आवश्यक हो तो सेवा को पुनरारंभ करें। यह एक अन्य प्रोग्राम केवल कोशिश कर सकता है और c:\mysvc.txt हटा सकता है, और, यदि फ़ाइल चली गई है, तो यह सुरक्षित रूप से मान सकता है कि सेवा प्रक्रिया समाप्त हो गई है।

इसके अलावा, मैं कल्पना कर सकता हूं, कुछ प्रोग्राम उपयोगकर्ताओं को उनकी फ़ाइलों को हटाने या स्थानांतरित करने से रोकना चाहते हैं - https://stackoverflow.com/questions/11318663/prevent-a-user-from-deleting-moving-or-renameing-a-file

एलेक्स

विंडोज़ पर गो का डेटा बिंदु पुन: परिनियोजन यहां दिया गया है:
Win8 7 साल पहले शिप किया गया था।
Win8+ को प्रभावित करने वाले इस गो बग की रिपोर्ट सिर्फ 5 महीने पहले की गई थी: #31528

@rsc कोई भी प्रोग्राम जो गो के साथ खोली गई फ़ाइल का नाम बदलने/निकालने का प्रयास करते समय त्रुटि प्राप्त करने की अपेक्षा करता है, यूनिक्स पर टूटा हुआ है। उदाहरण के लिए, एलेक्स का c:\mysvc.txt परिदृश्य।

यदि कोई विंडोज़ पर विकसित होता है और लिनक्स/आदि (या इसके विपरीत) पर तैनात होता है, तो यह बग का स्रोत हो सकता है।

हमारा उपयोग मामला यह है कि हमारे पास एक लॉगर है जो फ़ाइल में लॉग करता है।
लॉग फ़ाइल रोटेशन का समर्थन करती है (उदाहरण के लिए अगला लिखें यदि लॉग फ़ाइल> अधिकतम आकार है तो घुमाएं)।
हमारे पास पाठक भी हैं जो इन फाइलों को खोलेंगे और पढ़ते समय उन्हें खुला रखेंगे।

FILE_SHARE_DELETE सेट करने की क्षमता के बिना हम सक्रिय पाठक होने पर रोटेशन (नाम बदलें और/या हटाएं) नहीं कर सकते हैं।

@mattn :

संभावना है कि एक उपयोगकर्ता है जो वर्तमान गो के os.Open व्यवहार का उपयोग करके विशेष प्रसंस्करण को लागू करता है, इनकार नहीं किया जा सकता है।

ऐसा हो सकता है, लेकिन यूनिक्स पर वैसे भी ऐसा कोड गलत है। पैकेज ओएस एक पोर्टेबल इंटरफेस होने के लिए है। साथ ही हम संभावनाओं की तुलना में _actual_ कार्यक्रमों में अधिक रुचि रखते हैं।

@alexbrainman :

आपने यह नहीं कहा कि विंडोज़ पर Microsoft डेवलपर टूल डिफ़ॉल्ट रूप से यह फ़्लैग प्रदान नहीं करते हैं। मेरी टिप्पणी देखें #32088 (टिप्पणी)

हाँ लेकिन वह सी है; हम बात कर रहे हैं गो की। हम सामान्य रूप से सी एपीआई की नकल नहीं कर रहे हैं। हम पैकेज ओएस में अधिकतर पोर्टेबल एब्स्ट्रैक्शन प्रदान करने का प्रयास कर रहे हैं। O_CLOEXEC के बारे में बात यह थी कि यूनिक्स सिस्टम पर os.Open O_CLOEXEC सेट करता है, भले ही यह संबंधित C कॉल में डिफ़ॉल्ट रूप से सेट न हो। हम _do_ उपयोगी डिफ़ॉल्ट प्रदान करने का प्रयास करते हैं जो सभी प्रणालियों में लगभग समान व्यवहार करते हैं।

जहां तक ​​​​गो 1 संगतता है, अन्य ओएस के साथ बेहतर संरेखित करने के लिए एक ओएस पर एक कोने-केस व्यवहार को बदलना ठीक लगता है। हम सभी समय के लिए सभी क्रॉस-सिस्टम असंगतियों को संरक्षित करने का वादा नहीं कर रहे हैं।

विंडोज़ उपयोगकर्ता जो विंडो-विशिष्ट व्यवहार पर जोर देते हैं, उनके पास हमेशा पैकेज सिस्कल का उपयोग करने का विकल्प होता है, जो स्पष्ट करेगा कि जिस व्यवहार तक पहुंचा जा रहा है वह वास्तव में केवल विंडोज़ पर लागू होता है।

दोबारा, क्या आपके पास वास्तविक कार्यक्रमों के ठोस उदाहरण हैं जो टूट जाएंगे?

@ cpuguy83 , एक प्रोग्राम के वास्तविक दुनिया के उपयोग के मामले के लिए धन्यवाद जिससे मदद मिलेगी।

@rsc जैसा कि आप कहते हैं, मैंने अभी तक FILE_SHARE_DELETE के ब्रेकिंग प्रभावों का पता नहीं लगाया है। इसी तरह, कोई पुष्टि नहीं मिली है कि इस परिवर्तन से लॉगरोटेट को लागू किया जा सकता है।

हालाँकि, एक बार जब गो में यह परिवर्तन शामिल हो जाता है जो फ़ाइल को हटा सकता है, तो उपयोगकर्ता इस व्यवहार की अपेक्षा करेगा, भले ही गो इस परिवर्तन से विंडोज पर लॉगरोटेट को लागू नहीं कर सकता है। इसलिए हमें इस बदलाव के बारे में ध्यान से सोचना होगा। मूल रूप से, Windows उन फ़ाइलों को नहीं हटा सकता जिन्हें FILE_SHARE_DELETE के साथ फ़्लैग नहीं किया गया है। उपयोगकर्ता सोच सकते हैं कि यह परिवर्तन गो को किसी भी फाइल को हटाने की अनुमति देगा। विशेष रूप से, हैंडल के साथ os.NewFile द्वारा बनाई गई फ़ाइलें os.File संरचना के तरीकों में हेरफेर कर सकती हैं, भले ही यह फ़्लैग सेट न हो। मुझे लगता है कि प्रोग्रामर को पता होना चाहिए कि विंडोज़ पर फ़ाइल को हटाया जा सकता है या नहीं, मुझे लगता है। मैं एक तंत्र पसंद करता हूं जो FILE_SHARE_DELETE को डिफ़ॉल्ट के बजाय os.OpenFile के लिए ध्वज द्वारा पारित करने की अनुमति देता है। मुझे लगता है कि ओएस के डिफ़ॉल्ट व्यवहार का पालन किया जाना चाहिए।

हाँ लेकिन वह सी है; हम बात कर रहे हैं गो की।

और सी # भी। मैंने जांच नहीं की, लेकिन मुझे पूरा यकीन है कि विंडोज़ पर कोई अन्य विकास उपकरण इस तरह से व्यवहार करता है।

जहां तक ​​​​गो 1 संगतता है, अन्य ओएस के साथ बेहतर संरेखित करने के लिए एक ओएस पर एक कोने-केस व्यवहार को बदलना ठीक लगता है।

यह गैर विंडोज उपयोगकर्ताओं के लिए कॉर्नर-केस है। विंडोज उपयोगकर्ताओं के लिए यह व्यवहार मानक है।

दोबारा, क्या आपके पास वास्तविक कार्यक्रमों के ठोस उदाहरण हैं जो टूट जाएंगे?

कंक्रीट के ऊपर मेरे सेवा उदाहरण पर विचार करें।

@ cpuguy83 , एक प्रोग्राम के वास्तविक दुनिया के उपयोग के मामले के लिए धन्यवाद जिससे मदद मिलेगी।

@ cpuguy83 क्या आप अपनी समस्या के बारे में और

मूल रूप से, Windows उन फ़ाइलों को नहीं हटा सकता जिन्हें FILE_SHARE_DELETE के साथ फ़्लैग नहीं किया गया है। उपयोगकर्ता सोच सकते हैं कि यह परिवर्तन गो को किसी भी फाइल को हटाने की अनुमति देगा।

मैं सहमत हूं कि यह एक अच्छी बात है। केवल गो प्रोग्राम द्वारा खोली गई फाइलों को ही हटाया जा सकता है। लेकिन नॉन गो प्रोग्राम द्वारा खोली गई अन्य सभी फाइलें अभी भी हटाने योग्य नहीं रहेंगी। वह ओएस बना देगा। अप्रत्याशित हटा दें - कभी-कभी यह काम करेगा, और कभी-कभी यह नहीं होगा।

एलेक्स

मेरे पास एक पैच किए गए syscall.Open() को कॉल करने वाला कोड है जो खुली फाइलों का नाम बदलता है। इस तरह आप लॉग रोटेशन को लागू करते हैं; यह काम करता हैं।

// several processes or goroutines do this
   fd, err := os.OpenFile("log", os.O_CREATE|os.O_APPEND|os.O_WRONLY, ...)
   _, err = fd.Write(log_entry) // one or more times
   err = fd.Close()

// log rotator process does this
   err := os.Rename("log", "log_old") // active writers not disturbed
   fmt.Println(err) // "sharing violation" without FILE_SHARE_DELETE

लेकिन आपको यह बताने के लिए किसी की जरूरत नहीं थी :-/

स्वाभाविक रूप से os.NewFile() से os.File में os.Create/Open/OpenFile() की तुलना में कई अलग-अलग गुण हो सकते हैं, यह एक विशेषता है, आश्चर्य की बात नहीं है।

आप दावा करते हैं कि Microsoft C fopen() व्यवहार Windows डिफ़ॉल्ट व्यवहार है; यह सच नहीं है। कोई CreateFile() डिफ़ॉल्ट साझाकरण मोड नहीं है; यह FILE_SHARE_READ | FILE_SHARE_WRITE ।

आप दावा करते हैं कि परिनियोजित विंडोज प्रोग्राम आमतौर पर यह मानते हैं कि __प्रोग्राम अन्य विक्रेताओं द्वारा__ हमेशा एक विशिष्ट तरीके से फाइलें खोलते हैं। अगर ऐसा होता, तो Microsoft हमें डिफ़ॉल्ट रूप से file_share_delete को सक्षम करने के लिए नहीं कहता।

@networkimprov

लेकिन आपको यह बताने के लिए किसी की जरूरत नहीं थी :-/

मैं जानना चाहता हूं कि बाहरी प्रक्रिया किसी भी मामले में फ़ाइल को सही ढंग से हटा सकती है और उसका नाम बदल सकती है।

मैं जो जानना चाहता हूं वह है: उस परिवर्तन को शामिल करने के बाद, लॉग फ़ाइल गो से आउटपुट होती है, बाहरी प्रक्रिया द्वारा निष्पादित लॉगरोटेट ठीक काम करता है, और यह बिना किसी त्रुटि के उत्पादन के रूप में काम करता है।

@alexbrainman

दुर्भाग्य से कोड जटिल है, लेकिन यह वास्तविक वास्तविक दुनिया कोड है: https://github.com/moby/moby/blob/master/daemon/logger/loggerutils/logfile.go

प्रस्तावित शमन वर्तमान में केवल फोर्क os.OpenFile और syscall.Open: https://github.com/moby/moby/pull/39974/files के लिए है

स्पष्ट होने के लिए, OpenFile से FILE_SHARE_DELETE या यहां तक ​​कि syscall.Open से गुजरने का विकल्प हमारे मामले को संभालने के लिए पर्याप्त होगा।

दुर्भाग्य से कोड जटिल है, लेकिन यह वास्तविक वास्तविक दुनिया कोड है: https://github.com/moby/moby/blob/master/daemon/logger/loggerutils/logfile.go

प्रस्तावित शमन वर्तमान में केवल फोर्क os.OpenFile और syscall.Open: https://github.com/moby/moby/pull/39974/files के लिए है

@ cpuguy83 सूचक के लिए धन्यवाद।

दुर्भाग्य से इस पर मेरी संक्षिप्त नज़र यह तय करने के लिए पर्याप्त जानकारी प्रदान नहीं करती है कि क्या यह वर्तमान मुद्दा समाधान है। मुझे रेप्रो (शायद यह https://github.com/moby/moby/issues/39274#issuecomment-497966709 ) से शुरू करना होगा और इसे वहां से लेना होगा। मुझे यकीन नहीं है कि मेरे पास इस पर खर्च करने का समय कब होगा। अगर आपके पास बेहतर सुझाव है तो मेरी योजना, मुझे बताएं।

एलेक्स

नीचे मानक-अभ्यास लॉग रोटेशन का एक कार्यशील डेमो है, जिसमें हर बार लॉग फ़ाइल खोलने पर 100 गोरआउट प्रत्येक लॉगिंग 50 लाइनें 0.1-2सेकंड के अंतराल पर होती है, और दूसरा गोरौटाइन लॉग को 1 मिनट के अंतराल पर घुमाता है। मैंने कल इसे कई घंटों तक Win7 लैपटॉप पर शून्य त्रुटियों के साथ चलाया।

इसे syscall.Open() के पैच के साथ बनाया गया है जो FILE_SHARE_DELETE को सक्षम बनाता है; यह अन्यथा विफल रहता है। इस ध्वज के बिना कोई अधिक जटिल लॉगिंग योजना बना सकता है, लेकिन इसके कई अन्य उपयोग भी हैं; मेरा अपना कोड विभिन्न कारणों से खुली फाइलों का नाम बदलता है।

@rsc , मेरा मानना ​​​​है कि यह आपके सुझाव के मामले को पूरा करता है, अगर अभी भी कोई संदेह था। (और जैसा कि ऊपर उल्लेख किया गया है, मैंने गोलंग-देव और गोलंग-नट्स में बार-बार पोस्ट किया है जो उन परियोजनाओं के लिए पूछ रहा है जो वर्तमान व्यवहार पर निर्भर हैं, शून्य परिणामों के साथ।)

package main

import (
   "fmt"
   "os"
   "math/rand"
   "syscall"
   "time"
)

const kLogFile = "winrotate"

func main() {
   syscall.Open_FileShareDelete = true
   rand.Seed(time.Now().UnixNano())

   for a := 0; a < 100; a++ {
      go runLog()
   }

   fmt.Println("rotating to "+ kLogFile +"N.txt")
   for a := 0; true; a++ {
      if a >= 5 {
         a = 0
      }
      time.Sleep(60 * time.Second)
      err := os.Rename(kLogFile +".txt", kLogFile + string('0'+a) +".txt")
      if err != nil {
         fmt.Println(err)
         os.Exit(1)
      }
   }
}

const kLineVal = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"

func runLog() {
   aLine := make([]byte, 102)
   for {
      aFd, err := os.OpenFile(kLogFile +".txt", os.O_CREATE|os.O_APPEND|os.O_WRONLY, 0600)
      if err != nil {
         fmt.Println(err)
         return
      }
      for _, aV := range kLineVal {
         for a := range aLine {
            aLine[a] = byte(aV)
         }
         aEnd := aV - ('z' - 100) // limit line len to 100
         copy(aLine[aEnd:], []byte{'\r','\n'})
         _, err = aFd.Write(aLine[:aEnd + 2])
         if err != nil {
            fmt.Println(err)
            return
         }
         time.Sleep(time.Duration(100 + rand.Intn(1900)) * time.Millisecond)
      }
      err = aFd.Close()
      if err != nil {
         fmt.Println(err)
         return
      }
   }
}

syscall_windows.go पर पैच करें:

diff --git a/src/syscall/syscall_windows.go b/src/syscall/syscall_windows.go
index de05840..e1455d5 100644
--- a/src/syscall/syscall_windows.go
+++ b/src/syscall/syscall_windows.go
@@ -245,6 +245,8 @@ func makeInheritSa() *SecurityAttributes {
    return &sa
 }

+var Open_FileShareDelete = false
+
 func Open(path string, mode int, perm uint32) (fd Handle, err error) {
    if len(path) == 0 {
        return InvalidHandle, ERROR_FILE_NOT_FOUND
@@ -270,6 +272,9 @@ func Open(path string, mode int, perm uint32) (fd Handle, err error) {
        access |= FILE_APPEND_DATA
    }
    sharemode := uint32(FILE_SHARE_READ | FILE_SHARE_WRITE)
+   if Open_FileShareDelete {
+       sharemode |= FILE_SHARE_DELETE
+   }
    var sa *SecurityAttributes
    if mode&O_CLOEXEC == 0 {
        sa = makeInheritSa()

@networkimprov फ़ाइल का नाम बाहरी प्रक्रिया द्वारा नहीं बदला गया है। यदि फ़ाइल का नाम बदलना उसी प्रक्रिया में हो रहा है, तो इसे लागू करने के कुछ अन्य तरीके भी हैं।

https://github.com/mattn/go-sizewriter/blob/master/_example/example.go#L14

नीचे मानक-अभ्यास लॉग रोटेशन का एक कार्यशील डेमो है

आपके उदाहरण के लिए धन्यवाद, @networkimprov । मैं अब देख सकता हूं कि आप क्या करने की कोशिश कर रहे हैं।

आपके कोड के साथ एकमात्र समस्या यह है कि, यदि कोई बाहरी प्रक्रिया FILE_SHARE_DELETE के बिना आपके द्वारा लिखी जा रही फ़ाइलों को खोल देगी, तो आपको वही समस्या होगी जो अब आपके पास है, भले ही हम गो में बदलाव करें।

@ cpuguy83 मैं आपके मुद्दे को नहीं देख रहा हूँ (जैसा कि मैंने यहाँ वादा किया था https://github.com/golang/go/issues/32088#issuecomment-536233195), क्योंकि @networkimprov उदाहरण मुझे एक तस्वीर देता है कि वह क्या कोशिश कर रहा है करने के लिए।

एलेक्स

एलेक्स, यदि बाहरी पहुंच की अनुमति है तो कोई नाम बदलने का प्रयास लूप कर सकता है, या सक्रिय लॉग फ़ाइल को प्रतिबंधित कर सकता है यदि नहीं।

मैटन, रोटेट का नाम आमतौर पर एक अलग प्रक्रिया द्वारा किया जाता है।

ऐसा लगता है कि यहां कोई स्पष्ट सहमति नहीं है। यूनिक्स पृष्ठभूमि वाले डेवलपर्स इसके पक्ष में प्रतीत होते हैं, लेकिन हमारे दो सबसे सक्रिय विंडोज डेवलपर्स ( @alexbranman और @mattn ) नहीं हैं। यह परिवर्तन वास्तव में केवल विंडोज़ के नवीनतम संस्करण को एकीकृत करेगा जिसमें FILE_SHARE_DELETE के लिए नया यूनिक्स जैसा व्यवहार है।

यह कुछ वर्षों में इस विषय पर फिर से विचार करने लायक हो सकता है, यह देखने के लिए कि नया ध्वज व्यवहार कितना व्यापक रूप से उपलब्ध है और क्या अन्य भाषाएं एक सामान्य व्यवहार में परिवर्तित हो गई हैं। अगर कोई इस पर पुनर्विचार करने के लिए दो साल या उससे अधिक समय में एक नया मुद्दा दर्ज करना चाहता है, तो यह ठीक होगा।

लेकिन अभी के लिए, आम सहमति की कमी को देखते हुए, यह संभावित गिरावट की तरह लगता है।

अंतिम टिप्पणियों के लिए एक सप्ताह के लिए खुला है।

क्या केवल विकल्प उपलब्ध कराने पर विवाद है?

अगर हम आवाज़ उठाने के लिए और आवाज़ें ढूंढ रहे हैं, तो मैं निश्चित रूप से _something_ करने के पक्ष में हूँ। अभी, एकमात्र समाधान गो की मानक लाइब्रेरी से कोड का एक गुच्छा कॉपी करना है, एक पंक्ति बदलना है, और फिर उस कांटे को हमेशा के लिए बनाए रखना है। लॉग मॉनिटर या लाइव "टेल" का हर कार्यान्वयन अंततः ऐसा करने लगता है।

उदाहरण के लिए, देखें https://github.com/elastic/beats/blob/master/libbeat/common/file/file_windows.go#L85 -L103

अगर मैंने सही ढंग से पालन किया, तो इस प्रस्ताव के वास्तव में दो भाग हैं:

1. फ़ाइल खोलते समय फ़्लैग FILE_SHARE_DELETE के उपयोग की अनुमति दें -
   कार्यान्वयन आसान और सुरक्षित होना चाहिए, डेवलपर को स्पष्ट रूप से करना होगा
   नई फ़ाइल खोलते समय इस मोड का अनुरोध करें
2. इस फ़्लैग को डिफ़ॉल्ट रूप से चालू करें - जोखिम भरा हो सकता है, और केवल अच्छी तरह से समर्थित हो सकता है
   अंतिम विंडोज़ 10 बिल्ड का उपयोग करते समय।

यदि सभी 1 पर सहमत होते हैं, तो शायद हम डेवलपर के समय ध्वज को अनुमति दे सकते हैं
अभी के लिए स्पष्ट रूप से इसका अनुरोध करें, और कुछ वर्षों में 2 पर फिर से जाएं।

बुध पर, 2 अक्टूबर 2019, 19:32 मार्क दासचर, नोटिफिकेशन @github.com ने लिखा:

अगर हम आवाज उठाने के लिए और आवाजें ढूंढ रहे हैं, तो मैं निश्चित रूप से इसके पक्ष में हूं
कुछ करने का । अभी, केवल एक ही उपाय है कि शाब्दिक रूप से a . को कॉपी करें
गो के मानक पुस्तकालय से कोड का गुच्छा, एक पंक्ति बदलें, और फिर
उस कांटे को हमेशा के लिए बनाए रखना। लॉग मॉनिटर या लाइव का हर कार्यान्वयन
"पूंछ" अंततः ऐसा करने लगता है।

उदाहरण के लिए देखें
https://github.com/elastic/beats/blob/master/libbeat/common/file/file_windows.go#L85 -L103

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/32088?email_source=notifications&email_token=ABNEY4VFQLSYVI66ENT6G4LQMTLJ7A5CNFSM4HNPNYIKYY3PNVWWK3TUL52HS4DFVREXGEAVMVBW63 ,
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/ABNEY4U5L3WFZYNIUOSY2TQMTLJ7ANCNFSM4HNPNYIA
.

निश्चित रूप से _at कम से कम के पक्ष में 1. (फ़ाइल खोलते समय FILE_SHARE_DELETE ध्वज के उपयोग की अनुमति दें)

बस मेरे पिछले प्रस्ताव पर फिर से विचार करने के लिए और उदाहरण के कार्यान्वयन के साथ अनुवर्ती कार्रवाई करने के लिए :

syscall.FILE_SHARE_DELETE ध्वज os.OpenFile के flag पैरामीटर में अच्छी तरह फिट होगा और इस व्यवहार को ऑन-डिमांड सक्षम करने के लिए एक छोटा तंत्र प्रदान करेगा। यह विंडोज़ पर किसी अन्य os.O_* झंडे से टकराता नहीं है (और इसे लागू/इंजीनियर किया जा सकता है) और यह सिस्टम-विशिष्ट फ़ाइल खोलने के व्यवहार को निर्दिष्ट करने का एक बेवकूफ तरीका प्रदान करता है ( os ) पॉज़िक्स-ओरिएंटेड इंटरफ़ेस को विंडोज़ पर मुहावरेदार माना जा सकता है)। यह वही मार्ग है जो पहले से ही POSIX प्लेटफॉर्म पर सिस्टम-विशिष्ट फ़ाइल खोलने के व्यवहार में पास करने के लिए उपयोग किया जाता है (उदाहरण के लिए लिनक्स पर syscall.O_DIRECTORY )।

भले ही इसे डिफ़ॉल्ट रूप से चालू न करने का निर्णय लिया गया हो (जो मुझे लगता है कि सही कॉल है), मैं सहमत हूं कि ध्वज के उपयोग के मामले हैं (जिनमें @networkimprov द्वारा इंगित किए गए हैं) और यह उपयोगी होगा होना CreateFileW कॉल का सहारा लिए बिना और बॉयलरप्लेट कोड को कॉपी किए बिना इसे चालू करने में सक्षम।

कृपया ऊपर दिए गए विकल्प [1] पर विचार करें जो डेवलपर्स को आवश्यक होने पर FILE_SHARE_DELETE सेट करने का विकल्प देता है और गो मानक पुस्तकालय कोड के कांटेदार भाग को रोकता है।

__Rust__ भी डिफ़ॉल्ट रूप से इस ध्वज को सेट करता है, और आपको किसी भी FILE_SHARE_* विकल्पों में से _स्विच ऑफ_ करने की अनुमति देता है।
https://doc.rust-lang.org/std/os/windows/fs/trait.OpenOptionsExt.html

@rsc क्या मैं पूछ सकता हूं कि प्रस्ताव के खिलाफ दिए गए तकनीकी तर्कों में से कौन सा खंडन नहीं किया गया था?

@networkimprov पूरे प्रस्ताव और चर्चा को पढ़ने के बाद मुझे लगता है कि आपको इसे बंद करने और ossyscall पैकेज में नई विंडोज़ विशिष्ट ध्वज जोड़ने के बारे में स्पष्ट रूप से एक नया मुद्दा फिर से खोलने की आवश्यकता है। यह सुनिश्चित करेगा कि नया व्यवहार ऑप्ट-आउट के बजाय ऑप्ट-इन है। वर्तमान प्रस्ताव का तात्पर्य मौजूदा कोड को बदलना है, जो लोगों को चिंतित करता है।

@rsc क्या मैं पूछ सकता हूं कि प्रस्ताव के खिलाफ दिए गए तकनीकी तर्कों में से कौन सा खंडन नहीं किया गया था?

मुझे खेद है, लेकिन ऐसा नहीं है कि प्रस्ताव प्रक्रिया कैसे काम करती है। अन्य लोगों के तर्कों का "खंडन" करना पर्याप्त नहीं है। "प्रस्ताव प्रक्रिया का लक्ष्य समय पर परिणाम के बारे में आम सहमति तक पहुंचना है।" यहां आगे के रास्ते को लेकर कोई स्पष्ट सहमति नहीं है। तकनीकी तर्क दिए गए हैं, और उन्होंने प्रमुख गो डेवलपर्स को मना नहीं किया जिन्होंने विंडोज पोर्ट (अर्थात्, @alexbrainman और @mattn) में महत्वपूर्ण योगदान दिया है। स्पष्ट सहमति की कमी के अलावा, आज कुछ करने की तात्कालिकता का कोई स्पष्ट संकेत नहीं है: इस मुद्दे को दायर करने से पहले लगभग 10 वर्षों तक विंडोज़ पर गो ने ठीक काम किया। जैसा कि मैं इसे समझता हूं, सब कुछ अकेला छोड़ देने का मतलब है कि गो हमेशा की तरह काम करता रहेगा।

मैंने FILE_SHARE_DELETE के साथ फ़ाइलें खोलने का एक आसान तरीका प्रदान करने के लिए #34681 दायर किया था (अभी भी संभावित) घटना में कि यह अस्वीकार कर दिया गया है। इस विचार को जारी रखने की तुलना में उस विचार तक सीमित एक नया सूत्र शुरू करना अधिक उपयोगी लग रहा था, जो बहुत लंबा हो गया है।

@rsc , इससे पहले कि आप इसे अस्वीकार करें, आइए सुनें कि एलेक्स आपके O_ALLOW_DELETE प्रस्ताव के बारे में क्या सोचता है।

इस चर्चा की शुरुआत में, वह एक नए os.OpenFile() ध्वज के खिलाफ थे जो file_share_delete सेट करता है, उन्हीं कारणों से वह आपके os.Create/Open/OpenFile() सुझाव से असहमत था। वह चिंतित है कि अन्य कार्यक्रम यह मानते हैं कि कोई भी कभी भी इस तरह से फाइलें नहीं खोलता है, क्योंकि MSVC fopen() ऐसा नहीं कर सकता है। इसलिए वे (अभी भी अनिर्दिष्ट) प्रोग्राम ध्वज सेट करने वाले गो प्रोग्राम को तोड़ देंगे।

एलेक्स, अगर बाहरी पहुंच की अनुमति है तो कोई नाम बदलने का प्रयास कर सकता है, ...

यदि आप नाम बदलने के लिए तैयार हैं, तो आपको गो रेपो कोड में कुछ भी बदलने की आवश्यकता नहीं है। आपका प्रोग्राम उतना ही अच्छा काम करेगा जितना अभी काम करता है।

अभी, एकमात्र समाधान गो की मानक लाइब्रेरी से कोड का एक गुच्छा कॉपी करना है, एक पंक्ति बदलना है, और फिर उस कांटे को हमेशा के लिए बनाए रखना है।

मुझे लगता है कि कोड को अलग पैकेज में कॉपी करना ठीक है। https://github.com/moby/moby/pull/39974 की जांच करते समय मुझे भी यही विचार आया। मुझे नहीं लगता कि बनाए रखने के लिए बहुत अधिक कोड है। वास्तव में मैंने बस यही लागू किया

https://github.com/alexbrainman/goissue34681

बेझिझक कॉपी करें या जैसा है वैसा ही उपयोग करें। हो सकता है, इस कार्यक्षमता में इतनी रुचि है, आप वास्तव में उचित पैकेज बनाते हैं जिसे दूसरों द्वारा साझा और उपयोग किया जा सकता है। इस तरह आप इसे अप टू डेट रख सकते हैं और बग्स को ठीक कर सकते हैं।

@rsc , इससे पहले कि आप इसे अस्वीकार करें, आइए सुनें कि एलेक्स आपके O_ALLOW_DELETE प्रस्ताव के बारे में क्या सोचता है।

प्रयास करें

https://github.com/alexbrainman/goissue34681

प्रथम। यदि आप किसी कारण से संतुष्ट नहीं हैं, तो हम गो रेपो में नई कार्यक्षमता जोड़ने पर चर्चा कर सकते हैं।

शुक्रिया।

एलेक्स

मैं इस प्रतिक्रिया से वास्तव में निराश हूं।

कोड के इस बड़े समूह की नकल करना, जिसे काफी हद तक समझा भी नहीं जाता है (as .)
यह ऐसा क्यों कर रहा है जो यह कर रहा है) बस हम एक ही विकल्प जोड़ सकते हैं
कि सिस्टम स्वयं का समर्थन करता है, बस वह जाओ, अधिकतर संभावना है कि मैं नहीं मानता
यहां तक ​​कि जानबूझकर, विकल्प को यहां तक ​​कि नीचे पारित करने का साधन भी प्रदान नहीं करता है
syscall.Open एक हास्यास्पद स्थिति की तरह लगता है।

मुझे इस विकल्प को पास करने के लिए syscall.Open को फिर से क्यों लिखना है?

शनिवार, 5 अक्टूबर, 2019 को 18:43 पर एलेक्स ब्रेनमैन नोटिफिकेशन @github.com ने लिखा:

एलेक्स, अगर बाहरी पहुंच की अनुमति है तो कोई नाम बदलने का प्रयास कर सकता है, ...

यदि आप नाम बदलने के लिए तैयार हैं, तो आपको कुछ भी बदलने की आवश्यकता नहीं है
गो रेपो कोड में। आपका प्रोग्राम उतना ही अच्छा काम करेगा जितना अभी काम करता है।

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

मुझे लगता है कि कोड को अलग पैकेज में कॉपी करना ठीक है। जांच करते समय
moby/moby#39974 https://github.com/moby/moby/pull/39974 मुझे वही मिला
विचार। मुझे नहीं लगता कि बनाए रखने के लिए बहुत अधिक कोड है। वास्तविकता में, मैं
बस इतना ही लागू किया

https://github.com/alexbrainman/goissue34681

बेझिझक कॉपी करें या जैसा है वैसा ही उपयोग करें। हो सकता है, दिया गया, इसमें बहुत रुचि है
यह कार्यक्षमता, आप वास्तव में उचित पैकेज बनाते हैं जिसे साझा किया जा सकता है
और दूसरों द्वारा उपयोग किया जाता है। इस तरह आप इसे अप टू डेट रख सकते हैं और बग्स को ठीक कर सकते हैं।

@rsc https://github.com/rsc , इससे पहले कि आप इसे अस्वीकार करें, आइए सुनते हैं क्या
एलेक्स आपके O_ALLOW_DELETE प्रस्ताव के बारे में सोचता है।

प्रयास करें

https://github.com/alexbrainman/goissue34681

प्रथम। यदि आप किसी कारण से संतुष्ट नहीं हैं, तो हम नया जोड़ने पर चर्चा कर सकते हैं
गो रेपो की कार्यक्षमता।

शुक्रिया।

एलेक्स

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/32088?email_source=notifications&email_token=AAGDCZXHULQEMHAPTO6ZUJTQNFGE7A5CNFSM4HNPNYIKYY3PNVWWK3TUL52HS4DFVREXGEAN7QM
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAGDCZWYUNMCTAGO567AV73QNFGE7ANCNFSM4HNPNYIA
.

>

• ब्रायन गोफ्

मैं इस प्रतिक्रिया से वास्तव में निराश हूं।

मुझे खेद है कि आप ऐसा महसूस करते हैं। लेकिन क्या आपने वास्तव में मेरे पैकेज का उपयोग करने की कोशिश की?

एलेक्स

@rsc , चूंकि एलेक्स एक os.OpenFile() ध्वज का भी विरोध करता है, क्या हमें कुछ नहीं करना चाहिए?

इस सुविधा को बिल्ड फ्लैग के पीछे कैसे रखा जाए?

जैसे कि "गो ने लगभग 10 वर्षों तक विंडोज़ पर ठीक काम किया," यह निश्चित रूप से नहीं था, उस स्थिति में जब आपको एक खुली फ़ाइल का नाम बदलने की आवश्यकता होती है। (यह पिछले 7 वर्षों से विंडोज 8/10 लैपटॉप पर भी टूटा हुआ था।)

मेरे पास os.OpenFile और syscall का अपना कांटा है। पहले से ही moby/moby में खोलें।

हम यहाँ इतने बर्खास्त क्यों हो रहे हैं?

मंगलवार, 8 अक्टूबर, 2019 को 01:47 बजे एलेक्स ब्रेनमैन नोटिफिकेशन @github.com ने लिखा:

मैं इस प्रतिक्रिया से वास्तव में निराश हूं।

मुझे खेद है कि आप ऐसा महसूस करते हैं। लेकिन क्या आपने वास्तव में मेरे पैकेज का उपयोग करने की कोशिश की?

एलेक्स

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपका उल्लेख किया गया था।
इस ईमेल का सीधे उत्तर दें, इसे GitHub पर देखें
https://github.com/golang/go/issues/32088?email_source=notifications&email_token=AAGDCZRV72GY4IJQJVJWMYTQNRCIHA5CNFSM4HNPNYIKYY3PNVWWK3TUL52HS4DFVREXGEAVMVBW63LNMVXHJJKT
या थ्रेड को म्यूट करें
https://github.com/notifications/unsubscribe-auth/AAGDCZRNYSMIE6BX77XJVWDQNRCIHANCNFSM4HNPNYIA
.

>

• ब्रायन गोफ्

मेरा सुझाव है कि इस विशिष्ट प्रस्ताव को अस्वीकार कर दिया जाए। हम उन विंडोज़ उपयोगकर्ताओं के लिए TOCTOU सुरक्षा बग्स का एक समूह पेश नहीं करने जा रहे हैं जो os.OpenFile के मौजूदा व्यवहार पर निर्भर थे।

यहां बड़ा सवाल यह है कि, "हम विंडोज़ के CreateFile और NtCreateFile फ़ंक्शंस के लिए गो उपयोगकर्ताओं के सामने विभिन्न प्रकार के दिलचस्प फ़्लैग कैसे प्रदर्शित कर सकते हैं?" मुझे उम्मीद है कि हम अलग-अलग प्रस्तावों में उन्हें संबोधित करने में सक्षम होंगे, लेकिन निश्चित रूप से उन सभी को डिफ़ॉल्ट रूप से चालू करके नहीं, जैसा कि यहां बताया गया है।

@ zx2c4 क्या आपने पूरा सूत्र पढ़ा? हम गो उपयोगकर्ता के एक भी मामले की पहचान करने में सक्षम नहीं थे, जो बार-बार प्रयासों के बावजूद मौजूदा, गैर-दस्तावेज व्यवहार पर निर्भर करता है।

https://github.com/golang/go/issues/32088#issuecomment -537590826 को एक सप्ताह हो गया है, और अभी भी बहुत स्पष्ट सहमति नहीं है, जिसका अर्थ है कि हमें इसे अस्वीकार कर देना चाहिए।

इंकार कर दिया।

मैंने https://github.com/golang/go/issues/34681#issuecomment -565853605 में पेशेवरों और विपक्षों के साथ विकल्पों का सारांश पोस्ट किया है।