উইন্ডোতে 260 অক্ষরের পাথ দৈর্ঘ্যের সীমা কেন বিদ্যমান?

Question

অপ্রয়োজনীয় মুহুর্তে আমি কয়েকবার এই সমস্যার বিরুদ্ধে এসেছি:

• গভীর পাথ সহ ওপেন সোর্স জাভা প্রকল্পগুলিতে কাজ করার চেষ্টা করা
• উত্স নিয়ন্ত্রণে গভীর ফিটনেস উইকি গাছ সংরক্ষণ করা
• আমার উত্স নিয়ন্ত্রণ গাছ আমদানি করতে বাজার ব্যবহার করার চেষ্টা করার সময় একটি ত্রুটি

কেন এই সীমা বিদ্যমান?

কেন এটি এখনও সরানো হয়নি?

আপনি কীভাবে পথ সীমাটি সহ্য করবেন? এবং না, লিনাক্স বা ম্যাক ওএস এক্সে স্যুইচ করা এই প্রশ্নের বৈধ উত্তর নয়;)

Comments

@Artelius: বাস্তবিক, উইন্ডোজ (Win2K থেকে অন্তত অগ্রে) সমর্থন মোড় পয়েন্ট (না en.wikipedia.org/wiki/NTFS_junction_point ), এবং ভিস্তা অগ্রে NT তে সিম্বলিক লিংক (সমর্থন en.wikipedia.org/wiki/NTFS_symbolic_link )। যাইহোক, যখন সিমলিংকগুলি দীর্ঘ / নেস্টেড পাথগুলিকে আরও বন্ধুত্বপূর্ণ করতে সহায়তা করতে পারে, আপনি ভাবতে পারি না যে আপনি যদি পথের দৈর্ঘ্যের সীমাটি আঘাত করছেন তবে সিমলিংকগুলি কীভাবে সহায়তা করবে।

— আশুতোষ মেহরা

এমনকি যদি এই সীমাটি না থাকে তবে সর্বদা প্রচুর পরিমাণে অন্যান্য সীমা থাকে এবং তাদের প্রত্যেকটি কোনও না কোনও সময়ে বিরক্তিকর হতে পারে। মুল বিষয় এই সীমাটি এত কম কেন? 8.3 এর যুগের পরে এবং মেগা / গিগা আকারের হার্ডওয়্যার সহ, একটি পাথ এখন ভার্চুয়াল সীমাহীন আকারের গতিশীল বরাদ্দযুক্ত স্ট্রিং হওয়া উচিত।

— রোল্যান্ড

মাইক্রোসফ্ট অবশেষে উইন্ডোজ 10 বিল্ড 14352

— ওয়ারেন পি

হ্যাঁ, এবং দেখে মনে হচ্ছে আপনাকে দীর্ঘ পথ সচেতন করার জন্য আপনাকে অ্যাপ্লিকেশন ম্যানিফেস্টটি সংশোধন করতে হবে।

— ওয়ারেন পি

@ পেট্রিকসালাপস্কি দুর্ভাগ্যক্রমে এটি স্থির করা হয়েছিল ভিজ্যুস্টুডিও.ইউসারওয়্যস

— //

Answer 1

এই নিবন্ধটির উদ্ধৃতি https://docs.microsoft.com/en-us/windows/desktop/FileIO/naming-a-file#maximum-path-leth-limization

সর্বাধিক পথ দৈর্ঘ্য সীমাবদ্ধতা

উইন্ডোজ এপিআইতে (নিম্নলিখিত অনুচ্ছেদে কিছু ব্যতিক্রম নিয়ে আলোচনা করা হয়েছে), কোনও পাথের সর্বাধিক দৈর্ঘ্য হল MAX_PATH , এটি 260 টি অক্ষর হিসাবে সংজ্ঞায়িত। স্থানীয় পাথ নিম্নলিখিত ক্রমে কাঠামোযুক্ত: ড্রাইভ লেটার, কোলন, ব্যাকস্ল্যাশ, ব্যাকস্ল্যাশ দ্বারা পৃথক করা নাম উপাদান এবং একটি অবসান নাল অক্ষর। উদাহরণস্বরূপ, ড্রাইভ ডি-এর সর্বাধিক পাথ হ'ল "ডি: \ কিছু 256-বর্ণের পাথ স্ট্রিং <NUL>" যেখানে "<NUL>" বর্তমান সিস্টেম কোডকেজের জন্য অদৃশ্য টার্মিনেটিং নাল চরিত্রের প্রতিনিধিত্ব করে। (<< অক্ষরগুলি এখানে ভিজ্যুয়াল স্পষ্টতার জন্য ব্যবহৃত হয় এবং এটি কোনও বৈধ পাথ স্ট্রিংয়ের অংশ হতে পারে না))

এখন আমরা দেখতে পাচ্ছি যে এটি 1 + 2 + 256 + 1 বা [ড্রাইভ] [: \] [পথ] [নাল] = 260 One যে কেউ ধরে নিতে পারে যে ডস দিন থেকে 256 একটি যুক্তিসঙ্গত নির্দিষ্ট স্ট্রিং দৈর্ঘ্য। এবং ডস এপিআইগুলিতে ফিরে আমরা বুঝতে পারি যে সিস্টেমটি প্রতি ড্রাইভের বর্তমান পথটি অনুসরণ করেছে এবং আমাদের 26 (প্রতীক সহ 32) সর্বোচ্চ ড্রাইভ (এবং বর্তমান ডিরেক্টরি) রয়েছে।

