בחר באתחול

כשאני בוחר באתחול יש לי רק את האפשרות של FAT32

הדרך הפשוטה ביותר...ללא פרמוט...

כנס לCMD (הפעלה) ורשום

convert X: /fs:ntfs

הערה: אי אפשר להחזיר לFAT שוב בלי פרמוט!!!

הדרך הפשוטה ביותר...ללא פרמוט...

כנס לCMD (הפעלה) ורשום

convert X: /fs:ntfs

הערה: אי אפשר להחזיר לFAT שוב בלי פרמוט!!!

זה לא עובד

תשתמש בתוכנת ניהול מחיצות GPARTED או תוכנה דומה.

תמחק את כל המחיצות בדיסק וגם את הMBR.

ותיצור מחיצה חדשה NTFS

שכתבתי convert X לא התכוונתי שתרשום X אלא את שם הכונן שאותו את רוצה להפוך ל NTFS אולי מכאן נובעת הטעות שלך אולי ?.

תכנס לDevice Manager תחת הכוננים תמצא את הדיסק הנייד שלך, לחיצה ימנית Properties, תחת אחד הטאבים אמור להיות לך 2 אופציות Optimize for removal וOptimize for performance תחבר בשניה(Performance) לאחר מכן תוכל לפרמט את הכונן כNTFS.

יש סימה למה Windows לא מאפשרת לפרמט כוננים ניידים לNTFS סתם ככה, זאת מערכת קבצים רגישה יחסית. מה שאומר שכיוון שNTFS בין השאר מתבססת על Transaction Journal הוצאה של הדיסק ללא "Eject" בSafely remove devices/לחיצה ימנית על האייקון שלו במחשב שלי תוביל ליצירה של שגיאות במערכת הקבצים, UBEים ואיבוד מידע אם זה נעשה בצורה שיגרתית.

דובי, הJOURNALING דווקא משפר את אמינות המידע ושחזורו. תיזכר בימי FAT32 העליזים שכל הפסקת חשמל היתה מאבדת את

הקובץ שעבדת עליו (ולפעמים גם את כל מערכת הקבצים עצמה )

עריכה: יש לציין שחיפוש קצר בסטיקי היה נותן לך את הפתרון שדובי כתב.

LOL ת'רד של שלושה עמודים על פרמוט DOK מסכן .

אתה תמיד יכול פשוט לפצל את הקובץ לחלקים שקטנים מ4 ג'יגה..

אפשר עם winrar אבל יותר מהיר עם http://www.dekabyte.com/filesplitter/ או hjsplit..

דובי, הJOURNALING דווקא משפר את אמינות המידע ושחזורו. תיזכר בימי FAT32 העליזים שכל הפסקת חשמל היתה מאבדת את

הקובץ שעבדת עליו (ולפעמים גם את כל מערכת הקבצים עצמה )

עריכה: יש לציין שחיפוש קצר בסטיקי היה נותן לך את הפתרון שדובי כתב.

לא בדיוק, גם בFAT היה לך Journal אבל ברמת הFS DRIVER, זה למה אחרי כל "ריסט" היה לך check disk שאחד הדברים שהוא עשה זה להתאים את ה journal של מערכת הקבצים הלוגית לfile allocation table של מערכת הקבצים הפיזית.

בNTFS כל פעולה נרשמת בלוג, חוסר קונסיסטניות בלוג גורם לשגיעות של מערכת הקבצים ואיבוד מידע, מה עוד שFAT32 לא תומכת בDelayed Write מבחינת הדרייבר, ככה שזה מוריד את הסיכוי שאתה שולף קובץ שמבחינת מערכת ההפעלה "סיים" להכתב, אבל בפועל עדיין לא כתוב על הדיסק.

^^^^^

בתכל'ס, הפסקת מתח באמצע " דופקת " את הכתיבה לדיסק,

וזה בלי להיכנס לרמות של ג'ורנל ושות'.

מפליא שבשלל השיפורים שמכניסים למערכות ההפעלה, לא פותרים את הבעיה

שמעלה פותח הדיון, נניח ע"י פיצול אוטומתי שיבוצע ע"י מ"ה עצמה, ללא צורך בתוכנות

צד שלישי, כאילו מה הבעיה ?

אבל כבר פתרו את הבעיה.

לפתרון קוראים ntfs או ext2/3/4 או עוד מספר שמות

לא בדיוק' date=' גם בFAT היה לך Journal אבל ברמת הFS DRIVER, זה למה אחרי כל "ריסט" היה לך check disk שאחד הדברים שהוא עשה זה להתאים את ה journal של מערכת הקבצים הלוגית לfile allocation table של מערכת הקבצים הפיזית.

בNTFS כל פעולה נרשמת בלוג, חוסר קונסיסטניות בלוג גורם לשגיעות של מערכת הקבצים ואיבוד מידע, מה עוד שFAT32 לא תומכת בDelayed Write מבחינת הדרייבר, ככה שזה מוריד את הסיכוי שאתה שולף קובץ שמבחינת מערכת ההפעלה "סיים" להכתב, אבל בפועל עדיין לא כתוב על הדיסק.

