Timestamp Problem beim Kopieren zwischen Windows und Samba Laufwerken
Markus Benedikt
ich nutze hier ein Programm (namens Secondcopy), dass ein Windows-Verzeichnis
mit einem Samba-Verzeichnis auf dem Eis abgleichen soll (Samba V1.18). Das
gleiche kann auch XCOPY. Jetzt ist es aber so, dass diese beiden Programme
das Dateidatum bzw die Dateiuhrzeit der letzten Modifikation zum Vergleich
heranziehen (ob die Datei geändert wurde) und wird die Datei von einem auf
ein anderes Windows Laufwerk kopiert ist auch alles in Ordnung Problem, die
Uhrzeit der letzten Modifikation ändert sich nicht.
Wird die Datei jedoch auf einen Samba Share kopiert, stimmt die Uhrzeit der
letzten Modifikation nicht exakt mit der Original Datei überein; es gibt eine
Differenz von bis zu 2 Sekunden. Diese führt dazu, dass Secondcopy oder Xcopy
die Datei als geändert identifiziert und kopiert.
Zwei Postings die mit einem identischen Problem meine Frage nach einer Lösung
nochmal verdeutlichen nochmal unten anbei.
Wer kann mir helfen? Wie kann ich erreichen, dass Samba die Uhrzeit der
letzten Modifikation NICHT ändert?
Danke für jede Hilfe in dieser Sache!
--
hi liste !
folgendes problem:
ich muss (leider) mit xcopy /D <SRC> <DST> ein windows-verzeichnis mit
einem samba-verzeichnis abgleichen.
wenn ich auf der windows-maschine eine neue datei erzeuge, wird diese
beim ersten xcopy aufruf auch korrekt rüberkopiert.
leider passiert das aber immer wieder, d.h. windows erkennt nicht,
dass die datei schon auf dem samba in aktueller version vorhanden ist.
testweise "heilen" kann man das, indem ich alle dateien vom samba mit
copy (nicht xcopy) auf die windowskiste hole. dann sind die timestamps
wirklich gleich und xcopy gibt ruhe.
alternativ kann man mit touch die uhrzeit der files auf dem samba auf 2
sekunden jünger stellen als auf der windowskiste und dann geht es auch.
eigenartigerweise sind die files auf dem samba immer eine sekunde jünger
als auf der windowsmaschine.
windows
w2k / SP4 / NTFS
linux
debian woody / ext2 / Samba version 2.2.3a-12.3 for Debian
smb.conf (auszug)
[SUO]
comment = Ablage
path = /daten/suo
read only = No
dos filetimes = Yes
fake directory create times = Yes
dos filetime resolution = Yes
delete readonly = Yes
force directory mode = 777
directory mode = 777
create mode = 666
force create mode = 666
preserve case = No
ich habe die dos file... parameter in verschiedenen kombination
probiert, aber keine änderung.
hat jemand eine tolle idee ?
wäre sehr dankbar dafür :-))
grüsse + danke
stephan
--
Any help with the following would be appreciated.
I have been using, entirely successfully, a batch file for backing up My
Documents folders, on several Win98 and XP machines. Set with several
switches including /D (copies files changed on or after the specified date.
If no date is given copies only those files whose source time is newer than
the destination time). The backup is to a folder on a FreeBSD server with
Samba installed, mapped as virtual network drive H:\.
Now on an existing XP machine, after changing the user, this switch does not
work i.e. the copy command insists on backing up everything, which is very
frustrating.
Any clues as to why this happens would be gratefully received.
A sample batch command follows:
cls
@echo This program will backup to your H:\Backups\folder, all the files
@echo in your C:\Documents & Settings\Richard\My Documents\ folder,
@echo that have newer dates than the date of the last backup, to H:\Backups
@echo The programme will run in the background.
cd\
xcopy C:\docume~1\richard\MyDocu~1\*.* /A /D /S /W /I /R /F /Y H:\Backups\
Regards
Richard Tetley
Markus Benedikt
>Wer kann mir helfen? Wie kann ich erreichen, dass Samba die Uhrzeit der
>letzten Modifikation NICHT ändert?
Ich habe gerade eine Antwort vom Support von Secondcopy bekommen:
--schnipp--
With the old systems such as Irix and Samba 1.19, the file systems which are
exported are mounted as samba file systems. Therefore the two second
difference comes into play when check modification dates.
The new system (Red Hat 7.2 and Samba 2.2). There is a new option in samba
fstype which defaults to NTFS.
Clearly when an NTFS based system mounts the file system from the server the
2 second difference is set to zero and the times have to match.
Please try modifying the smb.conf file and label all file systems as samba
(fstype = samba). After that running the second copy profiles should only
copy new and modified files as expected.
--schnapp--
In der config.d/samba finde ich auf die Schnelle geschaut kein fstype Parameter
an dem sich drehen liese und auch keine andere Möglichkeit.
Wer hat eine Idee?
Thomas Bork
> In der config.d/samba finde ich auf die Schnelle geschaut kein fstype Parameter
>
> an dem sich drehen liese und auch keine andere Möglichkeit.
setze den Parameter von Hand im entsprechenden Share-Abschnitt der
smb.conf und prüfe, ob es tatsächlich einen Unterschied macht.
Laut Beschreibung reportet Samba dadurch nur einen anderen Filesystemtyp
an anfragende Clients, nichts weiter:
fstype (S)
This parameter allows the administrator to configure the string that
specifies the type of filesystem a share is using that is reported by
smbd(8) when a client queries the filesystem type for a share. The
default type is NTFS for compatibility with Windows NT but this can be
changed to other strings such as Samba or FAT if required.
Default: fstype = NTFS
Example: fstype = Samba
--
der tom
[fli4l-/eisfair-team]
Markus Benedikt
>Wer kann mir helfen? Wie kann ich erreichen, dass Samba die Uhrzeit der
>letzten Modifikation NICHT ändert?
Ich habe das Problem gelöst. Statt Secondcopy verwende ich nunmehr SyncBack
auf der Windows Maschine. Damit ist man der Lage eine zulässige Abweichung
beim "Modification Timestamp" in Sekunden anzugeben. Damit gehts dann wie
gewünscht. Auch sonst bietet das Programm eine Fülle von Optionen, die
SecondCopy und kein anderes Programm bietet. Falls jemand Interesse hat,
der schaut hier hin:
Markus Benedikt
>setze den Parameter von Hand im entsprechenden Share-Abschnitt der
>smb.conf und prüfe, ob es tatsächlich einen Unterschied macht.
>Laut Beschreibung reportet Samba dadurch nur einen anderen Filesystemtyp
>an anfragende Clients, nichts weiter:
>
>fstype (S)
>
> Default: fstype = NTFS
> Example: fstype = Samba
Hatte ich probiert, macht keinen Unterschied. Die Modification Time ist
differiert trotzdem. Aber danke für den Tipp, ich habe inzwischen die
für mich optimale Lösung gefunden.