RECMGMT-L Archives

Records Management

RECMGMT-L@LISTSERV.IGGURU.US

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Sender:
Records Management Program <[log in to unmask]>
Date:
Mon, 19 Feb 2007 10:01:52 -0500
Reply-To:
Records Management Program <[log in to unmask]>
Subject:
MIME-Version:
1.0
Content-Transfer-Encoding:
7bit
In-Reply-To:
Content-Type:
text/plain; charset="us-ascii"
From:
John Phillips <[log in to unmask]>
Parts/Attachments:
text/plain (94 lines)
Gerard,

I believe that we are in agreement on most of the assertions, including that
the OS creation dates will change during a copy - as would be expected since
the OS serves itself with respect to metadata. And the date modified should
not change, thus creating the "modified" before the "creation" date anomaly.

However, I am not sure that I totally agree with "If you are talking about
the meta data stored within a Microsoft Office document such as the
"Document Created" element this definitely will not change irrespective of
the way the file is migrated." - It seems that depends on the technical way
things are "migrated". If they are copied, the creation date seems to change
to the date/time of the copy. If they are moved, the creation date is not
updated to the date/time of the move - at least that is what seems to be the
case when I "move" a file between drives.

Of equal concern is that if one points to a file through Windows Explorer
that has not been accessed recently, and then do a right mouse click to see
the properties, you will find the properties say that the file was last
"accessed" at whatever (current computer clock) time you are just looking at
the file's metadata. This will be true despite the fact that you did not
open the file.

Another more obvious example of a disconcerting inability of MS Windows to
track metadata is that one can use Windows Explorer to directly change a
file's name. Nothing will change in the metadata. So you can rename files
completely, add v.1, v.2, etc. and nothing changes in the metadata at either
the Windows level or the application level. So much for Windows level
record-keeping.

I think that Andrew's post about the legal discussions one can get into
regarding these issues is very enlightening in that in the end evidentiary
value will come down to a debate about the known technology issues vs the
"normal course of business" issues. What can be considered accurate and
authentic regarding an electronic records "creation" will often depend on
how an organization rigorously followed policies and procedures.

John

********************************
John T. Phillips
MSLS, CRM, CDIA, FAI
Electronic Records Management
Consulting, Education, Research
Information Technology Decisions
www.infotechdecisions.com
865-966-9413


-----Original Message-----
From: Records Management Program [mailto:[log in to unmask]] On Behalf
Of Gerard Nicol
Sent: Sunday, February 18, 2007 8:04 PM
To: [log in to unmask]
Subject: Re: Microsoft Properties Metadata

John,

If you make a file read only this will not stop it from being read to make a
copy. The attributes of the copy will reflect the fact that the copy is a
new file.

All operating systems work like this from zOS Mainframes to Windows Cell
Phones. This is because it reflects the reality.

When I copy a PDF it changes the OS level creation date just like any other
file.

The same application level meta data is available in Office documents as is
availalbe under Adobe PDF. This should remain unchanged.

Gerard



On Sun, 18 Feb 2007 00:47:36 -0500, John Phillips
<[log in to unmask]> wrote:

>George,
>
>Yes, the Microsoft Properties are a poor excuse for (controlled) metadata.
>In presentations I like to show the metadata properties for the
presentation
>that I am showing the audience - It usually says the date that I am
standing
>before them, because that is when I moved it to that machine, and also
says

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance

List archives at http://lists.ufl.edu/archives/recmgmt-l.html
Contact [log in to unmask] for assistance

ATOM RSS1 RSS2