[/quote']

היתרון הגדול בלוג של הNTFS, שעקרונית לכל ביט שעובר ממקום למקום\נכתב פעם ראשונה יש "יומן" ששומר עליו, ואם יש חוסר עקיבות בנתונים

מערכת הקבצים יודעת לחפש במקום הקודם של הביט ובמקום שאליו היה אמור לעבור ולשמור על המידע. בFAT סה"כ היו בועטים את השינוי לקבצי

FOUND והמידע היה הולך לאיבוד. נשאל בצורה יותר פשוטה - מתי בפעם האחרונה הושחת לך קובץ שהיה בשימוש (של המשתמש או מערכת

ההפעלה) בהפסקת חשמל עם NTFS? עכשיו תשאל את עצמך אותה שאלה על הFAT.

אבל כבר פתרו את הבעיה.

לפתרון קוראים ntfs או ext2/3/4 או עוד מספר שמות

בכל הצניעות ובמלא הרצינות - אני יודע את הפתרונות, וגם אתה יודע את הפתרונות

למה שהתלבטתי אם לקרוא לו " בעיה ".

אבל העובדה היא שכל פרק זמן צצות השאלות האלה, ורק תהיתי מה כ"כ קשה

לעשות את זה במ"ה.

קורה שנעבד מידע גם ללא הפסקות חשמל, קל וחומר כשיש. גם עם NTFS.

בכל הצניעות ובמלא הרצינות - אני יודע את הפתרונות, וגם אתה יודע את הפתרונות

למה שהתלבטתי אם לקרוא לו " בעיה ".

אבל העובדה היא שכל פרק זמן צצות השאלות האלה, ורק תהיתי מה כ"כ קשה

לעשות את זה במ"ה.

קורה שנעבד מידע גם ללא הפסקות חשמל, קל וחומר כשיש. גם עם NTFS.

כי מערכת הקבצים לא בנויה לזה, ואם אתה עושה את זה רק ממערכת ההפעלה אז זה לא יהיה תקף אם תעביר את זה למחשב אחר.

היתרון הגדול בלוג של הNTFS, שעקרונית לכל ביט שעובר ממקום למקום\נכתב פעם ראשונה יש "יומן" ששומר עליו, ואם יש חוסר עקיבות בנתונים

מערכת הקבצים יודעת לחפש במקום הקודם של הביט ובמקום שאליו היה אמור לעבור ולשמור על המידע. בFAT סה"כ היו בועטים את השינוי לקבצי

FOUND והמידע היה הולך לאיבוד. נשאל בצורה יותר פשוטה - מתי בפעם האחרונה הושחת לך קובץ שהיה בשימוש (של המשתמש או מערכת

ההפעלה) בהפסקת חשמל עם NTFS? עכשיו תשאל את עצמך אותה שאלה על הFAT.

זה נע בין לא מדוייק ללא נכון בFAT יש 2 טבלאות של קבצים שמשמשות לשחזור במקרה של נפילה, בFAT עקרונית גם אין הגבלה לגודל קובץ עד ל2GBIT, רוב ההגבלות הן תוצאה של תוכנות הפרמוט של MS שהן דיי ביזיוניות, וגם שאר מערך התוכנה התומך היה על הפנים, מערכות קניוניות אחרות שמשתמשות בFAT אפילו לא 32 מתגברות הרבה יותר טוב על הבעיות שאתה טוען שיש כביכול, סה"כ זה היה עניין של כמה משאבים רצו להקצות לניהול מערכת הקבצים, וזה לא היה הרבה. בקשר למה שאמרת על NTFS זה רחוק מלהיות מדוייק, יש לוג טרנזקציות, מערכת ההפעלה לא בדיוק יודעת לחפש במקום הקודם, היא יודעת לשחזר את הMFT בעזרת המידע שנשמר ב $MFTmirr ו$Log_File, אם תנסה להעתיק קובץ ממקום למקום ותוציא את החשמל מהדיסק באמצע אל תצפה שהקובץ שלך יחזור למקום המקורי שלו, או תוכל להמשיך בפעולה ישר לאחר מכן(וכן יש מערכות קבצים שכן מאפשרות את זה). עכשיו בנוסף לזה יש את הUSN, שכן הוא מתאר כל דבר שנעשה אבל הוא איננו שומר מידע או את מהות השינוי עצמו. שמירה ברמה שאתה "מתאר" נקראת Sapshotting שבה כל שינוי מתבצע ללא שינוי המידע המקורי אלא על יצירת מידע חדש והחלפה ההפניות מבחינת מערכת הקבצים למיקום של המידע שנוסף או השתנה, תוך שמירת המפנים הישנים למידע שכביכול השתנה. NTFS תומך בזה תחת VSS.