| From: | Lee Bosch |
| Date: | 11 Mar 2001 at 16:53:14 |
| Subject: | [D5] Re: How to copy with clone |
***WARNING***
This is a long-winded message that perhaps should have been directed to Dave
Clarke. If you're sick and tired of this thread, I apologize for posting
it to this mailing list.
***WARNING***
Hello Dave
On 10-Mar-01, you wrote:
>> The help file that I have doesn't mention what the flags represent;
>> simply
>> that they are called "attributes" as opposed to "Datestamp", "Protection
>> Bits" and "Comment" (filenote).
>
> Also copy source's:
> When set, these attributes of the original are to be copied as well as
> the file itself.
>
> It needs no other explanation, it's telling you that it will set the 'new'
> file's attributes to the same as the original file depending on what items
> you have set.
I suppose that if the relationship between "attributes" and the Date
Stamp, Protection Bits and Comment (filenote) have already been widely
established, this might be a valid connection. I submit that this is a
reasonably huge leap for someone who is searching for how to preserve the
"datestamp", "protection bits" and "filenote". When I went searching for
the reference so that I may pass it along, I tried the following steps:
1. Help->Copy -- no reference
2. Help->Environment->Copy -- ambiguous reference to attributes
3. Environment->Copy -- ah! words that I recognize
> What the items are, (in this case 3 of them but it could as easily be 1934
> different file attributes.... if that many existed), are of secondary
> relevance.
What the items are is of key importance. These three items are not
commonly known collectively or individually as "attributes". If you use a
.guide reader that features search capability, you might never find what
you're looking for.
> If you don't know what datestamp, protection bits and comment (filenote)
> mean, then you should look them up in the AmigaDOS manual, since these
> pertain primarily to AmigaDOS and not DOpus.
Even if you do, as most who are interested in them do, there is no direct
mention of how to preserve them in the .guide file. There are no
references to "filenote", the "Comment" (filenote), Protection Bits and
DateStamp are referred to in the button bar definitions. Interestingly,
Protection Bits links to an explanation of what they are; followed by a
pointer to the button bar.
>>>> A copy should be a copy and not look like a new file. Nyahh!!!
>>>
>>> Relative to the final destination it is a 'new' file.
>>>
>>> Subjectively to you, the file 'contents' are not.
>
>> The *ONLY* difference between the files are where they are located. If
>> your copy or move program is working correctly, they should be otherwise
>> indistinguishable. As such, I believe they should carry all the same
>> "attributes". To my thinking, the time stamp is an attribute of the file,
>> not the directory in which it resides. The FileInfoBlock certainly
>> suggests this relationship.
>
> <QUOTE>
> NEW <adj> only recently existing, done or made; not known before; just
> discovered or acquired;.........
> </QUOTE>
This goes right to my point. If you're a collector of Aminet software,
graphic or sound files, these files have:
1. Been around at least since the time they were posted.
2. Unless someone has inserted a readme file or BBS adz, they are
unchanged since they were assembled.
3. They have been indexed (known) by someone (even if someone other than
ourselves)
That an individual just acquired the file shouldn't change its global
status. As a collector (presumably the people primarily concerned with
datestamps) I'd like to know which of two identically named files is the
"most current". I personally use the LhA command to re-stamp the files
that I've downloaded from Aminet so that I know, at a glance, whether I
need to concern myself with updated versions and further, if I should be
concerned about compatability issues. To its credit, Aminet searches don't
feature datestamps but they do have a "weeks since posted" column.
The *nix community is a special case that bears investigation. They deal
with datestamps and protection bits in a slightly different manner for
reasons that are purely unix:
1. Copied files get new dates and bits. This stems from the fact that
unixen use streaming to jam the input file through a pipe to the output
file. It assumes that when things come from a pipe, that they have somehow
been "filtered". This follows your definition nicely.
2. Moved (renamed) files maintain their datestamp and bits. The
technical reasons are simple: you've simply re-linked the file in the
directory tree; no filtering. This suggests that a file's attributes
include where it is physically located on a storage device.
In a DOpus move, whether a file is moving across volumes determines
whether it is renamed or copied to the destination and deleted on the
source.
> By definition, (ie. it did not exist until created), the file is 'new'
> regardless of it's location or it's contents.
>
> Obviously I should have said:
>
> Objectively, any copy (clone) of a file, (or indeed anything), will always
> be 'new'.
So if you add an Amiga 1000 to your computer collection, do you tell
people that you just acquired a "new" computer? I can agree that it is
"new" to your collection but it is really a "most recent addition".
Perhaps it might be "Like New". Putting new license plates on a clunker
automobile doesn't make it "New" (or even "Like New") unless you consider
the license plates a selling feature of the car.
The ideal situation would be that *every* file format had an internal date
stamp or version string that was associated with the contents of the file
(as opposed to any filesystem references). This is why picture collectors
and MP3 collectors have to resort to checksums to define what is "the
same". Many Windows oriented file formats even include the name of the
machine and the printer driver used when the file was created (which
defines a surprising number of things about the content). For a while,
Microsoft Word documents even included you're ultra-personal Windows
registration information in all of your documents.
IFF file formats *may* have an ANNO attribute which is seldom used. JPEG
and GIF formats have available comment blocks but they are also seldom
used. Unix weenies have had to resort to Revision Control Systems, a
system that stamps source code files with something similar to the Amiga
VER string.
Lacking wide use of any of these techniques, we pretty much have to fall
back on what all identical content files might have in common: their
contents and their "last changed" date stamp. Since the Amiga supports
only one of the three possible time stamps (created, changed, accessed), I
submit that we should treat it as the "last *changed*" datestamp.
Lee Bosch