INT 0x21 এএইচ = 0x47 বলছে "এই ফাংশনটি ড্রাইভ চিঠি এবং প্রাথমিক ব্যাকস্ল্যাশ ছাড়াই পথের বিবরণ দেয়” " সুতরাং আমরা দেখতে পাচ্ছি যে সিস্টেম সিডাব্লুডিকে একটি জোড় (ড্রাইভ, পাথ) হিসাবে সঞ্চয় করে এবং আপনি ড্রাইভটি নির্দিষ্ট করে (1 = এ, 2 = বি,…) নির্দিষ্ট করার জন্য পথটির জন্য জিজ্ঞাসা করেন, যদি আপনি একটি 0 নির্দিষ্ট করে থাকেন তবে এটির জন্য পথটি ধরে নেওয়া হয়েছে ড্রাইভ INT 0x21 এএইচ = 0x15 AL = 0x19 দ্বারা ফিরে এসেছে। সুতরাং এখন আমরা জানি যে এটি কেন 260 এবং 256 নয়, কারণ tes 4 বাইটটি স্ট্রিং স্ট্রিংয়ে সংরক্ষিত নেই।

কেন 256 বাইট পথের স্ট্রিং, কারণ 640 কে যথেষ্ট র‍্যাম।

Comments

উইন্ডোজ এপিআই সর্বশেষতম ওএসেও দৈর্ঘ্য সীমাবদ্ধ করে। মাইক্রোসফ্ট যদি আজ পরিবর্তিত হয় তবে শত শত মিলিয়ন অপারেটিং সিস্টেমগুলি ভেঙে ফেলতে ভয় পাচ্ছে কারণ তাদের মধ্যে আর কোনও জিনিয়াস নেই যা এআইপি বুঝতে পারে না যেমন তারা 1980 এবং 1990 এর দশকে করেছিল। ঝুঁকি এটি পরিবর্তন করার মতো নয়। serverfault.com/questions/163419/…

— ম্যাকগাইভার

@ ম্যাকজিভার দুঃখিত, তবে এটি একদম বাজে কথা। মাইক্রোসফ্ট সেখানে লক্ষ লক্ষ দুর্বল লিখিত অ্যাপ্লিকেশনগুলি ভেঙে ফেলতে চায় না যা এই সিস্টেম সম্পর্কে এমন জিনিস ধরে নেয় যা কখনই গ্যারান্টিযুক্ত ছিল না। দুর্ভাগ্যক্রমে, এত দিন জিনিসগুলি একইভাবে ছিল যে বিকাশকারীরা তাদের উপর নির্ভর করতে এসেছিলেন, সুতরাং এখন এটি পরিবর্তন করা তৃতীয় পক্ষের অ্যাপ্লিকেশনগুলি ভেঙে ফেলবে এবং এমএস এর দোষ পাবে।

— বেসিক

বিটিডব্লিউর এমন কোনও প্রমাণ নেই যা গেটস কখনও বলেছিল যে "640K রাম সবার জন্য যথেষ্ট" কম্পিউটারওয়ার্ল্ড.

— প্যাট্রিক ফ্যাভরে

@ বেসিক 260 অক্ষরের সীমাটি উইন্ডোজ দ্বারা গ্যারান্টিযুক্ত ছিল । ধ্রুব হিসেবে ঘোষণা করা হয় ধ্রুবক , একটি কাঠামো উইন্ডোজ হেডার ফাইল শুধুমাত্র 260 অক্ষরের জন্য রুম আছে যে ঘোষিত হয়। এটি পরিবর্তন করার কোনও উপায় নেই।

— ইয়ান বয়ড

@ বেসিক এটি একবার আমার অ্যাপ্লিকেশনটিতে সংকলিত হয়ে গেলে ধ্রুবকটি পরিবর্তন হয় না। আমি সর্বশেষে ১৯৯৪ সালে নির্মিত একটি অ্যাপ্লিকেশন চালিয়েছি এবং আজও উইন্ডোজ ১০-এ চালাচ্ছি মাইক্রোসফ্ট একটি নির্দিষ্ট বাইনারি আকারের মেমরির প্রতিশ্রুতি দিয়েছিল এবং প্রোগ্রামার সেই নিয়মটি অনুসরণ করেছিল। মাইক্রোসফ্ট যদি ধ্রুবক পরিবর্তন করে, তবে প্রতিটি বিদ্যমান অ্যাপ্লিকেশন, যিনি সঠিকভাবে প্রোগ্রামিং এপিআই অনুসরণ করেছিলেন, তা নষ্ট হয়ে যাবে । আপনি বাইনারি সামঞ্জস্যতা ভাঙ্গতে পারবেন না।

— ইয়ান বয়ড

Answer 2

