Γιατί δεν μπορώ να αλλάξω αρχεία σε χρήση στα Windows όπως μπορώ σε Linux και OS X;
Όταν χρησιμοποιείτε το Linux και το OS X, το λειτουργικό σύστημα δεν θα σας εμποδίσει να διαγράψετε ένα αρχείο που χρησιμοποιείται αυτή τη στιγμή στα Windows, θα σας εμποδίζεται ρητά να το κάνετε. Τι δίνει; Γιατί μπορείτε να επεξεργαστείτε και να διαγράψετε αρχεία σε χρήση σε συστήματα που προέρχονται από Unix, αλλά όχι σε Windows?
Η σημερινή συνάντηση ερωτήσεων και απαντήσεων έρχεται σε επαφή με το SuperUser - μια υποδιαίρεση του Stack Exchange, μια κοινότητα που κατευθύνεται από τους ιστότοπους ερωτήσεων & απαντήσεων.
Το ερώτημα
Ο αναγνώστης SuperUser the.midget θέλει να μάθει γιατί τα Linux και τα Windows αντιμετωπίζουν τα αρχεία σε χρήση με διαφορετικό τρόπο:
Ένα από τα πράγματα που με προβλημάτισε από τότε που άρχισα να χρησιμοποιώ το Linux είναι το γεγονός ότι σας επιτρέπει να αλλάξετε το όνομα ενός αρχείου ή ακόμα και να το διαγράψετε ενώ διαβάζεται. Ένα παράδειγμα είναι το πώς κατά λάθος προσπάθησα να διαγράψω ένα βίντεο ενώ έπαιζε. Επιτυχία και εκπλήσσει καθώς έμαθα ότι μπορείτε να αλλάξετε σχεδόν τίποτα σε ένα αρχείο χωρίς να φροντίζετε εάν χρησιμοποιείται αυτή τη στιγμή ή όχι.
Λοιπόν, τι συμβαίνει πίσω από τις σκηνές και τον εμποδίζει να διαγράψει χωρίς δισταγμό τα πράγματα στα Windows όπως μπορεί στο Linux?
Η απάντηση
Οι συνεισφέροντες του SuperUser ρίχνουν λίγο φως στην κατάσταση για το αντικείμενο. Εντυπωσιασμένος γράφει:
Κάθε φορά που ανοίγετε ή εκτελείτε ένα αρχείο στα Windows, τα Windows κλειδώνουν το αρχείο στη θέση του (πρόκειται για απλούστευση, αλλά συνήθως είναι αληθές). Ένα αρχείο το οποίο είναι κλειδωμένο από μια διαδικασία δεν μπορεί να διαγραφεί μέχρι να κυκλοφορήσει αυτή η διαδικασία. Αυτός είναι ο λόγος για τον οποίο κάθε φορά που τα Windows πρέπει να ενημερώνονται μόνοι σας χρειάζεστε μια επανεκκίνηση για να τεθεί σε ισχύ.
Από την άλλη πλευρά, τα λειτουργικά συστήματα που μοιάζουν με Unix, όπως το Linux και το Mac OS X, δεν κλειδώνουν το αρχείο αλλά τους υποκείμενους τομείς δίσκου. Αυτό μπορεί να φαίνεται μια ασήμαντη διαφοροποίηση αλλά σημαίνει ότι η καταγραφή του αρχείου στον πίνακα περιεχομένων του συστήματος αρχείων μπορεί να διαγραφεί χωρίς να διαταραχθεί οποιοδήποτε πρόγραμμα που έχει ήδη ανοίξει το αρχείο. Έτσι, μπορείτε να διαγράψετε ένα αρχείο ενώ εξακολουθεί να εκτελείται ή να χρησιμοποιείται με άλλο τρόπο και θα συνεχίσει να υπάρχει στον δίσκο, εφόσον κάποια διαδικασία έχει ανοιχτή λαβή γι 'αυτό, παρόλο που έχει καταργηθεί η καταχώρησή του στον πίνακα αρχείων.
Ο David Schwartz επεκτείνει την ιδέα και τονίζει πώς τα πράγματα πρέπει να είναι ιδανικά και πώς είναι στην πράξη:
Τα προεπιλεγμένα Windows είναι αυτόματη, υποχρεωτική ασφάλιση αρχείων. Το UNIX είναι προεπιλεγμένο σε χειροκίνητο, συνεργατικό κλείδωμα αρχείων. Και στις δύο περιπτώσεις, οι προεπιλογές μπορούν να αντικατασταθούν, αλλά και στις δύο περιπτώσεις συνήθως δεν είναι.
Πολλοί παλιότεροι κωδικοί των Windows χρησιμοποιούν το API C / C ++ (λειτουργίες όπως fopen) και όχι το εγγενές API (λειτουργίες όπως το CreateFile). Το API C / C ++ δεν σας δίνει τρόπο να καθορίσετε τον τρόπο με τον οποίο θα λειτουργήσει το υποχρεωτικό κλείδωμα, ώστε να λάβετε τις προεπιλογές. Η προεπιλεγμένη "λειτουργία κοινής χρήσης" τείνει να απαγορεύει τις "αντικρουόμενες" λειτουργίες. Εάν ανοίξετε ένα αρχείο για εγγραφή, οι εγγραφές υποτίθεται ότι έρχονται σε σύγκρουση, ακόμα και αν ποτέ δεν γράφετε πραγματικά στο αρχείο. Ditto για μετονομασία.
Και, εδώ, γίνεται χειρότερη. Εκτός από το άνοιγμα για ανάγνωση ή εγγραφή, το C / C ++ API δεν παρέχει τρόπο να καθορίσετε τι σκοπεύετε να κάνετε με το αρχείο. Επομένως, το API πρέπει να υποθέσει ότι πρόκειται να εκτελέσετε οποιαδήποτε νομική λειτουργία. Δεδομένου ότι το κλείδωμα είναι υποχρεωτικό, ένα ανοιχτό που επιτρέπει μια αντιφατική λειτουργία θα απορριφθεί, ακόμα και αν ο κώδικας δεν είχε ποτέ την πρόθεση να εκτελέσει τη συγκρουόμενη λειτουργία, αλλά άνοιξε ακριβώς το αρχείο για άλλο σκοπό.
Έτσι, αν ο κώδικας χρησιμοποιεί το API C / C ++ ή χρησιμοποιεί το εγγενές API χωρίς να σκεφτεί ειδικά αυτά τα ζητήματα, θα τελειώσει, εμποδίζοντας το μέγιστο σύνολο πιθανών λειτουργιών για κάθε αρχείο που ανοίγει και δεν μπορεί να ανοίξει ένα αρχείο, θα μπορούσε να εκτελέσει σε αυτό ανοιχτό δεν έχει καμία επίθεση.
Κατά τη γνώμη μου, η μέθοδος των Windows θα λειτουργούσε πολύ καλύτερα από τη μέθοδο UNIX αν κάθε πρόγραμμα επέλεξε τις λειτουργίες κοινόχρηστων εφαρμογών και τις ανοιχτές λειτουργίες με σοφά και σωστά διαχειριζόμενες περιπτώσεις αποτυχίας. Η μέθοδος UNIX, ωστόσο, λειτουργεί καλύτερα εάν ο κώδικας δεν έχει τον κόπο να σκεφτεί αυτά τα θέματα. Δυστυχώς, το βασικό C / C ++ API δεν χαρτογραφεί καλά στο API αρχείου των Windows με τρόπο που να χειρίζεται τις λειτουργίες κοινής χρήσης και οι αντιφατικές λύσεις ανοίγουν καλά. Έτσι το καθαρό αποτέλεσμα είναι λίγο βρώμικο.
Εκεί το έχετε: δύο διαφορετικές προσεγγίσεις στο χειρισμό αρχείων αποφέρουν δύο διαφορετικά αποτελέσματα.
Έχετε κάτι να προσθέσετε στην εξήγηση; Απενεργοποιήστε τα σχόλια. Θέλετε να διαβάσετε περισσότερες απαντήσεις από άλλους τεχνολογικούς χρήστες Stack Exchange; Δείτε το πλήρες νήμα συζήτησης εδώ.