I am not sure if I have enough technical knowledge to frame this question properly but I will try!
I have an HP Proliant Microserver Gen 8 with a Xeon CPU running Linux Mint xfce 21.3 acting as a home media server feeding media mainly to my NVidia TV Show.
I back it up nightly to my Windows 10 server using a Widows app, SmartSync Pro.
Last night for some reason it decided that all the file in the "Films" directory on the Linux machine were different to those on the Windows machine so it churned way deleting each file on the Windows machine and replacing it with an identical file from the Linux machine :-(
It's about 2 TB of data and would still be running if I hadn't stopped it.
I haven't knowingly changed anything on either machine, Linux is ext4 and Windows exFat FS.
Can anybody suggest why this might have happened or what I need to investigate please?
Last night for some reason it decided that all the file in the
"Films" directory on the Linux machine were different to those on
the Windows machine so it churned way deleting each file on the
Windows machine and replacing it with an identical file from the
Linux machine :-(
Jeff Gaines wrote:
Last night for some reason it decided that all the file in the
"Films" directory on the Linux machine were different to those on
the Windows machine so it churned way deleting each file on the
Windows machine and replacing it with an identical file from the
Linux machine :-(
Would you really trust Windows to preserve the integrity of your
important data?
On 22 Mar 2026 15:20:35 GMT, Jeff Gaines wrote:
Last night for some reason it decided that all the file in the
"Films" directory on the Linux machine were different to those on
the Windows machine so it churned way deleting each file on the
Windows machine and replacing it with an identical file from the
Linux machine :-(
Would you really trust Windows to preserve the integrity of your
important data?
On 22 Mar 2026 15:20:35 GMT, Jeff Gaines wrote:
Last night for some reason it decided that all the file in the
"Films" directory on the Linux machine were different to those on
the Windows machine so it churned way deleting each file on the
Windows machine and replacing it with an identical file from the
Linux machine :-(
Would you really trust Windows to preserve the integrity of your
important data?
On Sun, 22 Mar 2026 20:58:06 -0000 (UTC), Lawrence D’Oliveiro wrote:
On 22 Mar 2026 15:20:35 GMT, Jeff Gaines wrote:
Last night for some reason it decided that all the file in the
"Films" directory on the Linux machine were different to those on
the Windows machine so it churned way deleting each file on the
Windows machine and replacing it with an identical file from the
Linux machine :-(
Would you really trust Windows to preserve the integrity of your
important data?
I have since the early 90's when I chose Windows over Slackware or
OS/2 Warp so yes.
On 22 Mar 2026 21:59:40 GMT, Jeff Gaines wrote:
On Sun, 22 Mar 2026 20:58:06 -0000 (UTC), Lawrence D’Oliveiro wrote:
On 22 Mar 2026 15:20:35 GMT, Jeff Gaines wrote:
Last night for some reason it decided that all the file in the
"Films" directory on the Linux machine were different to those on
the Windows machine so it churned way deleting each file on the
Windows machine and replacing it with an identical file from the
Linux machine :-(
Would you really trust Windows to preserve the integrity of your
important data?
I have since the early 90's when I chose Windows over Slackware or
OS/2 Warp so yes.
Even after it has decided that a previous backup, which was supposed
to be valid, was not valid and needed to be redone?
He described a timestamp problem, so no information loss was
involved. Inefficient extra copying went on, because the process
thought the date on the file had changed (and it had changed, just
not for the expected reason).
On Sun, 22 Mar 2026 20:53:32 -0400, Paul wrote:
He described a timestamp problem, so no information loss was
involved. Inefficient extra copying went on, because the process
thought the date on the file had changed (and it had changed, just
not for the expected reason).
Loss of timestamp info on the previously-backed-up files *does* count
as “information loss”. Something corrupted that info on disk.
On Sun, 3/22/2026 9:30 PM, Lawrence D’Oliveiro wrote:
On Sun, 22 Mar 2026 20:53:32 -0400, Paul wrote:
He described a timestamp problem, so no information loss was
involved. Inefficient extra copying went on, because the process
thought the date on the file had changed (and it had changed, just
not for the expected reason).
Loss of timestamp info on the previously-backed-up files *does*
count as “information loss”. Something corrupted that info on disk.
It's not loss, it is interpretation. It's a design issue.
There is little reason for all files to be synced because
the software has detected a one hour difference (for example).
That could happen on FAT32 with the DST change.
On Sun, 3/22/2026 9:30 PM, Lawrence D’Oliveiro wrote:
On Sun, 22 Mar 2026 20:53:32 -0400, Paul wrote:
He described a timestamp problem, so no information loss was
involved. Inefficient extra copying went on, because the process
thought the date on the file had changed (and it had changed, just
not for the expected reason).
Loss of timestamp info on the previously-backed-up files *does* count
as “information loss”. Something corrupted that info on disk.
It's not loss, it is interpretation. It's a design issue.
There is little reason for all files to be synced because
the software has detected a one hour difference (for example).
That could happen on FAT32 with the DST change.
When two systems systems do not share up-to-date TZINFO, there can be artificial changes that way. I have occasionally seen OSes I've booted
be off by an hour, and even when it is not a TZ change date.
You can see these cases in discussion threads Google throws up,
and in some of them, a "USB stick with FAT32" not mentioned
in the original question, is the culprit. FAT32 uses localtime,
EXFAT uses UTC apparently, but with different granularity
than NTFS.
You have to put on your timelord hat and start searching
around for the source of the mis-interpretation.
On 2026-03-23 02:59, Paul wrote:
On Sun, 3/22/2026 9:30 PM, Lawrence D’Oliveiro wrote:
On Sun, 22 Mar 2026 20:53:32 -0400, Paul wrote:
He described a timestamp problem, so no information loss was
involved. Inefficient extra copying went on, because the process
thought the date on the file had changed (and it had changed, just
not for the expected reason).
Loss of timestamp info on the previously-backed-up files *does* count
as “information loss”. Something corrupted that info on disk.
It's not loss, it is interpretation. It's a design issue.
There is little reason for all files to be synced because
the software has detected a one hour difference (for example).
That could happen on FAT32 with the DST change.
When two systems systems do not share up-to-date TZINFO, there can be
artificial changes that way. I have occasionally seen OSes I've booted
be off by an hour, and even when it is not a TZ change date.
You can see these cases in discussion threads Google throws up,
and in some of them, a "USB stick with FAT32" not mentioned
in the original question, is the culprit. FAT32 uses localtime,
EXFAT uses UTC apparently, but with different granularity
than NTFS.
You have to put on your timelord hat and start searching
around for the source of the mis-interpretation.
Arguably, that software is not saving the metadata of the Linux files correctly. The time stamping on the Windows machine should be irrelevant. For each Linux file, the software should store separately the file itself, and the original metadata somewhere else, because Windows can not store Linux filesystem metadata. And if that metadata is stored separately, there can not be interpretation errors about the timestamp later, even if the TZ or DST change later.
My guess is that the software is storing the Linux files as Windows files, so attributes and metadata get lost. Which may be irrelevant, if all they are are movies. But if it is a system backup, then important metadata will be lost. Also symlinks, hardlinks, sparse files, etc.
One thing we learn about calibrating backup software, is the need to
use multiple methods and compare what is happening with all of them.
In an attempt to spot inconsistency.
One of the problems I've been working on for some time, is the
incompleteness of file listing programs.
On 22 Mar 2026 21:59:40 GMT, Jeff Gaines wrote:
On Sun, 22 Mar 2026 20:58:06 -0000 (UTC), Lawrence D’Oliveiro wrote:
On 22 Mar 2026 15:20:35 GMT, Jeff Gaines wrote:
Last night for some reason it decided that all the file in the
"Films" directory on the Linux machine were different to those on
the Windows machine so it churned way deleting each file on the
Windows machine and replacing it with an identical file from the
Linux machine :-(
Would you really trust Windows to preserve the integrity of your >>>important data?
I have since the early 90's when I chose Windows over Slackware or
OS/2 Warp so yes.
Even after it has decided that a previous backup, which was supposed
to be valid, was not valid and needed to be redone?
On Sun, 3/22/2026 7:57 PM, Lawrence D’Oliveiro wrote:
On 22 Mar 2026 21:59:40 GMT, Jeff Gaines wrote:
On Sun, 22 Mar 2026 20:58:06 -0000 (UTC), Lawrence D’Oliveiro wrote:
On 22 Mar 2026 15:20:35 GMT, Jeff Gaines wrote:
Last night for some reason it decided that all the file in the >>>>>"Films" directory on the Linux machine were different to those on
the Windows machine so it churned way deleting each file on the >>>>>Windows machine and replacing it with an identical file from the >>>>>Linux machine :-(
Would you really trust Windows to preserve the integrity of your >>>>important data?
I have since the early 90's when I chose Windows over Slackware or
OS/2 Warp so yes.
Even after it has decided that a previous backup, which was supposed
to be valid, was not valid and needed to be redone?
He described a timestamp problem, so no information loss was involved. >Inefficient extra copying went on, because the process thought the
date on the file had changed (and it had changed, just not for the
expected reason).
Since he stopped the session, there should still be some evidence to
look at.
This might make a good question for the AI, such as
Doing a file backup from LM213 EXT4 to Win2K FAT32.
What things could go wrong to cause a mistaken timestamp
change detection ?
And the AI can scrape the training set for
cases where time changed when it should not have.
The backup scheme in this case, involves a satellite agent
and a serving task on another machine. It should have been
possible to parse conditions on each end of this backup
and do the right thing.
I would be checking the settings on the "App" to see
if it mentions anything about "timestamp corner condition detection".
Paul
On 23/03/2026 in message <10pq2uc$3occt$1@dont-email.me> Paul wrote:
On Sun, 3/22/2026 7:57 PM, Lawrence D’Oliveiro wrote:
On 22 Mar 2026 21:59:40 GMT, Jeff Gaines wrote:
On Sun, 22 Mar 2026 20:58:06 -0000 (UTC), Lawrence D’Oliveiro wrote:
On 22 Mar 2026 15:20:35 GMT, Jeff Gaines wrote:
Last night for some reason it decided that all the file in the >>>>>>"Films" directory on the Linux machine were different to those on >>>>>>the Windows machine so it churned way deleting each file on the >>>>>>Windows machine and replacing it with an identical file from the >>>>>>Linux machine :-(
Would you really trust Windows to preserve the integrity of your >>>>>important data?
I have since the early 90's when I chose Windows over Slackware or
OS/2 Warp so yes.
Even after it has decided that a previous backup, which was supposed
to be valid, was not valid and needed to be redone?
He described a timestamp problem, so no information loss was involved. >>Inefficient extra copying went on, because the process thought the
date on the file had changed (and it had changed, just not for the
expected reason).
Since he stopped the session, there should still be some evidence to
look at.
This might make a good question for the AI, such as
Doing a file backup from LM213 EXT4 to Win2K FAT32.
What things could go wrong to cause a mistaken timestamp
change detection ?
And the AI can scrape the training set for
cases where time changed when it should not have.
The backup scheme in this case, involves a satellite agent
and a serving task on another machine. It should have been
possible to parse conditions on each end of this backup
and do the right thing.
I would be checking the settings on the "App" to see
if it mentions anything about "timestamp corner condition detection".
Paul
Excellent question, Paul, thank you :-)
Answer:
Moving files from EXT4 (Linux native) to exFAT (portable file system)
often causes mistaken timestamp changes due to fundamental differences in >how these file systems handle time precision, time zones, and metadata.
When backup software compares the files, these differences can make >identical files appear to have been modified.
Here are the primary things that could go wrong to cause a mistaken >timestamp change detection:
1. Timestamp Resolution Mismatch (Rounding Errors)
The Problem: EXT4 supports nanosecond-level timestamp precision. exFAT, >however, has a 2-second resolution for file modification times (rounding
up or down).
The Mistake: If a file on EXT4 was last modified at 10:00:01, it might be >rounded to 10:00:00 or 10:00:02 on exFAT.
Detection Result: When a backup tool (like rsync or FreeFileSync) re-scans >the files, it sees a 1-second difference and incorrectly concludes the
file has changed, causing an unnecessary re-copy.
I will try my alternative backup app and if that has the same problem I >could change the destination FS to NTFS and see how that goes. In the dim >and distant past I stopped using SmartSync for network backup, perhaps I >have re-discovered why.
On Sun, 3/22/2026 10:35 PM, Carlos E.R. wrote:
On 2026-03-23 02:59, Paul wrote:
On Sun, 3/22/2026 9:30 PM, Lawrence D’Oliveiro wrote:
On Sun, 22 Mar 2026 20:53:32 -0400, Paul wrote:
He described a timestamp problem, so no information loss was
involved. Inefficient extra copying went on, because the process
thought the date on the file had changed (and it had changed, just
not for the expected reason).
Loss of timestamp info on the previously-backed-up files *does* count
as “information loss”. Something corrupted that info on disk.
It's not loss, it is interpretation. It's a design issue.
There is little reason for all files to be synced because
the software has detected a one hour difference (for example).
That could happen on FAT32 with the DST change.
When two systems systems do not share up-to-date TZINFO, there can be
artificial changes that way. I have occasionally seen OSes I've booted
be off by an hour, and even when it is not a TZ change date.
You can see these cases in discussion threads Google throws up,
and in some of them, a "USB stick with FAT32" not mentioned
in the original question, is the culprit. FAT32 uses localtime,
EXFAT uses UTC apparently, but with different granularity
than NTFS.
You have to put on your timelord hat and start searching
around for the source of the mis-interpretation.
Arguably, that software is not saving the metadata of the Linux files correctly. The time stamping on the Windows machine should be irrelevant. For each Linux file, the software should store separately the file itself, and the original metadata somewhere else, because Windows can not store Linux filesystem metadata. And if that metadata is stored separately, there can not be interpretation errors about the timestamp later, even if the TZ or DST change later.
My guess is that the software is storing the Linux files as Windows files, so attributes and metadata get lost. Which may be irrelevant, if all they are are movies. But if it is a system backup, then important metadata will be lost. Also symlinks, hardlinks, sparse files, etc.
https://www.2brightsparks.com/syncback/help/profeatures.htm?srsltid=AfmBOorAVDr3ASLAZGzZUuju4aBi34LQzlddH28yrmtuyxjmpyhvo4z5
"SyncBackPro uses a database to store details of the files it is copying,"
I think that means, when doing something in the incremental sense, the satellite software that sweeps a foreign computer, it is going to
forward information in some format local to it, and that has
to be compared to what is in the database. The database is loaded
with metadata also obtained from the format local to the remote machine.
If the handing on the remote machine does not have good temporal integrity, the problem may start on the foreign end.
*******
One thing we learn about calibrating backup software, is the need
to use multiple methods and compare what is happening with all of them.
In an attempt to spot inconsistency.
You might need, say, a directory listing from before the time change.
Wed, 09/17/2025 03:59 PM 255,125 zenity-dialog-02.png
Wed, 09/17/2025 04:05 PM 95,679 zenity-dialog.gif
Wed, 09/17/2025 03:34 PM 225,469 zenity-dialog.png
Then today, we check them again. Are they the same ?
Well, one problem would be, that the OS you're observing that with,
could have the same problem as the backup is seeing. Or, you would
hope so, if trying to detect an errant time change.
One of the problems I've been working on for some time, is the
incompleteness of file listing programs. Rather than anything
to do with datestamps. I don't keep file lists here as an
integrity check, rather most of the files I keep they have
lists of filenames (basically, to see if there will ever be
a method that lists everything). I'm not even set up, not
on any platform, for time-related issues. And that also means,
I'm more likely to have not recommended to people that they
keep ls -algtR listings as a means of detecting some sort of
modification. I would be more likely to be using hashdeep for that
(looking for content changes).
For the SyncBack software, you'd want to look inside the database
it keeps, to see the date information kept there. Presumably if
you were restoring, various versions of files should be listed,
along with their (foreign collected) datestamp information.
It's also possible that Jeff is in a place where there are
two timezones, and occasionally the wrong time zone is set
on an OS in the location department. Or, some software is
not aware there are two timezones. That would be for local time determination.
Moving files from EXT4 (Linux native) to exFAT (portable file system)
often causes mistaken timestamp changes due to fundamental differences
in how these file systems handle time precision, time zones, and
metadata. When backup software compares the files, these differences can
make identical files appear to have been modified.
Here are the primary things that could go wrong to cause a mistaken
timestamp change detection:
1. Timestamp Resolution Mismatch (Rounding Errors)
The Problem: EXT4 supports nanosecond-level timestamp precision. exFAT, however, has a 2-second resolution for file modification times (rounding
up or down).
The Mistake: If a file on EXT4 was last modified at 10:00:01, it might
be rounded to 10:00:00 or 10:00:02 on exFAT.
Detection Result: When a backup tool (like rsync or FreeFileSync) re-
scans the files, it sees a 1-second difference and incorrectly concludes
the file has changed, causing an unnecessary re-copy.
On 23/03/2026 in message <xn0pnm6mebcaaiz00q@news.individual.net> Jeff Gaines wrote:
On 23/03/2026 in message <10pq2uc$3occt$1@dont-email.me> Paul wrote:
On Sun, 3/22/2026 7:57 PM, Lawrence D’Oliveiro wrote:
On 22 Mar 2026 21:59:40 GMT, Jeff Gaines wrote:
On Sun, 22 Mar 2026 20:58:06 -0000 (UTC), Lawrence D’Oliveiro wrote: >>>>>
On 22 Mar 2026 15:20:35 GMT, Jeff Gaines wrote:
Last night for some reason it decided that all the file in the
"Films" directory on the Linux machine were different to those on >>>>>>> the Windows machine so it churned way deleting each file on the
Windows machine and replacing it with an identical file from the >>>>>>> Linux machine :-(
Would you really trust Windows to preserve the integrity of your
important data?
I have since the early 90's when I chose Windows over Slackware or
OS/2 Warp so yes.
Even after it has decided that a previous backup, which was supposed
to be valid, was not valid and needed to be redone?
He described a timestamp problem, so no information loss was involved.
Inefficient extra copying went on, because the process thought the
date on the file had changed (and it had changed, just not for the
expected reason).
Since he stopped the session, there should still be some evidence to
look at.
This might make a good question for the AI, such as
Doing a file backup from LM213 EXT4 to Win2K FAT32.
What things could go wrong to cause a mistaken timestamp
change detection ?
And the AI can scrape the training set for
cases where time changed when it should not have.
The backup scheme in this case, involves a satellite agent
and a serving task on another machine. It should have been
possible to parse conditions on each end of this backup
and do the right thing.
I would be checking the settings on the "App" to see
if it mentions anything about "timestamp corner condition detection".
Paul
Excellent question, Paul, thank you :-)
Answer:
Moving files from EXT4 (Linux native) to exFAT (portable file system) often causes mistaken timestamp changes due to fundamental differences in how these file systems handle time precision, time zones, and metadata. When backup software compares the files, these differences can make identical files appear to have been modified.
Here are the primary things that could go wrong to cause a mistaken timestamp change detection:
1. Timestamp Resolution Mismatch (Rounding Errors)
The Problem: EXT4 supports nanosecond-level timestamp precision. exFAT, however, has a 2-second resolution for file modification times (rounding up or down).
The Mistake: If a file on EXT4 was last modified at 10:00:01, it might be rounded to 10:00:00 or 10:00:02 on exFAT.
Detection Result: When a backup tool (like rsync or FreeFileSync) re-scans the files, it sees a 1-second difference and incorrectly concludes the file has changed, causing an unnecessary re-copy.
I will try my alternative backup app and if that has the same problem I could change the destination FS to NTFS and see how that goes. In the dim and distant past I stopped using SmartSync for network backup, perhaps I have re-discovered why.
To finalise in case anybody else has the issue and comes across this post:
SmartSync Pro 4 is excellent for Windows backup/sync, I have used it for years as you can see by the version number!
However, it seems to read the file date/time very precisely and for the reasons given above by AI decide a minuscule difference means a file has changed so synchronising from ext4 to exFAT would mean unnecessary copying.
SyncBackSE v7 is fine, I don't know if it reads the file date/time more or less accurately but I have just installed and run it (again an old version) and it has ONLY copied changed files.
Probably explains why I stopped using SmartSync before but I can't remember for sure.
Many thanks to all, especially Paul who was right on the button :-)
I have a mixed network, Linux, Windows and Mac, because it suits me
and does what I want it to do.
On 23 Mar 2026 08:42:00 GMT, Jeff Gaines wrote:
I have a mixed network, Linux, Windows and Mac, because it suits me
and does what I want it to do.
I’m sure it does. Use the most robust of them -- i.e. Linux -- as the >foundation for supporting the others. You don’t want to have
everything depending on the weakest link, do you?
And that includes backups.
On 23/03/2026 in message <10ps3bj$dnue$2@dont-email.me> Lawrence
DOliveiro wrote:
On 23 Mar 2026 08:42:00 GMT, Jeff Gaines wrote:
I have a mixed network, Linux, Windows and Mac, because it suits me
and does what I want it to do.
I’m sure it does. Use the most robust of them -- i.e. Linux -- as
the foundation for supporting the others. You don’t want to have everything depending on the weakest link, do you?
And that includes backups.
The backup regime has worked fine for years and produces what I want
in the format I want where I want it so I shan't change it. The
answer to "I have a Windows problem" isn't "Linux".
The answer to "I have a Windows problem" isn't "Linux".
SmartSync Pro 4 is excellent for Windows backup/sync, I have used it
for years as you can see by the version number!
However, it seems to read the file date/time very precisely and for
the reasons given above by AI decide a minuscule difference means a
file has changed so synchronising from ext4 to exFAT would mean
unnecessary copying.
SyncBackSE v7 is fine, I don't know if it reads the file date/time
more or less accurately but I have just installed and run it (again
an old version) and it has ONLY copied changed files.
On 23 Mar 2026 09:56:41 GMT, Jeff Gaines wrote:
SmartSync Pro 4 is excellent for Windows backup/sync, I have used it
for years as you can see by the version number!
However, it seems to read the file date/time very precisely and for
the reasons given above by AI decide a minuscule difference means a
file has changed so synchronising from ext4 to exFAT would mean
unnecessary copying.
SyncBackSE v7 is fine, I don't know if it reads the file date/time
more or less accurately but I have just installed and run it (again
an old version) and it has ONLY copied changed files.
What happens to your old backups when you switch to a different backup
app? Do you just throw them away?
On Mon, 3/23/2026 9:24 PM, Lawrence D’Oliveiro wrote:
What happens to your old backups when you switch to a different
backup app? Do you just throw them away?
Since it is a "sync", the target already "resembles" the source.
On 23 Mar 2026 09:56:41 GMT, Jeff Gaines wrote:
SmartSync Pro 4 is excellent for Windows backup/sync, I have used it
for years as you can see by the version number!
However, it seems to read the file date/time very precisely and for
the reasons given above by AI decide a minuscule difference means a
file has changed so synchronising from ext4 to exFAT would mean
unnecessary copying.
SyncBackSE v7 is fine, I don't know if it reads the file date/time
more or less accurately but I have just installed and run it (again
an old version) and it has ONLY copied changed files.
What happens to your old backups when you switch to a different backup
app? Do you just throw them away?
On 23 Mar 2026 22:00:41 GMT, Jeff Gaines wrote:
The answer to "I have a Windows problem" isn't "Linux".
As Microsoft deliberately makes its platform more and more hostile to
users who don’t want to give it more money, what else is there?
At 23 Mar 2026 22:00:41 GMT, "Jeff Gaines" <jgnewsid@outlook.com> wrote:
On 23/03/2026 in message <10ps3bj$dnue$2@dont-email.me> Lawrence
DOliveiro wrote:
On 23 Mar 2026 08:42:00 GMT, Jeff Gaines wrote:
I have a mixed network, Linux, Windows and Mac, because it suits me
and does what I want it to do.
I’m sure it does. Use the most robust of them -- i.e. Linux -- as
the foundation for supporting the others. You don’t want to have >>>everything depending on the weakest link, do you?
And that includes backups.
The backup regime has worked fine for years and produces what I want
in the format I want where I want it so I shan't change it. The
answer to "I have a Windows problem" isn't "Linux".
Hi Jeff,
It might be in "alt.os.linux" ;)
Seriously though: Lawrence is trying to give good advice,
he's just being a bit pushy about it.
Personally, I keep my first-level backups on a 4T USB-NVME drive
using timeshift, with that periodically rsynced to my
Synology Diskstation via NFS v4. The data is stored in a
RAID5 array using ext4.
Not all filesystems are created alike...the history of ext4
is worth considering.
https://en.wikipedia.org/wiki/Ext4
But! Use whatever works. :)
On Tue, 24 Mar 2026 01:24:03 -0000 (UTC), Lawrence D’Oliveiro wrote:
What happens to your old backups when you switch to a different
backup app? Do you just throw them away?
They are mirrors of the source so overwritten when there is a change
in the source. Kept on HD/SSD/NVMe with exFAT FS. I use my computers
like a Meccano set and if you move NTFS drives between machines you
run into all sort of permission problems.
...
(b) the process doesn't allow for previous versions so I discipline
myself that before I make changes to a Visual Studio project the
whole project is copied to a "hold" directory that I can go back to
when I screw things up.
You suffer such a crapulent backup regime, inflicted on you by the >limitations of the applications and platform software, and yet you
seem to think that is a normal way of doing things. It’s not.
On 24/03/2026 in message <10psnov$kqga$3@dont-email.me> Lawrence
DOliveiro wrote:
On 23 Mar 2026 22:00:41 GMT, Jeff Gaines wrote:
The answer to "I have a Windows problem" isn't "Linux".
As Microsoft deliberately makes its platform more and more hostile
to users who don’t want to give it more money, what else is there?
I use Windows for my day to day stuff because I am at home in it.
It's used by millions of people / companies world wide so must have
something going for it.
I use a Mac M1 to link to my Artinoise Re.corder because Artinoise concentrate on iOS for their app (and the Mac M1 runs iOS apps).
I use Linux to prepare iso files of DVDs and to act as my home media
server, it's new to me so I struggle at times but is works!
(b) the process doesn't allow for previous versions so I discipline
myself that before I make changes to a Visual Studio project the whole project is copied to a "hold" directory that I can go back to when I
screw things up.
Lawrence D’Oliveiro <ldo@nz.invalid> writes:
Jeff Gaines wrote:
Last night for some reason it decided that all the file in the
"Films" directory on the Linux machine were different to those on
the Windows machine so it churned way deleting each file on the
Windows machine and replacing it with an identical file from the
Linux machine :-(
Would you really trust Windows to preserve the integrity of your
important data?
A backup on Windows that actually exists is better than a backup on
Linux that doesn’t.
On Tue, 24 Mar 2026 01:01:20 -0000 (UTC), Lawrence D’Oliveiro wrote:
As Microsoft deliberately makes its platform more and more hostile
to users who don’t want to give it more money, what else is there?
I use Windows for my day to day stuff because I am at home in it.
It's used by millions of people / companies world wide so must have
something going for it.
On Tue, 24 Mar 2026 09:20:48 -0000 (UTC), Lawrence D’Oliveiro wrote:
You suffer such a crapulent backup regime, inflicted on you by the
limitations of the applications and platform software, and yet you
seem to think that is a normal way of doing things. It’s not.
I suggest you find yourself an advocacy group if there are any still
about.
I am not sure if I have enough technical knowledge to frame this question >properly but I will try!
I have an HP Proliant Microserver Gen 8 with a Xeon CPU running Linux Mint >xfce 21.3 acting as a home media server feeding media mainly to my NVidia
TV Show.
I back it up nightly to my Windows 10 server using a Widows app, SmartSync >Pro.
Last night for some reason it decided that all the file in the "Films" >directory on the Linux machine were different to those on the Windows >machine so it churned way deleting each file on the Windows machine and >replacing it with an identical file from the Linux machine :-(
It's about 2 TB of data and would still be running if I hadn't stopped it.
I haven't knowingly changed anything on either machine, Linux is ext4 and >Windows exFat FS.
Can anybody suggest why this might have happened or what I need to >investigate please?
On 22/03/2026 in message <xn0pnl2flaav11l00m@news.individual.net> Jeff Gaines wrote:
I am not sure if I have enough technical knowledge to frame this question properly but I will try!
I have an HP Proliant Microserver Gen 8 with a Xeon CPU running Linux Mint xfce 21.3 acting as a home media server feeding media mainly to my NVidia TV Show.
I back it up nightly to my Windows 10 server using a Widows app, SmartSync Pro.
Last night for some reason it decided that all the file in the "Films" directory on the Linux machine were different to those on the Windows machine so it churned way deleting each file on the Windows machine and replacing it with an identical file from the Linux machine :-(
It's about 2 TB of data and would still be running if I hadn't stopped it. >>
I haven't knowingly changed anything on either machine, Linux is ext4 and Windows exFat FS.
Can anybody suggest why this might have happened or what I need to investigate please?
In case anybody come across this in the future the problem was that there was a "link" on the Linux machine which Windows identified as a directory so instead of ignoring it it went down the rabbit hole and found pretty well the same files a second time but on a different path which had "link-to-TV-series" inserted in it.
Rectification is simple, deleted the link IN LINUX, if you delete it from Windows it goes down the rabbit hole again. I lost a complete TV series and half another before I realised what it was doing, all restored now from backups.
On 22/03/2026 in message <xn0pnl2flaav11l00m@news.individual.net> Jeff Gaines wrote:
I am not sure if I have enough technical knowledge to frame this
question properly but I will try!
I have an HP Proliant Microserver Gen 8 with a Xeon CPU running Linux
Mint xfce 21.3 acting as a home media server feeding media mainly to
my NVidia TV Show.
I back it up nightly to my Windows 10 server using a Widows app,
SmartSync Pro.
Last night for some reason it decided that all the file in the "Films"
directory on the Linux machine were different to those on the Windows
machine so it churned way deleting each file on the Windows machine
and replacing it with an identical file from the Linux machine :-(
It's about 2 TB of data and would still be running if I hadn't stopped
it.
I haven't knowingly changed anything on either machine, Linux is ext4
and Windows exFat FS.
Can anybody suggest why this might have happened or what I need to
investigate please?
In case anybody come across this in the future the problem was that
there was a "link" on the Linux machine which Windows identified as a directory so instead of ignoring it it went down the rabbit hole and
found pretty well the same files a second time but on a different path
which had "link-to-TV-series" inserted in it.
Rectification is simple, deleted the link IN LINUX, if you delete it
from Windows it goes down the rabbit hole again. I lost a complete TV
series and half another before I realised what it was doing, all
restored now from backups.
On 2026-04-14 14:30, Jeff Gaines wrote:
On 22/03/2026 in message <xn0pnl2flaav11l00m@news.individual.net> Jeff Gaines wrote:
I am not sure if I have enough technical knowledge to frame this question properly but I will try!
I have an HP Proliant Microserver Gen 8 with a Xeon CPU running Linux Mint xfce 21.3 acting as a home media server feeding media mainly to my NVidia TV Show.
I back it up nightly to my Windows 10 server using a Widows app, SmartSync Pro.
Last night for some reason it decided that all the file in the "Films" directory on the Linux machine were different to those on the Windows machine so it churned way deleting each file on the Windows machine and replacing it with an identical file from the Linux machine :-(
It's about 2 TB of data and would still be running if I hadn't stopped it. >>>
I haven't knowingly changed anything on either machine, Linux is ext4 and Windows exFat FS.
Can anybody suggest why this might have happened or what I need to investigate please?
In case anybody come across this in the future the problem was that there was a "link" on the Linux machine which Windows identified as a directory so instead of ignoring it it went down the rabbit hole and found pretty well the same files a second time but on a different path which had "link-to-TV-series" inserted in it.
Rectification is simple, deleted the link IN LINUX, if you delete it from Windows it goes down the rabbit hole again. I lost a complete TV series and half another before I realised what it was doing, all restored now from backups.
Well, you got that problem because you are using Windows to back up Linux. Just use Linux to back up Linux. No such problems.
And that's slightly different than Windows. In Windows, the partitions
tend to stop at C: , D: , E: and so on. Going "above" that point, does not >usually make sense. There are a few issues with "being at the top", such
as having to manually insert the correct formatting in ICACLS for the >permissions
for the very very top of C: . The software does not index that properly, or >at least it did not in the past. There was no reason for them to fix that, >yet it has to be fixed if you needed to do "permissions playback" later.
Whereas with Linux, things start with / , and if you're not careful
when traversing the tree, you can end up going places you had not intended. >It takes a little more attention to detail, when working with / .
If a command has an exclude capability, you can carve around things
you don't want.
On Tue, 4/14/2026 9:51 AM, Carlos E.R. wrote:
On 2026-04-14 14:30, Jeff Gaines wrote:
On 22/03/2026 in message <xn0pnl2flaav11l00m@news.individual.net> Jeff Gaines wrote:
I am not sure if I have enough technical knowledge to frame this question properly but I will try!
I have an HP Proliant Microserver Gen 8 with a Xeon CPU running Linux Mint xfce 21.3 acting as a home media server feeding media mainly to my NVidia TV Show.
I back it up nightly to my Windows 10 server using a Widows app, SmartSync Pro.
Last night for some reason it decided that all the file in the "Films" directory on the Linux machine were different to those on the Windows machine so it churned way deleting each file on the Windows machine and replacing it with an identical file from the Linux machine :-(
It's about 2 TB of data and would still be running if I hadn't stopped it. >>>>
I haven't knowingly changed anything on either machine, Linux is ext4 and Windows exFat FS.
Can anybody suggest why this might have happened or what I need to investigate please?
In case anybody come across this in the future the problem was that there was a "link" on the Linux machine which Windows identified as a directory so instead of ignoring it it went down the rabbit hole and found pretty well the same files a second time but on a different path which had "link-to-TV-series" inserted in it.
Rectification is simple, deleted the link IN LINUX, if you delete it from Windows it goes down the rabbit hole again. I lost a complete TV series and half another before I realised what it was doing, all restored now from backups.
Well, you got that problem because you are using Windows to back up Linux. Just use Linux to back up Linux. No such problems.
You can back up Linux with Windows.
You can back up Windows with Linux.
In case anybody come across this in the future the problem was that
there was a "link" on the Linux machine which Windows identified as
a directory so instead of ignoring it it went down the rabbit hole
and found pretty well the same files a second time but on a
different path which had "link-to-TV-series" inserted in it.
You can back up Linux with Windows.
You can back up Windows with Linux.
This sort of issue affects applications such as "hashdeep64" when
you attempt to generate a hash for every file on C: . It does not
affect backup software, because the backup software typically works
at the cluster or inode level. The file system is analyzed at the
file level, when it is desired to make a list of file names for
later, but the actual read operations for content, are done on
clusters ...
On 14 Apr 2026 12:30:56 GMT, Jeff Gaines wrote:
In case anybody come across this in the future the problem was that
there was a "link" on the Linux machine which Windows identified as
a directory so instead of ignoring it it went down the rabbit hole
and found pretty well the same files a second time but on a
different path which had "link-to-TV-series" inserted in it.
Were you exporting your filesystem to Windows via Samba? Did you have
Samba configured to follow symlinks?
On Tue, 14 Apr 2026 09:51:16 -0400, Paul wrote:
This sort of issue affects applications such as "hashdeep64" when
you attempt to generate a hash for every file on C: . It does not
affect backup software, because the backup software typically works
at the cluster or inode level. The file system is analyzed at the
file level, when it is desired to make a list of file names for
later, but the actual read operations for content, are done on
clusters ...
Is this why Windows users are so fixated on all-or-nothing “image” >backups? On Linux, file-level backups, such as you would do with
rsync, are just that much more flexible.
On 14/04/2026 in message <10rmda9$fdsi$3@dont-email.me> Lawrence DOliveiro wrote:
On Tue, 14 Apr 2026 09:51:16 -0400, Paul wrote:
This sort of issue affects applications such as "hashdeep64" when
you attempt to generate a hash for every file on C: . It does not
affect backup software, because the backup software typically works
at the cluster or inode level. The file system is analyzed at the
file level, when it is desired to make a list of file names for
later, but the actual read operations for content, are done on
clusters ...
Is this why Windows users are so fixated on all-or-nothing “image”
backups? On Linux, file-level backups, such as you would do with
rsync, are just that much more flexible.
To me that is for different reasons. Windows needs a product key and activation and so do MSFT apps like Office. I used to install, activate, image then if I needed to re-install I just restore the image with everything activated.
I don't keep data on the OS drive in Windows, it's on a separate drive (or partition), D:\Data, and that's backed up as files so when I screw up I can easily grab the previous version from a backup.
On 14/04/2026 in message <10rmd4m$fdsi$1@dont-email.me> Lawrence DOliveiro wrote:
On 14 Apr 2026 12:30:56 GMT, Jeff Gaines wrote:
In case anybody come across this in the future the problem was that
there was a "link" on the Linux machine which Windows identified as
a directory so instead of ignoring it it went down the rabbit hole
and found pretty well the same files a second time but on a
different path which had "link-to-TV-series" inserted in it.
Were you exporting your filesystem to Windows via Samba? Did you have
Samba configured to follow symlinks?
I have Samba installed on Linux and wssd (from memory) so Windows File Explorer can see the Linux machine.
I followed online instructions to configure Samba, didn't see anything relating to symlinks.
On Tue, 14 Apr 2026 11:01:48 -0400, Paul wrote:
You can back up Linux with Windows.
That can lead to problems like what occurred in this case.
You can back up Windows with Linux.
This will usually be more reliable. The file-handling tools on Linux
are just that much more robust.
On 2026-04-14 23:56, Lawrence D’Oliveiro wrote:
On Tue, 14 Apr 2026 11:01:48 -0400, Paul wrote:
You can back up Linux with Windows.
That can lead to problems like what occurred in this case.
You can back up Windows with Linux.
This will usually be more reliable. The file-handling tools on Linux
are just that much more robust.
Linux doesn't see all the Windows file attributes, they can not be mapped to Linux. Like "system". You can see and save them with "mtools".
Windows doesn't "need" a product key and activation.
Windows installations today are "infinite grace period".
The only thing you lose by not performing any ceremonies
of that type, is the "Personalize" menu is not available.
And you can set a background image for your desktop
from File Manager, from the right-click menu. That's
about all I want out of Personalize.
Windows backups have a "mount option" (which as of three hours ago, after >Windows Update, just broke, something else for me to fix). You can
mount a Ghost, mount an Acronis TIH backup file, mount a Macrium .mrimg
and copy out individual files or folders, as you please. It's the
best of both worlds. You can restore an entire disk image to a new
disk drive (after a hardware failure). Or, if you deleted your Notes.txt
file by accident, you can mount the backup and fetch out the file you >captured yesterday in the backup.
On 15/04/2026 in message <10rnjlm$p7pp$1@dont-email.me> Paul wrote:
Windows doesn't "need" a product key and activation.
Windows installations today are "infinite grace period".
The only thing you lose by not performing any ceremonies
of that type, is the "Personalize" menu is not available.
And you can set a background image for your desktop
from File Manager, from the right-click menu. That's
about all I want out of Personalize.
That is true of Win 10 on, some of my machines run 8.1 and in any event it doesn't cover Office etc. or the annoyance of Windows reverting to a black background when you log on an un-activated PC. There are sound reasons why Windows users do it as I have explained
Windows backups have a "mount option" (which as of three hours ago, after
Windows Update, just broke, something else for me to fix). You can
mount a Ghost, mount an Acronis TIH backup file, mount a Macrium .mrimg
and copy out individual files or folders, as you please. It's the
best of both worlds. You can restore an entire disk image to a new
disk drive (after a hardware failure). Or, if you deleted your Notes.txt
file by accident, you can mount the backup and fetch out the file you
captured yesterday in the backup.
You think I should go to all that trouble instead of just backing my files up incrementally?
On 15/04/2026 in message <10rnjlm$p7pp$1@dont-email.me> Paul wrote:
Windows doesn't "need" a product key and activation.
Windows installations today are "infinite grace period".
The only thing you lose by not performing any ceremonies
of that type, is the "Personalize" menu is not available.
And you can set a background image for your desktop
from File Manager, from the right-click menu. That's
about all I want out of Personalize.
That is true of Win 10 on, some of my machines run 8.1 and in any event
it doesn't cover Office etc. or the annoyance of Windows reverting to a black background when you log on an un-activated PC.
On 15/04/2026 10:31 pm, Jeff Gaines wrote:
On 15/04/2026 in message <10rnjlm$p7pp$1@dont-email.me> Paul wrote:
Windows doesn't "need" a product key and activation.
Windows installations today are "infinite grace period".
The only thing you lose by not performing any ceremonies
of that type, is the "Personalize" menu is not available.
And you can set a background image for your desktop
from File Manager, from the right-click menu. That's
about all I want out of Personalize.
That is true of Win 10 on, some of my machines run 8.1 and in any event >>it doesn't cover Office etc. or the annoyance of Windows reverting to a >>black background when you log on an un-activated PC.
AH!! Is that why my Win-11, which used to be colourful, is now Black!!
(for the last month or so)
On Wed, 4/15/2026 8:31 AM, Jeff Gaines wrote:
On 15/04/2026 in message <10rnjlm$p7pp$1@dont-email.me> Paul wrote:
Windows doesn't "need" a product key and activation.
Windows installations today are "infinite grace period".
The only thing you lose by not performing any ceremonies
of that type, is the "Personalize" menu is not available.
And you can set a background image for your desktop
from File Manager, from the right-click menu. That's
about all I want out of Personalize.
That is true of Win 10 on, some of my machines run 8.1 and in any event it >>doesn't cover Office etc. or the annoyance of Windows reverting to a black >>background when you log on an un-activated PC. There are sound reasons why >>Windows users do it as I have explained
Windows backups have a "mount option" (which as of three hours ago, after >>>Windows Update, just broke, something else for me to fix). You can
mount a Ghost, mount an Acronis TIH backup file, mount a Macrium .mrimg >>>and copy out individual files or folders, as you please. It's the
best of both worlds. You can restore an entire disk image to a new
disk drive (after a hardware failure). Or, if you deleted your Notes.txt >>>file by accident, you can mount the backup and fetch out the file you >>>captured yesterday in the backup.
You think I should go to all that trouble instead of just backing my files >>up incrementally?
My point is, that "files are not trapped, in monolithic backup files".
That's a tick box feature, the ability to do random access, and
people take that feature tick box into account, when selecting
backup softwares.
This is handy for "coincidental situations", where your hand crafted
custom tiddly backup missed a certain thing, and you're wracking
your brain to find a copy. That's partially what that tick box
feature is for. Nobody wants to restore a 2TB backup to pull out
a 100KB Notes.txt file.
I pull stuff out of VHD files. I even mount VHD files and
defragment or zero out white space, at host level. These are
all "side channels" available to you, and useful for the
odd work flow.
The VHDX file format, is less useful, as tools like 7ZIP can't
open those (that I know of). 7ZIP opens a lot of content
(it can open the .docx you wrote and extract the pictures
from it). 7ZIP doesn't open a .mrimg or a .tib, as those
are proprietary and not work the devs time to include.
Having random access to backup files, is just another feature.
Handy for times when you forgot to do something.
Paul
I followed online instructions to configure Samba, didn't see
anything relating to symlinks.
On 15 Apr 2026 07:40:25 GMT, Jeff Gaines wrote:
I followed online instructions to configure Samba, didn't see
anything relating to symlinks.
Samba has options in places where Windows Server doesn’t have places.
<https://manpages.debian.org/smb.conf(5)>
On Wed, 15 Apr 2026 22:18:30 -0000 (UTC), Lawrence D’Oliveiro wrote:
On 15 Apr 2026 07:40:25 GMT, Jeff Gaines wrote:
I followed online instructions to configure Samba, didn't see
anything relating to symlinks.
Samba has options in places where Windows Server doesn’t have
places.
<https://manpages.debian.org/smb.conf(5)>
It says:
This option is enabled (i.e. smbd will follow symbolic links) by
default.
Default: follow symlinks = yes
Problem is it doesn't tell me where to put that so I can set it to
"no".
On 16 Apr 2026 07:38:23 GMT, Jeff Gaines wrote:
On Wed, 15 Apr 2026 22:18:30 -0000 (UTC), Lawrence D’Oliveiro wrote:
On 15 Apr 2026 07:40:25 GMT, Jeff Gaines wrote:
I followed online instructions to configure Samba, didn't see
anything relating to symlinks.
Samba has options in places where Windows Server doesn’t have
places.
<https://manpages.debian.org/smb.conf(5)>
It says:
This option is enabled (i.e. smbd will follow symbolic links) by
default.
Default: follow symlinks = yes
Problem is it doesn't tell me where to put that so I can set it to
"no".
Put in an explicit value for that option, and it will override the
default.
On Thu, 16 Apr 2026 07:55:11 -0000 (UTC), Lawrence D’Oliveiro wrote:
Put in an explicit value for that option, and it will override the
default.
Does it matter what sections it is in?
On 16 Apr 2026 08:40:47 GMT, Jeff Gaines wrote:
On Thu, 16 Apr 2026 07:55:11 -0000 (UTC), Lawrence D’Oliveiro wrote:
Put in an explicit value for that option, and it will override the >>>default.
Does it matter what sections it is in?
The man page tells you where each directive goes, by the little code
after the directive, e.g. “(G)” for [global]; “(S)” can be global >for
a default setting, selectively overridden by a per-share setting.
You haven't answered my point. You think it is easier to create an image and mount it than to just go to a file backup?
These are all examples of adhoc failures. And a person writing
scripts has to consider every possibility, when hacking together
such things. That's why I don't underestimate the degree of difficulty
of doing a good job.
On 15/04/2026 in message <10ro5u1$vtet$2@dont-email.me> Daniel70 wrote:
On 15/04/2026 10:31 pm, Jeff Gaines wrote:
On 15/04/2026 in message <10rnjlm$p7pp$1@dont-email.me> Paul wrote:
Windows doesn't "need" a product key and activation.
Windows installations today are "infinite grace period".
The only thing you lose by not performing any ceremonies
of that type, is the "Personalize" menu is not available.
And you can set a background image for your desktop
from File Manager, from the right-click menu. That's
about all I want out of Personalize.
That is true of Win 10 on, some of my machines run 8.1 and in any event it doesn't cover Office etc. or the annoyance of Windows reverting to a black background when you log on an un-activated PC.
AH!! Is that why my Win-11, which used to be colourful, is now Black!! (for the last month or so)
Do you like these new fashionable dark themes? I find the awful blurry white font on a black background impossible to read.
On 15/04/2026 in message <10ro5u1$vtet$2@dont-email.me> Daniel70 wrote:
On 15/04/2026 10:31 pm, Jeff Gaines wrote:
On 15/04/2026 in message <10rnjlm$p7pp$1@dont-email.me> Paul wrote:
Windows doesn't "need" a product key and activation.
Windows installations today are "infinite grace period".
The only thing you lose by not performing any ceremonies
of that type, is the "Personalize" menu is not available.
And you can set a background image for your desktop
from File Manager, from the right-click menu. That's
about all I want out of Personalize.
That is true of Win 10 on, some of my machines run 8.1 and in any
event it doesn't cover Office etc. or the annoyance of Windows
reverting to a black background when you log on an un-activated PC.
AH!! Is that why my Win-11, which used to be colourful, is now Black!!
(for the last month or so)
Do you like these new fashionable dark themes? I find the awful blurry
white font on a black background impossible to read.
I am willing to bet, that given the number of arguments
that rsync supports, that every single person in this
group has to admit that at least on one occasion they've
made a mistake using that. Smart people test things,
and assembling a good test bench is an even better
test of skill, than writing a script.
On 16/04/2026 in message <10rq4kv$1himd$1@dont-email.me> Lawrence DOliveiro wrote:
On 16 Apr 2026 07:38:23 GMT, Jeff Gaines wrote:
On Wed, 15 Apr 2026 22:18:30 -0000 (UTC), Lawrence D’Oliveiro wrote:
On 15 Apr 2026 07:40:25 GMT, Jeff Gaines wrote:
I followed online instructions to configure Samba, didn't see
anything relating to symlinks.
Samba has options in places where Windows Server doesn’t have
places.
<https://manpages.debian.org/smb.conf(5)>
It says:
This option is enabled (i.e. smbd will follow symbolic links) by
default.
Default: follow symlinks = yes
Problem is it doesn't tell me where to put that so I can set it to
"no".
Put in an explicit value for that option, and it will override the
default.
Does it matter what sections it is in? If I put it inside the section with the smb share details would that be OK?
I have deleted the symlink but prevention is better than cure :-)
On 16/04/2026 12:23 am, Jeff Gaines wrote:
On 15/04/2026 in message <10ro5u1$vtet$2@dont-email.me> Daniel70 wrote:"Dark themes"?? Sorry, I was referring to the Computer Desktop .... on which I then click various Icons dependant on what I want to do.
On 15/04/2026 10:31 pm, Jeff Gaines wrote:
On 15/04/2026 in message <10rnjlm$p7pp$1@dont-email.me> Paul wrote:
Windows doesn't "need" a product key and activation.
Windows installations today are "infinite grace period".
The only thing you lose by not performing any ceremonies
of that type, is the "Personalize" menu is not available.
And you can set a background image for your desktop
from File Manager, from the right-click menu. That's
about all I want out of Personalize.
That is true of Win 10 on, some of my machines run 8.1 and in any event it doesn't cover Office etc. or the annoyance of Windows reverting to a black background when you log on an un-activated PC.
AH!! Is that why my Win-11, which used to be colourful, is now Black!! (for the last month or so)
Do you like these new fashionable dark themes? I find the awful blurry white font on a black background impossible to read.
I am sure there are people who can write a correct script
on the first try. But the reason they can do that, is
they've already made all these mistakes and learned from
them. Imagine what their thoroughness index was, while
on that learning curve. How many "jeffs notes.txt" that
fell on the floor.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 1,113 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 492335:46:06 |
| Calls: | 14,238 |
| Files: | 186,312 |
| D/L today: |
3,562 files (1,160M bytes) |
| Messages: | 2,514,866 |