এটি কঠোরভাবে সত্য নয় কারণ এনটিএফএস ফাইল সিস্টেম 32k অক্ষর পর্যন্ত পাথ সমর্থন করে। আপনি উইন 32 এপিআই এবং \\?\260 টিরও বেশি অক্ষরের ব্যবহারের জন্য পথটি উপসর্গ ব্যবহার করতে পারেন।

। নেট বিসিএল টিম ব্লগ থেকে দীর্ঘ পথের বিস্তারিত ব্যাখ্যা ।
একটি ছোট অংশটি দীর্ঘ পথ সহ সমস্যাটি তুলে ধরে

আর একটি উদ্বেগ হ'ল অসঙ্গতিপূর্ণ আচরণ যা দীর্ঘ পথ সমর্থন প্রকাশের ফলে ঘটবে। \\?\উপসর্গ সহ দীর্ঘ পথগুলি ফাইল-সম্পর্কিত উইন্ডোজ এপিআইয়ের বেশিরভাগ ক্ষেত্রে ব্যবহার করা যেতে পারে তবে সমস্ত উইন্ডোজ এপিআই নয়। উদাহরণস্বরূপ, লোডলিবারি, যা কলিং প্রক্রিয়াটির ঠিকানায় একটি মডিউল ম্যাপ করে, ফাইলের নাম MAX_PATH এর চেয়ে বেশি লম্বা হলে ব্যর্থ হয়। সুতরাং এর অর্থ হল মুভফিল আপনাকে একটি ডিএলএলকে এমন কোনও স্থানে সরিয়ে ফেলতে দেবে যে এর পথটি 260 টি অক্ষরের চেয়ে দীর্ঘ, তবে আপনি যখন ডিএলএল লোড করার চেষ্টা করবেন, এটি ব্যর্থ হবে। উইন্ডোজ এপিআই জুড়ে একই রকম উদাহরণ রয়েছে; কিছু কর্মক্ষেত্র বিদ্যমান, তবে তারা কেস-কেস-কেস ভিত্তিতে রয়েছে।

Comments

যথেষ্ট উপযুক্ত, তবে এর অর্থ আপনাকে অনেক জায়গায় পি / ইনভোক ব্যবহার করতে হবে এবং এটি আমার মতে আপনার। নেট কোডটির বহনযোগ্যতা হ্রাস করে। আমি কি মনো-সামঞ্জস্য রাখতে চাইলে কী হবে?

— জেফ্রি ক্যামেরন

আমার বক্তব্যটি হ'ল আপনি যদি সত্যিই চান তবে দীর্ঘ পথ ব্যবহার করতে পারবেন। তবে আমি একমত যে এটি একটি ব্যথা এবং ব্যক্তিগতভাবে আমি এটি এড়ানোও চাই।

— সফটভেদ

এটি নির্বাচিত উত্তর হওয়া উচিত। প্রকৃতপক্ষে কেন এই সীমাটি বিদ্যমান এবং ব্যবহারকারীরা একটি কাজের পরিপ্রেক্ষিতে ব্যবহারকারীদের দ্বারা উত্থাপিত প্রশ্নের উত্তর দেয়। দৃশ্যমানতার জন্য উপভোট

— কাইলমিট

এটি আমার কাছে মনে হচ্ছে মাইক্রোসফ্টকে তাদের এপিআইগুলি ঠিক করতে হবে এবং আমি অনুমান করি এটি কোনও অগ্রাধিকার নয়। আমি অবাক হয়েছিলাম যে এই সীমাটি এখনও উইন্ডোজ ৮-এ বিদ্যমান রয়েছে

— মাস

@ আপনি যে "ফিক্স" চান তা উইন্ডোজ এক্সপিতে ফিরে এসেছিল all তাদের API এর ইউনিকোড সংস্করণে কল করা আপনাকে "বর্ধিত পথ" অ্যাক্সেসের অনুমতি দেবে। আমি বিশ্বাস করি এক্সপ্লোরার স্বয়ংক্রিয়ভাবে এটি পরিচালনা করে। - এখানে এক ধরনের ফাংশন এটি সমর্থন করে msdn.microsoft.com/en-us/library/windows/desktop/... ।

— নাটালি অ্যাডামস

Answer 3

প্রশ্নটি কেন এখনও সীমাবদ্ধতা বিদ্যমান? অবশ্যই আধুনিক উইন্ডোজ আরও MAX_PATHদীর্ঘ পথের জন্য পার্শ্ব বাড়িয়ে তুলতে পারে। কেন সীমাবদ্ধতা সরানো হয়নি?

• এটি অপসারণ করা যায় না কারণ উইন্ডোজ প্রতিশ্রুতি দিয়েছিল যে এটি কখনও পরিবর্তন হবে না।

এপিআই চুক্তির মাধ্যমে, উইন্ডোজ সমস্ত অ্যাপ্লিকেশনকে গ্যারান্টি দিয়েছিল যে স্ট্যান্ডার্ড ফাইল এপিআই কখনও 260অক্ষরের চেয়ে দীর্ঘ পথ ফেরায় না ।

নিম্নলিখিত সঠিক কোড বিবেচনা করুন :

WIN32_FIND_DATA findData;

FindFirstFile("C:\Contoso\*", ref findData);

