When you transfer a dir of script/s & data-files to rPi from your PC, via USBstik, there's a problem, since the rPi has no RealTimeClock.
So the important abilty to 'evaluate' files by their recentcy is lost. It's a universal truth that you'll want to get the most-recent cup-of-coffee and not the 17th most-recent that you put-down. That's why stacks are used.
What algorithm do you use to solve this problem?
==TIA.
md5sum
I don't know why you relate that to not having a realtime clock.
First, you can set the time and keep it correct on the Pi using NTP. Second, you can copy files and retain their original date.
(e.g. using the -p or -a flag of cp)
I keep files that have multiple version in a version control system.
Or using rsync or using tar.
>
Doesn't work so good for binary files
Sure it does. They might not be diffs available, but it does keep track of multiple versions.
They don?t seem to be causing me any trouble.
chrony. ntp would do as well (assuming of course that you are on the net, or have a gps timing receiver plugged in). Otherwise you can set the time by hand with chrony, or even with just adjtimex.
It is the time stamp on the file which tells you what is the most recent version, is I presume what he means. And it is the RTC which linux uses to set the current time on bootup.
Or use rsync. Of course the rPi finding files that are 45 years in the future, according to the current time on the machine could well confuse the operating system.
Normally when you copy a directory via USBstick the timestamps will be transferred with the copy and the local time on the system is not relevant.
No, that does not matter to rsync. It only compares filetimes, not the system time.
But rsync sets the time and the permissions on the transfered file to be the same as on the source file.
It is the operating system (not rsync) that may have trouble if it finds files 45 years in the future, because it thinks it is still 1970.
I use NTP so that my Raspberry Pi cards keep the correct time. I believe you can buy an RTC card for the RPi as well.
Most version control systems simply store the entire binary file every time so one is no better off if you simply create a directory to hold all the different binary files.
You mean it's not Jan 01, 1970? I wonder where have I've been.
It sounds like you think the only relevant issue is storage space.
The operating system does not care about that.
The only problem that may occur is that one of those files is modified, then gets an old modification time, then copied back onto the USBstick and the user is confused to see such an old file on the stick, or it may fail to be copied back to the other system when "copy only newer files" is used as a synchronization method (i.e. not the rsync default)
But those issues can be easily avoided using NTP. I think the Pi image comes with ntpd and pool.ntp.org by default, but I always change that to use my own NTP servers.
The problem with NTP is you need a network connection and our troll (remember he's the guy asking the bizarre questions people can't help themselves from answering) doesn't have an internet connection. Except when he's trolling, then his net connection is real peachy.
He does not need an Internet connection. The machine he is transferring files to/from can provide NTP service.
No not really, as someone that has extensive Solidworks files/models/drawings etc I find that vcs (version control systems) very in-appropriate for the job. Now text files as in *.c *.h etc I would use vcs.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required