פורסם 2010 ביולי 1015 שנים הדרך הפשוטה ביותר...ללא פרמוט... כנס לCMD (הפעלה) ורשוםconvert X: /fs:ntfsהערה: אי אפשר להחזיר לFAT שוב בלי פרמוט!!!
פורסם 2010 ביולי 1015 שנים מחבר הדרך הפשוטה ביותר...ללא פרמוט... כנס לCMD (הפעלה) ורשוםconvert X: /fs:ntfsהערה: אי אפשר להחזיר לFAT שוב בלי פרמוט!!!זה לא עובד
פורסם 2010 ביולי 1015 שנים תשתמש בתוכנת ניהול מחיצות GPARTED או תוכנה דומה.תמחק את כל המחיצות בדיסק וגם את הMBR.ותיצור מחיצה חדשה NTFS
פורסם 2010 ביולי 1115 שנים שכתבתי convert X לא התכוונתי שתרשום X אלא את שם הכונן שאותו את רוצה להפוך ל NTFS אולי מכאן נובעת הטעות שלך אולי ?.
פורסם 2010 ביולי 1215 שנים תכנס לDevice Manager תחת הכוננים תמצא את הדיסק הנייד שלך, לחיצה ימנית Properties, תחת אחד הטאבים אמור להיות לך 2 אופציות Optimize for removal וOptimize for performance תחבר בשניה(Performance) לאחר מכן תוכל לפרמט את הכונן כNTFS.יש סימה למה Windows לא מאפשרת לפרמט כוננים ניידים לNTFS סתם ככה, זאת מערכת קבצים רגישה יחסית. מה שאומר שכיוון שNTFS בין השאר מתבססת על Transaction Journal הוצאה של הדיסק ללא "Eject" בSafely remove devices/לחיצה ימנית על האייקון שלו במחשב שלי תוביל ליצירה של שגיאות במערכת הקבצים, UBEים ואיבוד מידע אם זה נעשה בצורה שיגרתית.
פורסם 2010 ביולי 1215 שנים דובי, הJOURNALING דווקא משפר את אמינות המידע ושחזורו. תיזכר בימי FAT32 העליזים שכל הפסקת חשמל היתה מאבדת את הקובץ שעבדת עליו (ולפעמים גם את כל מערכת הקבצים עצמה ) עריכה: יש לציין שחיפוש קצר בסטיקי היה נותן לך את הפתרון שדובי כתב.
פורסם 2010 ביולי 1215 שנים אתה תמיד יכול פשוט לפצל את הקובץ לחלקים שקטנים מ4 ג'יגה..אפשר עם winrar אבל יותר מהיר עם http://www.dekabyte.com/filesplitter/ או hjsplit..
פורסם 2010 ביולי 1215 שנים דובי, הJOURNALING דווקא משפר את אמינות המידע ושחזורו. תיזכר בימי FAT32 העליזים שכל הפסקת חשמל היתה מאבדת את הקובץ שעבדת עליו (ולפעמים גם את כל מערכת הקבצים עצמה ) עריכה: יש לציין שחיפוש קצר בסטיקי היה נותן לך את הפתרון שדובי כתב. לא בדיוק, גם בFAT היה לך Journal אבל ברמת הFS DRIVER, זה למה אחרי כל "ריסט" היה לך check disk שאחד הדברים שהוא עשה זה להתאים את ה journal של מערכת הקבצים הלוגית לfile allocation table של מערכת הקבצים הפיזית. בNTFS כל פעולה נרשמת בלוג, חוסר קונסיסטניות בלוג גורם לשגיעות של מערכת הקבצים ואיבוד מידע, מה עוד שFAT32 לא תומכת בDelayed Write מבחינת הדרייבר, ככה שזה מוריד את הסיכוי שאתה שולף קובץ שמבחינת מערכת ההפעלה "סיים" להכתב, אבל בפועל עדיין לא כתוב על הדיסק.
פורסם 2010 ביולי 1215 שנים ^^^^^ בתכל'ס, הפסקת מתח באמצע " דופקת " את הכתיבה לדיסק, וזה בלי להיכנס לרמות של ג'ורנל ושות'. מפליא שבשלל השיפורים שמכניסים למערכות ההפעלה, לא פותרים את הבעיה שמעלה פותח הדיון, נניח ע"י פיצול אוטומתי שיבוצע ע"י מ"ה עצמה, ללא צורך בתוכנות צד שלישי, כאילו מה הבעיה ?
פורסם 2010 ביולי 1215 שנים לא בדיוק' date=' גם בFAT היה לך Journal אבל ברמת הFS DRIVER, זה למה אחרי כל "ריסט" היה לך check disk שאחד הדברים שהוא עשה זה להתאים את ה journal של מערכת הקבצים הלוגית לfile allocation table של מערכת הקבצים הפיזית.בNTFS כל פעולה נרשמת בלוג, חוסר קונסיסטניות בלוג גורם לשגיעות של מערכת הקבצים ואיבוד מידע, מה עוד שFAT32 לא תומכת בDelayed Write מבחינת הדרייבר, ככה שזה מוריד את הסיכוי שאתה שולף קובץ שמבחינת מערכת ההפעלה "סיים" להכתב, אבל בפועל עדיין לא כתוב על הדיסק.[/quote']היתרון הגדול בלוג של הNTFS, שעקרונית לכל ביט שעובר ממקום למקום\נכתב פעם ראשונה יש "יומן" ששומר עליו, ואם יש חוסר עקיבות בנתוניםמערכת הקבצים יודעת לחפש במקום הקודם של הביט ובמקום שאליו היה אמור לעבור ולשמור על המידע. בFAT סה"כ היו בועטים את השינוי לקבציFOUND והמידע היה הולך לאיבוד. נשאל בצורה יותר פשוטה - מתי בפעם האחרונה הושחת לך קובץ שהיה בשימוש (של המשתמש או מערכת ההפעלה) בהפסקת חשמל עם NTFS? עכשיו תשאל את עצמך אותה שאלה על הFAT.
פורסם 2010 ביולי 1215 שנים אבל כבר פתרו את הבעיה. לפתרון קוראים ntfs או ext2/3/4 או עוד מספר שמות בכל הצניעות ובמלא הרצינות - אני יודע את הפתרונות, וגם אתה יודע את הפתרונות למה שהתלבטתי אם לקרוא לו " בעיה ". אבל העובדה היא שכל פרק זמן צצות השאלות האלה, ורק תהיתי מה כ"כ קשה לעשות את זה במ"ה. קורה שנעבד מידע גם ללא הפסקות חשמל, קל וחומר כשיש. גם עם NTFS.
פורסם 2010 ביולי 1215 שנים בכל הצניעות ובמלא הרצינות - אני יודע את הפתרונות, וגם אתה יודע את הפתרונות למה שהתלבטתי אם לקרוא לו " בעיה ". אבל העובדה היא שכל פרק זמן צצות השאלות האלה, ורק תהיתי מה כ"כ קשה לעשות את זה במ"ה. קורה שנעבד מידע גם ללא הפסקות חשמל, קל וחומר כשיש. גם עם NTFS. כי מערכת הקבצים לא בנויה לזה, ואם אתה עושה את זה רק ממערכת ההפעלה אז זה לא יהיה תקף אם תעביר את זה למחשב אחר. היתרון הגדול בלוג של הNTFS, שעקרונית לכל ביט שעובר ממקום למקום\נכתב פעם ראשונה יש "יומן" ששומר עליו, ואם יש חוסר עקיבות בנתונים מערכת הקבצים יודעת לחפש במקום הקודם של הביט ובמקום שאליו היה אמור לעבור ולשמור על המידע. בFAT סה"כ היו בועטים את השינוי לקבצי FOUND והמידע היה הולך לאיבוד. נשאל בצורה יותר פשוטה - מתי בפעם האחרונה הושחת לך קובץ שהיה בשימוש (של המשתמש או מערכת ההפעלה) בהפסקת חשמל עם NTFS? עכשיו תשאל את עצמך אותה שאלה על הFAT. זה נע בין לא מדוייק ללא נכון בFAT יש 2 טבלאות של קבצים שמשמשות לשחזור במקרה של נפילה, בFAT עקרונית גם אין הגבלה לגודל קובץ עד ל2GBIT, רוב ההגבלות הן תוצאה של תוכנות הפרמוט של MS שהן דיי ביזיוניות, וגם שאר מערך התוכנה התומך היה על הפנים, מערכות קניוניות אחרות שמשתמשות בFAT אפילו לא 32 מתגברות הרבה יותר טוב על הבעיות שאתה טוען שיש כביכול, סה"כ זה היה עניין של כמה משאבים רצו להקצות לניהול מערכת הקבצים, וזה לא היה הרבה. בקשר למה שאמרת על NTFS זה רחוק מלהיות מדוייק, יש לוג טרנזקציות, מערכת ההפעלה לא בדיוק יודעת לחפש במקום הקודם, היא יודעת לשחזר את הMFT בעזרת המידע שנשמר ב $MFTmirr ו$Log_File, אם תנסה להעתיק קובץ ממקום למקום ותוציא את החשמל מהדיסק באמצע אל תצפה שהקובץ שלך יחזור למקום המקורי שלו, או תוכל להמשיך בפעולה ישר לאחר מכן(וכן יש מערכות קבצים שכן מאפשרות את זה). עכשיו בנוסף לזה יש את הUSN, שכן הוא מתאר כל דבר שנעשה אבל הוא איננו שומר מידע או את מהות השינוי עצמו. שמירה ברמה שאתה "מתאר" נקראת Sapshotting שבה כל שינוי מתבצע ללא שינוי המידע המקורי אלא על יצירת מידע חדש והחלפה ההפניות מבחינת מערכת הקבצים למיקום של המידע שנוסף או השתנה, תוך שמירת המפנים הישנים למידע שכביכול השתנה. NTFS תומך בזה תחת VSS.
ארכיון
דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.