উইন্ডোজ আমার প্রোগ্রামটিকে গ্যারান্টি দিয়েছিল যে এটি আমার WIN32_FIND_DATAকাঠামোকে বিশিষ্ট করবে:

WIN32_FIND_DATA {
   DWORD    dwFileAttributes;
   FILETIME ftCreationTime;
   FILETIME ftLastAccessTime;
   FILETIME ftLastWriteTime;
   //...
   TCHAR    cFileName[MAX_PATH];
   //..
}

আমার অ্যাপ্লিকেশনটি ধ্রুবকের মান ঘোষণা করেনি MAX_PATH, উইন্ডোজ এপিআই করেছে। আমার অ্যাপ্লিকেশনটি সেই সংজ্ঞায়িত মানটি ব্যবহার করে।

আমার কাঠামোটি সঠিকভাবে সংজ্ঞায়িত হয়েছে, এবং কেবলমাত্র 592মোট বাইটগুলি বরাদ্দ করে । এর অর্থ হল যে আমি কেবলমাত্র এমন একটি ফাইল নাম গ্রহণ করতে সক্ষম যা 260অক্ষরের চেয়ে কম । উইন্ডোজ আমাকে প্রতিশ্রুতি দিয়েছিল যে আমি যদি আমার অ্যাপ্লিকেশনটি সঠিকভাবে লিখি তবে আমার অ্যাপ্লিকেশন ভবিষ্যতে কাজ চালিয়ে যাবে।

উইন্ডোজ যদি 260অক্ষরের চেয়ে বেশি ফাইলের মঞ্জুরি দেয় তবে আমার বিদ্যমান অ্যাপ্লিকেশনটি (যা সঠিক এপিআই সঠিকভাবে ব্যবহার করেছে) ব্যর্থ হবে।

মাইক্রোসফ্টকে MAX_PATHধ্রুবক পরিবর্তন করার জন্য যে কেউ ডাকছেন , তাদের প্রথমে নিশ্চিত হওয়া দরকার যে কোনও বিদ্যমান অ্যাপ্লিকেশন ব্যর্থ হয়। উদাহরণস্বরূপ, আমি এখনও একটি উইন্ডোজ অ্যাপ্লিকেশনটির মালিক এবং ব্যবহার করি যা উইন্ডোজ 3.11 এ চালানোর জন্য লেখা হয়েছিল। এটি এখনও 64৪-বিট উইন্ডোজ ১০ এ চলে That যা পিছনের সামঞ্জস্যতা আপনাকে দেয়।

মাইক্রোসফট করেনি পূর্ণ 32.768 পথ নাম ব্যবহার করার জন্য একটি উপায় তৈরি; তবে এটি করার জন্য তাদের একটি নতুন এপিআই চুক্তি তৈরি করতে হয়েছিল। একটির জন্য, ফাইলগুলি গণনা করতে আপনার শেল এপিআই ব্যবহার করা উচিত (হার্ড ড্রাইভ বা নেটওয়ার্ক শেয়ারে সমস্ত ফাইল বিদ্যমান নেই)।

তবে তাদের বিদ্যমান ব্যবহারকারীর অ্যাপ্লিকেশনগুলিও ভঙ্গ করতে হবে না। অ্যাপ্লিকেশনগুলির সিংহভাগ ফাইল কাজের জন্য শেল এপিআই ব্যবহার করে না । প্রত্যেকে কেবল একদিন কল করে FindFirstFile/ FindNextFileএবং কল করে।

Comments

@ জোসিয়াহ কেলার যদি এটি করে থাকে তবে এটি সেই পদ্ধতির জন্য মূলত সংজ্ঞায়িত চুক্তিটি ভেঙে ফেলবে এবং এটি করার ফলে অযৌক্তিক মেমোরিটি ওভাররাইট হয়ে যাবে এবং স্থিরভাবে একটি সুরক্ষা গর্ত খুলে যাবে। এটির সমাধানের একমাত্র উপায় হ'ল নতুন উন্নত এপিআই (ইউনিকোড সচেতন রূপগুলির মতো) অফার করা এবং আশা করি প্রত্যেকে নতুন এপিআই ব্যবহার করে তাদের সমস্ত অ্যাপ্লিকেশনগুলিকে পুনরায় সংযুক্ত / পুনরায় সংযুক্ত করে।

— রাওল্যান্ড শ '

@ রিওস আমি মনে করি না যে আমার বিদ্যমান উইন্ডোজ অ্যাপ্লিকেশনগুলি লিনাক্সে চলবে।

— ইয়ান বয়ড

পিছনের সামঞ্জস্য সুন্দর। তবে আমি মনে করি যে উইন্ডোজ ৩.১ অ্যাপ্লিকেশন সমর্থন করার চেয়ে এই জাতীয় (প্রায়শই সত্যই বাজে) সমস্যাগুলি এড়ানো আরও গুরুত্বপূর্ণ। কত লোক দীর্ঘ পথ ধরে সমস্যার মুখোমুখি হয়? এবং এখনও কত লোক উইন্ডোজ 3.1 অ্যাপ্লিকেশন ব্যবহার করে? এমনকি তারা উইন্ডোজ এক্সপি সমর্থন সমর্থন বাতিল করে। তাহলে কেন তারা কেবল একটি ঘোষণা দেয় না, যে উইন্ডোজ [এক্স] এবং পরবর্তী অ্যাপ্লিকেশনগুলি ধরে নিয়েছে যে 260 অক্ষরের চেয়ে দীর্ঘ পথ আর থাকবে না, যখন তারা দীর্ঘ পথ অবলম্বন করে তখন প্রত্যাশার মতো কাজ করবে না? আমাদের গতির সীমাও গাড়ি বহন করে না।

