Question Windows 7 idiosyncrasies

[Face]

so there isnt a secret society?

Oh, there is. But if I'd tell you details, I'd have to kill you .

a quick bug report would make the problem known, but it wouldnt immediately fix the problem

This is what I meant with "patches welcome" reply. More often than not you have to give something in FOSS-projects to accelerate bug report processing beyond stagnation. And if it is only a patch proposing a quick fix...

 

[Urwumpe]

so there isnt a secret society?

It is all open society. The problem is finding non-C++ developers that can survive going downtown with C++-developers. There are cities I have seen, that are now considering restoring their city walls.

 

[Ghostrider]

It is all open society. The problem is finding non-C++ developers that can survive going downtown with C++-developers. There are cities I have seen, that are now considering restoring their city walls.

Can anyone survive going downtown with FORTH programmers? They happen to code the walls - brick by brick. :lol:

 

[JEL]

@Martins; Can you use robocopy as your copy/check program? It is in your default windows7 installation.

I use it to make backups of new files, and changed files.

You would still have to zip the directory of new files afterwards though, but maybe you can include such commands in the script.

A simple .bat script could look like this:

robocopy "C:\Orbiter" "C:\Orbiter\Backup" "*.*" /E /XC /XN /XO /V /TS /ETA /TEE
pause

This .bat script copies files only if they do not already exist in the destination-dir. Not exactly the script you're after, but if you type "robocopy /?" at the command-prompt you'll get all the variables.

There are some that only copies files of a certain age, newer than X days for example. That may be useful to only get the latest files copied.

Or maybe there are other variables that would suit your purpose even better.

Robocopy is a standard win7 program so you already have it.
And the .bat scripts I'm sure you already know how to make

It's a suggestion

 

[Ripley]

...if you type "robocopy /?" at the command-prompt you'll get all the variables....

It's actually "robocopy /???".

Mind you, Robocopy is indeed powerful, but has a nasty behaviour, when copying between different file systems. I use it everyday (not latest version) at work for backups (XP Pro -> Buffalo NAS with Linux), and i occasionally have many files tagged as "newer", therefore copied again, even if they haven't been touched in years.

Latest Robocopy versions include a /FFT flag to check for "file time-stamps granularity".

[ame="http://en.wikipedia.org/wiki/Robocopy"]Robocopy - Wikipedia, the free encyclopedia[/ame]

 

[JEL]

It's actually "robocopy /???".

On win7 1 ? is enough

Mind you, Robocopy is indeed powerful, but has a nasty behaviour, when copying between different file systems. I use it everyday (not latest version) at work for backups (XP Pro -> Buffalo NAS with Linux), and i occasionally have many files tagged as "newer", therefore copied again, even if they haven't been touched in years.

I'm guessing it's because you use a variable that checks for the 'wrong' type of date. In win7 there are a bunch of different dates you can check for, and they don't all behave logically. For example, the date-accessed can be older than the date-modified, which is illogical in my view (how do you modify something you don't access, makes no sense to me), but apparently logical win7 behavior none-the-less.

I'm only using it on win7 though, so I don't have cross-platform experience with it.

 

[Ripley]

...I'm guessing it's because you use a variable that checks for the 'wrong' type of date...

I guess it's because different file systems store different file date/time parameters.
It's a problem of different platforms' file date/time "granularity".

An old but interesting read:
http://www.xxcopy.com/xxcopy15.htm

Anyway, I'll have another look at Robocopy's switches
http://ss64.com/nt/robocopy.html

 

[JEL]

@Ripley; I use robocopy to sync files from NTFS drives (harddrives) to FAT drives (smart-media cards) and that seems to work correctly.

It's all done on win7 x64 though, so the files are never touched/updated/modified by a 32 bit system (like for example a 32 bit winXP or Linux system).

I suspect that in your work-case that could perhaps be an issue. If the Linux system you backup files to runs a file-scan or something similar and then updates its file-tables, on the files originally dated by winXP, to reflect what Linux believes is the correct date-structure. I don't know if that's a possible scenario though. I have no experience with Linux.

Some experimentation with robocopy is probably the only way to find out what will work best for you in your particular setup

 

[orb]

I use robocopy to sync files from NTFS drives (harddrives) to FAT drives (smart-media cards) and that seems to work correctly.

It's all done on win7 x64 though, so the files are never touched/updated/modified by a 32 bit system (like for example a 32 bit winXP or Linux system).

I suspect that in your work-case that could perhaps be an issue.

Copying files on Linux preserves file modification timestamps which should only be compared, and files copied to FAT show the same modification time in Linux and Windows for me (but it was 64-bit Linux, and 32-bit Windows XP).

The NTFS file system stores time values in UTC format, so they are not affected by changes in time zone or daylight saving time. The FAT file system stores time values based on the local time of the computer. (taken from http://msdn.microsoft.com/en-us/library/windows/desktop/ms724290.aspx)

Additionally, file times on FAT file systems have 2-second resolution, while on NTFS it's 100-nanosecond. Those resolutions are the same on 32-bit or 64-bit Windows or Linux systems.

I can see there only 2 or 3 problems that can occur while comparing file times of copies of the same file stored on different filesystems: rounding the time to the nearest 2 seconds, or different timezones where those files are compared (or changes between DST and non-DST). The eventual 3rd problem is file modification time being updated after file copy (i.e. not being restored to the original one after target file has been closed).