Geöffnete Dateien verschieben?

[BalkonSurfer]

Hi.
Mir ist grad ein nettes Feature von MacOS aufgefallen und würd gern mal wissen, wie das technisch geht.
Wenn ich eine MP3 Datei mit dem VLC anhöre, kann ich die Datei verschieben wie ich will. Der VLC spielt sie einfach weiter, merkt aber, dass sie woanders liegt...

 

[avalon]

Hi.
Mir ist grad ein nettes Feature von MacOS aufgefallen und würd gern mal wissen, wie das technisch geht.
Wenn ich eine MP3 Datei mit dem VLC anhöre, kann ich die Datei verschieben wie ich will. Der VLC spielt sie einfach weiter, merkt aber, dass sie woanders liegt...

Gut nicht, geht auch bei Downloads, die habe ich währenddessen umbenannt.

Ich will jetzt nicht wissen was Windows dabei anstellen würde....

 

[autoexec.bat]

Ich will jetzt nicht wissen was Windows dabei anstellen würde....

Um jedem bashing vorzugreifen:

Das geht dort einfach nicht.

 

[Ulfrinn]

Das liegt daran, daß die Programme auf geöffnete Dateien unterschiedlich verweisen. Während das ganze unter Windows über den Dateinamen funktioniert, wird unter Mac OS eine namensunabhängige Referenz verwendet.

 

[Graumagier]

Das liegt daran, daß die Programme auf geöffnete Dateien unterschiedlich verweisen. Während das ganze unter Windows über den Dateinamen funktioniert, wird unter Mac OS eine namensunabhängige Referenz verwendet.

Das liegt eher nicht daran, das erklärt lediglich, warum z.B. Aliases auch nach dem Umbenennen der Originaldateien weiterhin funktionieren.
Für das "Phänomen" des Verschiebens ist HFS mit seinem Index verantwortlich.

 

[KAMiKAZOW]

Dass das geht hat nichts mit HFS zu tun, sondern nur damit, dass beim Verschieben/Umbenennen einer Datei der physische Speicherort auf dem Datenträger nicht verändert wird – weder unter HFS, noch unter FAT(32).
Unter BeOS z.B. geht das ohne Probleme auch bei FAT32-Partitionen. Unter OSX bin ich mir jetzt nicht ganz sicher, aber es müsste auch gehen (habe gerade keine FAT32-Partition zur Hand um's zu Testen ).

 

[abgemeldeter Benutzer]

@ KAMiKAZOW

Der physische Speicherort auf dem Datenträger ist dem Anwendungsprogramm überhaupt nicht bekannt. Er ist nur dem Dateisystem bekannt.
Genau das ist ja auch der Sinn eines Dateisystems, dass den Anwendungsprogrammen der physikalische Ort einer Datei auf dem Datenträger nicht bekannt sein muss.

 

[KAMiKAZOW]

Der physische Speicherort auf dem Datenträger ist dem Anwendungsprogramm überhaupt nicht bekannt.

Und was willst du mir jetzt damit sagen? Willst du mir unterstellen, dass ich das gesagt habe? Denn das habe ich nicht gesagt.
Der physische Speicherort muss ja auch der Anwendung nicht bekannt sein. Nur wenn das Betriebsystem eine Datei an ein Programm übergeben hat, ist der Dateiname für die restliche Behandlung unwichtig, weil die Anwendung dann (über das System) auf den Inhalt der Datei zugreift und nicht ständig auf den Dateinamen.

 

[avalon]

Um jedem bashing vorzugreifen:

Das geht dort einfach nicht.

Ich weiß es, aber ich als alter MS Gegner wollte es nicht sagen..

 

[norbi]

Willst du mir unterstellen, dass ich das gesagt habe?

Für mich hörte sich das so an.

Laienhaft formuliert:
Bei HFS wird nicht über den Pfad auf eine Datei zugegriffen, sondern über eine Art "Zeitstempel", der über die ganze Platte einzigartig ist.
Wird eine Datei verschoben, ändert sich dieser "Zeitstempel" nicht, folglich ist die Datei über diesen Zeitstempel immer auffindbar, egal wo sie liegt.

Drum findet eine Alias das Original auch immer, auch wenn das Original (auf der selben Platte) verschoben wurde.

No.

 

[Ulfrinn]

Für das "Phänomen" des Verschiebens ist HFS mit seinem Index verantwortlich.

Allerdings kennt das Programm nicht diesen Zeitstempel. Dem Programm ist nur eine pfadunabhängige Referenz bekannt, wie diese nun auch immer im Detail aussehen mag, wollte ich hier nicht breittreten. Unter Windows referenzieren viele Programme Dateien dagegen über Pfade. Was du gesagt hast, widerspricht dem also im Grund nicht, und es ist genau das, was ich gesagt habe.

 

[abgemeldeter Benutzer]

Und was willst du mir jetzt damit sagen? Willst du mir unterstellen, dass ich das gesagt habe? Denn das habe ich nicht gesagt.
Der physische Speicherort muss ja auch der Anwendung nicht bekannt sein. Nur wenn das Betriebsystem eine Datei an ein Programm übergeben hat, ist der Dateiname für die restliche Behandlung unwichtig, weil die Anwendung dann (über das System) auf den Inhalt der Datei zugreift und nicht ständig auf den Dateinamen.

Auch das ist nicht ganz richtig. Die Datei wird nämlich gar nicht an das Programm übergeben, das Programm muss *immer* über das Dateisystem auf die Datei zugreifen. Wenn die API des Dateisystems keine anderen Referenzen bietet, als den Dateinamen (wie es bei Windows/FAT der Fall ist und auch unter Windows/NTFS, obwohl das Dateisystem durchaus zu mehr in der Lage wäre), ist der Dateiname durchaus für die restliche Behandlung wichtig.
Daher macht Windows ja auch Probleme, wenn man eine geöffnete Datei umbenennt oder verschiebt, Mac OS X aber nicht. Mac OS X ändert sogar den Dateinamen im Fenstertitel (und den mit Aplfe-Klick sichtbaren Pfad) einer geöffneten Datei, wenn dieser im Finder geändert wird.

Außerdem, kann sich der physikalische Speicherort durchaus verändern. Jedenfalls Teilweise. Z.B. bei großen Video-Streams, die während des Abspielens geladen werden. Wenn diese bei einer bestimmten Größe anfangen zu fragmentieren, liegen Teile der Datei ganz woanders auf der Festplatte. Oder sogar komplett, wenn Mac OS X eine Datei in das Hotfiles-Cluster verschiebt oder die automatische Defragmentierung beim Zugriff vornimmt.

Unter Windows referenzieren viele Programme Dateien dagegen über Pfade.

Jedes Programm, anders geht es unter Windows nicht.

 

[Ulfrinn]

Jedes Programm, anders geht es unter Windows nicht.

Es gab mal / gibt eine MFC-kompatible Klasse, die eine namensunabhängige Referenz dargestellt hat. Wie genau das intern funktioniert hat, weiß ich nicht, weil ich sie nie verwendet habe. Ich schau mal, ob ich da noch einen entsprechenden Verweis in den Tiefen meiner Lesezeichensammlung aufreiben kann. Vom Prinzip her hast du aber natürlich recht, denn mit Bordmitteln ist das tatsächlich nicht ohne Weiteres möglich unter Windows.