— জুসচু

@ জুসচু এটি কেবল উইন্ডোজ ৩.১ অ্যাপ্লিকেশন নয়। সঠিক এপিআই ব্যবহার করে আজ লিখিত অ্যাপ্লিকেশনগুলি কাজ করবে না।

— ইয়ান বয়ড

নিবন্ধন করুন নথিপত্র, চুক্তি সৃষ্টি যা তুমি কেন খুব সতর্কতা অবলম্বন কি আপনি নথি হতে হবে ।

— ইয়ান বয়ড

Answer 4

উইন্ডোজ 10 থেকে আপনি একটি রেজিস্ট্রি কী সংশোধন করে সীমাবদ্ধতাটি সরাতে পারেন ।

টিপ উইন্ডোজ 10-এ শুরু হওয়া, সংস্করণ 1607, MAX_PATH সীমাবদ্ধতাগুলি সাধারণ উইন 32 ফাইল এবং ডিরেক্টরি ফাংশন থেকে সরানো হয়েছে। তবে আপনাকে অবশ্যই নতুন আচরণের বিকল্প বেছে নিতে হবে।

একটি রেজিস্ট্রি কী আপনাকে নতুন দীর্ঘ পাথ আচরণ সক্ষম বা অক্ষম করতে দেয়। দীর্ঘ পাথ আচরণ সক্ষম করতে রেজিস্ট্রি কী সেট করুন HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled(প্রকার REG_DWORD:)। প্রভাবিত উইন 32 ফাইল বা ডিরেক্টরি ফাংশনটিতে প্রথম কল করার পরে সিস্টেমে (প্রক্রিয়া অনুসারে) এর মানটি ক্যাশে করা হবে (তালিকা অনুসারে)। প্রক্রিয়াটির জীবদ্দশায় রেজিস্ট্রি কী পুনরায় লোড হবে না। সিস্টেমে সমস্ত অ্যাপ্লিকেশানের কীটির মান সনাক্ত করার জন্য, একটি রিবুট দরকার হতে পারে কারণ কীটি সেট হওয়ার আগে কিছু প্রক্রিয়া শুরু হয়েছিল। রেজিস্ট্রি কী এ গ্রুপ পলিসির মাধ্যমেও নিয়ন্ত্রণ করা যায় Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths। আপনি ম্যানিফেস্টের মাধ্যমে অ্যাপ্লিকেশনে নতুন দীর্ঘ পাথ আচরণ সক্ষম করতে পারবেন:

<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings">
        <ws2:longPathAware>true</ws2:longPathAware>
    </windowsSettings>
</application>

Comments

দুঃখের বিষয় এমনকি সর্বশেষতম সংস্করণ উইন 10 এ, ফাইল এক্সপ্লোরার নিজেই লম্বা পথের নাম নিয়ে সমস্যা করে। এমনকি প্রসঙ্গ মেনুতে "পথ হিসাবে অনুলিপি করুন" প্রত্যাশার মতো কাজ করে না; এটি কেবল প্রথম 260 অক্ষর অনুলিপি করে। আপনি ফোল্ডার তৈরি করতে পারবেন না, অনুলিপি করুন / সরান / ফাইল খুলুন ... আমাকে এই বিস্ময়ের মূল বিষয়টি কি তা ভাবিয়ে তুলুন।

— raymai97

দ্রষ্টব্য যে ম্যানিফেস্টের সেটিং থেকে সিস্টেম সেটিংটি স্বতন্ত্র দাবিটি ভুল। উভয় প্রয়োজন। নীতিটি সিস্টেম পর্যায়ে সক্ষম করতে হবে এবং ম্যানিফেস্টে ঘোষণা করতে হবে যে অ্যাপ্লিকেশনটি দীর্ঘপথ সচেতন।

— এরিক সান

আমি পড়েছি যে এই পরিবর্তনটি করা পুরানো 32-বিট অ্যাপ্লিকেশনগুলির সাথে সামঞ্জস্যের সমস্যার কারণ হতে পারে, তবে কি এই ধরণের সমস্যাটি সামঞ্জস্যতা সাধারণ? আমি নিজেই পরিবর্তনটি করতে চাই। Lifehacker.com/…

— কেডিপি

Answer 5

আপনি কোনও ফোল্ডারটিকে ড্রাইভ হিসাবে মাউন্ট করতে পারেন। কমান্ড লাইন থেকে, যদি আপনার কোনও পথ থাকে তবে আপনি C:\path\to\long\folderএটি X:ব্যবহার করে চিঠিটি চালনা করতে ম্যাপ করতে পারেন :

subst x: \path\to\long\folder

Comments

