Re: File.datecreated doesn't change


I see the behavior the OP described in Windows 98 but only if I remove the
fso.DeleteFile ("c:\testfile.txt") line. This indicates (to me) that under
the hood, CreateTextFile opens existing files in sort of a binary mode.
That
makes me wonder why they never provided a binary mode which script writers
could use. It would sure be nice to not have to write an entire file every
time you wanted to just change a single or few characters.


Opens in a binary mode? It's all really binary.
The only difference with a text file is that the
bytes signify characters and Chr(0) has special
meaning in that it signifies the end of a string
for most Windows functions. I don't think there's
any way to "just change a few bytes". I'm not
clear about the fine details of the file system on
disk, but a file is still consecutive storage of bytes.
If you change byte 100 of 1000 on disk you still
have to move the following 900, regardless of what
kind of file it is. And if you add, say, 100
bytes to an exact 8 KB file with cluster size of
4KB then Windows is going to have to find another
cluster to store those bytes in. At that level it's not
in the hands of the program writing the file. That's
why I was speculating that the file probably is techically
replaced each time, even if it's not seemingly replaced.
I tried doing a Textstream.Write operation (Win98SE)
where I replaced a sizable text file with just a few
characters. It shows the same created time when
resaved. Yet I imagine that the memory used by that
file on disk must have been released and the new, tiny
file written to a newly allotted, single cluster.

I never really thought about this topic before.
Thinking about it now I realize that it must have
been a sticky issue for MS to decide upon, since the
created date is really just a concept and their job was
to make created date act the way that people expect
it to.

I think the thing with binary files and WSH is a
combination of poor planning and "protecting people
from themselves". VBS started out as a strategy to
rain on Netscape's parade by introducing incompatibility.
I have a VBScript book from 1997 that presents VBS as
being just a new language for webpage scripting. The
author (Mary Jane Mara) described Netscape as being
difficult to use VBScript in because it had "limitations in
its support of ActiveX". The author then recommended
that separate pages might be needed for IE and Navigator
until "support of VBScript matures". :) There's no FSO
or anything like it in the old VBS book. Just webpage
scripting.
So at that point there was no CreateObject, no FileSystemObject,
no WSH, etc. It appears in hindsight that MS was being
nagged by admin. people about coming up with some kind
of GUI update equivalent to DOS files and they just hobbled
together some odds and ends that they thought people would
need, adding CreateObject to VBS in order to bring in Windows
programming abilities (and forever render IE an unsafe browser).

The package they came up with, WSH, Scripting Runtime, etc.
is clearly aimed at simple operations by people with limited
experience. Probably they left out binary operations because
they didn't want to make too much functionality available in
such an easy-to-learn tool. Oddly, though, MS apparently
tried to pass off the scripting runtime as an official part of
VB6. The O'Reilly VB6 reference book includes all of the FSO
operations as though they were part of the core language!

Strictly speaking, I guess MS didn't actually leave out binary
operations from FSO but rather hobbled the file I/O operations
to make binary functions difficult.
(FSO can handle binary files perfectly well on any PC that
doesn't use an Asian, DBCS (double byte character set)
codepage. The bigger problem is that FSO, and WSH, are
slow and inefficient with larger files.)

When VBS first came out I think it was more of a
hobbyist thing. It's only in recent years that I've seen this
group turn into mainly an admin. tasks discussion group.
In the interim VBS has been stretched to the limit, hijacking
any available COM object and even finding ways to make
API calls. There seems to be a general pattern, with script,
with VB, and probably now with .Net, where MS tries to
provide limited "kiddy tools" so that 3rd parties can automate
MS software, but then the 3rd parties start looking for ways
to take matters into their own hands. :)

As far as the OP's situation goes, if DateCreated tag is not changing even
with using the DeleteFile method, then renaming the file before deletion
may
solve the problem.

Dim fso, MyFile
on error resume next
Set fso = CreateObject("Scripting.FileSystemObject")
fso.MoveFile "c:\testfile.txt", "c:\testfile.txt.del"
fso.DeleteFile "c:\testfile.txt.del"
Set MyFile = fso.CreateTextFile("c:\testfile.txt", True)
MyFile.WriteLine("This is a test.")
MyFile.Close

--
Todd Vargo
(Post questions to group only. Remove "z" to email personal messages)



.

Relevant Pages

  • Re: "scrrun.dll" not compatible in different languages?
    ... Any OS that supports scripting must be properly locked down or the scripting ... some features in FSO that are nearly impossible to ... The fact that VB 6 doesn't support ... The fact that there is no way to write a decent language translator from VB ...
    (microsoft.public.vb.general.discussion)
  • Re: "scrrun.dll" not compatible in different languages?
    ... >Any OS that supports scripting must be properly locked down or the scripting ... >situation exists today with Windows. ... >implement in VB 6 without FSO or another file system interface. ... >that VB 6 doesn't support multi-platform file IO is based on the fact that ...
    (microsoft.public.vb.general.discussion)
  • Re: Create folder from within Access VB
    ... a program to wreak havoc from a batch file. ... using the File Scripting Object in an Access app. ... of a single reason to use that abomination (FSO) in an Access application. ... Set objTemp = fs.CreateFolder ...
    (microsoft.public.access.formscoding)
  • Re: Create folder from within Access VB
    ... The use of FSO in a scripting environment is fine as this is what it was ... Set objTemp = fs.CreateFolder ...
    (microsoft.public.access.formscoding)
  • Re: Curent Dir
    ... > ich have a HTML Page with VBS parts like ... > and in ther i try to get the current directory but how? ... Do you want the full physical path with the drive letter? ... Here's a JavaScript solution that doesn't use FSO: ...
    (microsoft.public.scripting.vbscript)
Loading