এই কমান্ডটি চেষ্টা করার সময় আমি "অবৈধ পরামিতি জে" পেয়ে যাচ্ছি

— ব্যারিপিকার

এটি প্রশাসক (উন্নত) কমান্ড প্রম্পট থেকে চালানো দরকার from

— মিঃচিফ

এটি ফরোয়ার্ড স্ল্যাশ সহ ব্যর্থ হবে, ব্যাকস্ল্যাশ হওয়া দরকার।

— চেম্বারলাইন

এটি কেবল উইন্ডোজ 10-এ প্রযোজ্য কিনা তা আমি নিশ্চিত নই, তবে আমি সবেমাত্র পেয়েছি যে এই কমান্ডটি চালানোর চেষ্টা করার সময়, যদি আমি প্রশাসকের পদে চালিত করি তবে উপরের পরামর্শ মতো ড্রাইভ উপলব্ধ হবে না। এর কারণ আচরণটি নেটওয়ার্ক ড্রাইভের ম্যাপিংয়ের অনুরূপ এবং এটি সেশন নির্দিষ্ট ইত্যাদি সম্পর্কিত বলে মনে হয়, তাই যখন আমি প্রশাসক হিসাবে দৌড়ে এসে এই আদেশটি ব্যবহার করি তখন সেই সেশনটি x: TL; DR ব্যবহার করতে পারে আপনি যদি ড্রাইভটি দেখতে না পান তবে অ্যাডমিনিস্ট্রেটর মোডে না রেখে কমান্ডটি চালাচ্ছেন।

— জ্যাডি

substস্থানীয় অধিবেশন / অ্যাকাউন্ট - দেখুন superuser.com/questions/29072/... কিভাবে এটি 'সিস্টেম জুড়ে' কাজকে আপনার জন্য

— user2864740

Answer 6

পাথ সীমাটি সহ্য করার একটি উপায় হ'ল প্রতীকী লিঙ্কগুলির সাথে পাথের প্রবেশাধিকাগুলি সংক্ষিপ্ত করা।

উদাহরণ স্বরূপ:

1. C:\pদীর্ঘ পাথের সংক্ষিপ্ত লিঙ্কগুলি রাখতে একটি ডিরেক্টরি তৈরি করুন
2. mklink /J C:\p\foo C:\Some\Crazy\Long\Path\foo
3. C:\p\fooদীর্ঘ পথের পরিবর্তে আপনার পথে যুক্ত করুন

Comments

প্রথমে ডিরেক্টরি তৈরি করতে হবে না, সুতরাং পদক্ষেপ 1 প্রয়োজনীয় নয়।

— ওহাল

এই কৌশলটি সর্বদা কার্যকর হয় না

— যতগুলি

/jবিকল্প একটি স্থানীয় ভলিউম ডিভাইস বা একটি স্থানীয় ভলিউমে একটি পাথ (ক ইউনিক্স মত বাঁধুন মাউন্ট) এর জন্য মোড় mountpoint সৃষ্টি করে। এটি প্রতীকী লিঙ্ক তৈরি করে না। এটি একটি গুরুত্বপূর্ণ পার্থক্য যেহেতু জংশন মাউন্টপয়েন্টগুলি সর্বদা সার্ভারে মূল্যায়ন করা হয় এবং স্থানীয় ডিভাইসগুলি অবশ্যই লক্ষ্যবস্তু করা উচিত, যখন প্রতীকী লিঙ্কগুলি ক্লায়েন্টে মূল্যায়ন করা হয় এবং দূরবর্তী পাথগুলিকে লক্ষ্য করতে পারে (নীতি দ্বারা অনুমোদিত হলে)। একটি সাবস্টে. ড্রাইভের মতো (যেমন DefineDosDeviceW), একটি জংশন লক্ষ্য সাধারণত প্রায় 4K অক্ষরের মধ্যে সীমাবদ্ধ। এটি আসলে 8 কে অক্ষর, বিকল্প পথ এবং প্রদর্শনের পথের মাঝে সমানভাবে বিভক্ত।

— এরিক সান

Answer 7

আপনি পাওয়ারশেল ব্যবহার করে দীর্ঘ পথের নামগুলি সক্ষম করতে পারেন:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\FileSystem' -Name LongPathsEnabled -Type DWord -Value 1 

অন্য সংস্করণ একটি গোষ্ঠী নীতি ব্যবহার করতে হয় Computer Configuration/ Administrative Templates/ System/ Filesystem:

Comments

প্রতিটি অ্যাপ্লিকেশনটিকে এখনও ঘোষণা করতে হবে যে এটি দীর্ঘপথ সচেতন। মাইক্রোসফ্ট এটিকে যোগাযোগ করে একটি দুর্বল কাজ করেছে যেমন অ্যাপ্লিকেশন ম্যানিফেস্টকে এই বৈশিষ্ট্যটি সক্ষম করার আরও একটি উপায়, এটি ওএস (সিস্টেম স্তর নীতি) এবং অ্যাপ্লিকেশনের মধ্যে একটি চুক্তি যেখানে উভয়কেই সম্মত হতে হবে তা স্পষ্ট করে ব্যাখ্যা করার চেয়ে।

— এরিক সান

Answer 8

হিসেবে কেন এই এখনও বিদ্যমান - এম এস এটা একটি অগ্রাধিকার বিবেচনা করে না, এবং (এই উদাহরণ হিসেবে বলা যায় অন্তত) OS- এর আগুয়ান উপর মান পিছন সামঞ্জস্য।

আমি যে কার্যকারিতাটি ব্যবহার করি তা হ'ল ডিরেক্টরিগুলির জন্য "সংক্ষিপ্ত নাম" তাদের মানক, মানব-পঠনযোগ্য সংস্করণগুলির পরিবর্তে ব্যবহার করা। তাই যেমন জন্য C:\Program Files\আমি ব্যবহার করেন C:\PROGRA~1\ আপনি সংক্ষিপ্ত নাম ব্যবহার করে সমতুল জানতে পারেন dir /x।

Comments

সংক্ষিপ্ত পথের নামগুলি রেজিস্ট্রিগুলিতে অক্ষম করা যেতে পারে (বা এটি নিজেই ফাইলসিস্টেম ছিল?), সুতরাং এটি সত্যিকারের মতো নির্ভরযোগ্য কাজ নয়।

— রুবেনভিবি

@ রুবেনভব আমি নিশ্চিত যে উইন্ডোজের সমস্ত বৈশিষ্ট্য রেজিস্ট্রিতে অক্ষম করা সম্ভব না হলে sure \ _ (ツ) _ / ¯

— কনরাড

সংক্ষিপ্ত নামগুলি এনটিএফএসের জন্য অক্ষম করা যেতে পারে (এবং এটি বেশিরভাগ ক্ষেত্রে এটি অকার্যকর কারণ হওয়া উচিত), পুরো সিস্টেমের জন্য বা ভলিউম প্রতি, তাই এটি সিস্টেম ড্রাইভে পাথের জন্য এমনকি একটি অবিশ্বাস্য পদ্ধতি, যা অবশ্যই এনটিএফএস হতে হবে। এনটিএফএস-এ ফাইল এবং ডিরেক্টরিতে ম্যানুয়ালি সংক্ষিপ্ত নাম স্থাপন করা সম্ভব, তবে এটি নতুন ফাইল সিস্টেমগুলিতে প্রসারিত হয় না যা সংক্ষিপ্ত নামগুলিকে মোটেই সমর্থন করে না যেমন এক্সএফএটি এবং রেফার্স। সংক্ষিপ্ত নামগুলিকে একক- এবং ডাবল-বাইট কোডপেজ ব্যবহার করে পুরানো এএনএসআই / ইএম এপিআই এর মতো সীমিত ক্ষেত্রে সামঞ্জস্যের জন্য ধরে রাখা একটি অবচিত বৈশিষ্ট্য হিসাবে বিবেচনা করা উচিত।

— এরিক সান

@ এরিকসুন সংক্ষিপ্ত পথের নাম অক্ষম করার বিষয়ে দয়া করে আমার আগের মন্তব্যটি দেখুন। :) কেবলমাত্র আপনি মনে করেন যে এটিকে অবচয় বলে বিবেচনা করা উচিত, এর অর্থ এটি আসলে নয়। এমএসের এই বৈশিষ্ট্যটি হ্রাস করার কোনও পরিকল্পনা নেই। (এছাড়াও, আপনি কেন এক্সএফএটিএটি / রেফার্স পার্টিশনে উইন্ডোজ সফ্টওয়্যার ইনস্টল করছেন?)

— কনরাড

আমি এখনও বলি যে কেবলমাত্র নরমালাইজড ডিভাইস পাথগুলি ব্যবহার করুন (যেমন "\\? \" উপসর্গ), যেহেতু তারা সর্বদা উপলব্ধ এবং স্পষ্ট। উদাহরণস্বরূপ, অনুবাদ PATHএবং এটি পাস SearchPathW। এটি কার্যকরও, যেহেতু রানটাইম লাইব্রেরি এনটি জন্য যেভাবেই "\\?।" ডিভাইস পাথ তৈরি করে। নতুন ফাইল সিস্টেমগুলির হিসাবে, আমরা সম্ভবত কোনও এক্সএফএটি ভলিউমে ইনস্টল হওয়া সফ্টওয়্যার দেখতে পাই না, পোর্টেবল অ্যাপ্লিকেশন ব্যতীত অন্য কোনও সফ্টওয়্যার নেই, কারণ এটির কোনও সুরক্ষা নেই, তবে আমি রেফারসকে বাতিল করব না। ব্যবহারকারীরা সুবিধা, স্থান বা কার্য সম্পাদনের কারণে অ-মানক স্থানে প্রোগ্রাম ইনস্টল করে।

— এরিক সান

Answer 9

উইন্ডোজে পাথ আকার সীমাবদ্ধতার সাথে কীভাবে সামলাতে হয় - প্যাক করতে 7zip ব্যবহার করে (এবং আনপ্যাক করা) আপনার পাথ-দৈর্ঘ্যের সংবেদনশীল ফাইলগুলি একটি কার্যক্ষম কর্মের মতো বলে মনে হয়। আমি এটি বেশ কয়েকটি আইডিই ইনস্টলেশন (সেগুলি গ্রহনের প্লাগইন পাথ, ইয়াইক!) এবং অটোজেনারেটেড ডকুমেন্টেশনের পাইলগুলি পরিবহণ করতে ব্যবহার করেছি এবং এখনও পর্যন্ত কোনও সমস্যা হয়নি had

উইন্ডোজ দ্বারা নির্ধারিত 260 চর সীমাটি (কোনও প্রযুক্তিগত পিওভি থেকে) কীভাবে এড়ায় তা সত্যিই নিশ্চিত নয়, তবে ওহে, এটি কার্যকর!

তাদের সোর্সফোর পৃষ্ঠায় আরও বিশদ এখানে :

"এনটিএফএস দৈর্ঘ্যে 32,000 অক্ষর পর্যন্ত প্যাথনামগুলি সমর্থন করতে পারে।"

7-জিপও এ জাতীয় দীর্ঘ নাম সমর্থন করে।

তবে এটি এসএফএক্স কোডে অক্ষম। কিছু ব্যবহারকারী দীর্ঘ পথ পছন্দ করেন না, যেহেতু তারা কীভাবে তাদের সাথে কাজ করবেন তা তারা বোঝে না। এজন্য আমি এটি এসএফএক্স কোডে অক্ষম করে দিয়েছি।

এবং রিলিজ নোট :

9.32 আলফা 2013-12-01

• 260 টি অক্ষরের চেয়ে দীর্ঘ ফাইলের নামের জন্য উন্নত সমর্থন।

4.44 বিটা 2007-01-20

• 7-জিপ এখন 260 টি অক্ষরের চেয়ে দীর্ঘ ফাইলের নামগুলি সমর্থন করে।

গুরুত্বপূর্ণ দ্রষ্টব্য: এটি সঠিকভাবে কাজ করার জন্য, উদ্দেশ্যে উদ্দেশ্যে ফোল্ডারে ফাইলগুলি টেনে এনে ফেলে দেওয়ার পরিবর্তে আপনার সরাসরি 7zip "এক্সট্র্যাক্ট" ডায়ালগের গন্তব্য পথ নির্দিষ্ট করতে হবে । অন্যথায় "টেম্প" ফোল্ডারটি একটি অন্তর্বর্তীকালীন ক্যাশে হিসাবে ব্যবহৃত হবে এবং উইন্ডোজ এক্সপ্লোরার ফাইলগুলিকে তাদের "চূড়ান্ত বিশ্রামস্থানে" স্থানান্তরিত করা শুরু করার পরে আপনি একই 260 চর সীমাবদ্ধতায় চলে আসবেন। আরও তথ্যের জন্য এই প্রশ্নের উত্তর দেখুন ।

Comments

আমি ভুল ছিলাম, 7 জিপ এবং উইনআরআর সমস্ত ফোল্ডার এবং ফাইলগুলি বের করে। এটি কেবলমাত্র উইন্ডোজের কোনও ফোল্ডারের সম্পত্তি সীমাবদ্ধতা লঙ্ঘন করে না এমন ফোল্ডার এবং ফাইলগুলির সংখ্যা কেবল রিপোর্ট করে। এটি মনে হয় যে উইন্ডোজ এক্সপ্লোরার সর্বাধিক পাথ পৌঁছে যাওয়ার পরে ফোল্ডারগুলি আবিষ্কার করার জন্য আরও গভীর খনন করে না।

— পাক হুইস্পার

শিফট-ডেল দিয়ে 7-জিপে দীর্ঘ পথ মুছে ফেলা সম্ভব ।

— লরি স্টারন

সংক্ষিপ্ত উত্তর - একটি .zip ফাইল আনজিপ করতে 7zip ব্যবহার করুন .... আমার জন্য উইন্ডোজ 7

— andrewcockerham

Answer 10

এটি করে, এবং এটি কোনও কারণে একটি ডিফল্ট, তবে আপনি সহজেই এই রেজিস্ট্রি কী দিয়ে ওভাররাইড করতে পারেন:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

দেখুন: https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/

Answer 11

এর সাথে মোকাবিলা করার আরেকটি উপায় হ'ল ফাইলগুলির সাথে আপনি কী করতে চান তার উপর নির্ভর করে সাইগউইনকে ব্যবহার করা (উদাহরণস্বরূপ যদি সাইগউইন আদেশগুলি আপনার প্রয়োজন অনুসারে হয়)

উদাহরণস্বরূপ এটি এমন ফাইলগুলি অনুলিপি, সরানো বা পুনর্নবীকরণ করতে দেয় যা উইন্ডোজ এক্সপ্লোরারও করতে পারে না। অথবা অবশ্যই এমডি 5সাম, গ্রেপ, জিজিপ ইত্যাদির বিষয়বস্তুগুলির সাথে ডিল করুন

এছাড়াও আপনি যে প্রোগ্রামগুলি কোডিং করছেন তার জন্য আপনি সেগুলিন ডিএলএল এর সাথে লিঙ্ক করতে পারেন এবং এটি তাদের দীর্ঘ পথ ব্যবহার করতে সক্ষম করবে (যদিও আমি এটি পরীক্ষা করে দেখিনি)