New 32-bit multitasking DOS now available for download
Berth-Olof Bergman
own CD for testing out our 32-bit multitasking OS, ZDOS. The target for ZDOS
is embedded systems with PC architecture.The ISO-file can be downloaded at
http://www.zebor.com/main/zdos.html.
The CD is bootable live CD, so you can test ZDOS before you determine if you
want to install it.
The CD also contains an installer for open watcom 1.8 (windows hosted) with
support for development of ZDOS applications and drivers.
This is my first release of ZDOS to the public, so there are still very
limited applications and drivers for it. Currently there are 3 ethernet
drivers, a TCP/IP driver, a packet capture driver and some system tools.
How ever since the run time library is fully compatible with both 16-bit and
32-bit extended DOS, this can quickly change if any of you are interested.
I will publish the next release in the start of Q3 this year. It will
contain the rest of the (Z)DOS system tools and also a lot more of network
tools and some other software. Until then, I hope you will give it a try and
perhaps even getting to like it.
B-O
japheth
> For those of you who likes DOS I have published an ISO-file for burning your
> own CD for testing out our 32-bit multitasking OS, ZDOS. The target for ZDOS
> is embedded systems with PC architecture.The ISO-file can be downloaded at
> http://www.zebor.com/main/zdos.html.
Thanks! I like DOS and I'm interested, but a question first: why is the ISO so
huge and needs 50 MB? Is this because it contains OW? Or did I misinterpret
your post?
Berth-Olof Bergman
> Thanks! I like DOS and I'm interested, but a question first: why is the
> ISO so huge and needs 50 MB? Is this because it contains OW? Or did I
> misinterpret your post?
>
1) Full OW 1.8 installation.
2) ZDOS (combinated live and installation CD).
The ZDOS part is about 400KB.
B-O
George White
"Berth-Olof Bergman" <b-o.b...@zebor.com> wrote in message
news:fnlaqs$fgf$1...@www.openwatcom.org...
> "japheth" <ma...@japheth.de> wrote:
>>
> Yes, it contains the following:
>
> 1) Full OW 1.8 installation.
??? Current Official release is 1.7a. Surely it should not (yet) be
described as 1.8 - that will lead to confusion down the line...
But how to describe it? I think I will leave that to Peter Chapin to rule
on... He is the current keeper of the releases.
George
Bob Kematick
> For those of you who likes DOS I have published an ISO-file for burning your
> own CD for testing out our 32-bit multitasking OS, ZDOS. The target for ZDOS
> is embedded systems with PC architecture.The ISO-file can be downloaded at
> http://www.zebor.com/main/zdos.html.
>
> The CD is bootable live CD, so you can test ZDOS before you determine if you
> want to install it.
> The CD also contains an installer for open watcom 1.8 (windows hosted) with
> support for development of ZDOS applications and drivers.
>
I downloaded the "Evaluation.iso" file. Tried to start it in a virtual
machine with vmware player. Also burned it to CD and tried to boot a
real machine. Failed in both cases. A screen capture from the vmplayer
session is at http://as.chem.binghamton.edu/~bobk/zdos.jpg
rug...@gmail.com
On Jan 27, 1:29 pm, "Berth-Olof Bergman" <b-o.berg...@zebor.com>
wrote:
> For those of you who likes DOS I have published an ISO-file for burning your
> own CD for testing out our 32-bit multitasking OS, ZDOS.
>
"Written completely in assembly"? Which one (MASM, TASM, NASM, FASM)?
SSE support? 386 minimum? Built-in DPMI server? Works with DJGPP apps?
(Maybe I should just try it, heh.) :-)
> The CD is bootable live CD, so you can test ZDOS before you determine if you
> want to install it.
>
What file systems does it support? (I assume FAT and/or something
unique.)
I assume it doesn't know how to dual boot (or certainly, not resize or
make new partitions). I guess GParted liveCD (or SPfdisk + Partition
Resizer) is also our friend here. :-)
> This is my first release of ZDOS to the public, so there are still very
> limited applications and drivers for it.
I've seen it before when browsing around. So, it's not a "new"
product, but the demo .ISO itself is new, right?
> I will publish the next release in the start of Q3 this year. It will
> contain the rest of the (Z)DOS system tools and also a lot more of network
> tools and some other software. Until then, I hope you will give it a try and
> perhaps even getting to like it.
It sounds interesting. The main concerns are stability and
compatibility.
>
> B-O
Peter C. Chapin
> ??? Current Official release is 1.7a. Surely it should not (yet) be
> described as 1.8 - that will lead to confusion down the line...
True. We don't really know what 1.8 looks like yet, since it doesn't exist.
> But how to describe it? I think I will leave that to Peter Chapin to rule
> on... He is the current keeper of the releases.
I think Berth-Olaf is using a modified version of the current (or maybe
the 1.7) source. Perhaps it would be more accurate to say "1.7 modified
for ZDOS" or something similar.
Peter
Berth-Olof Bergman
> I downloaded the "Evaluation.iso" file. Tried to start it in a virtual
> machine with vmware player. Also burned it to CD and tried to boot a real
> machine. Failed in both cases. A screen capture from the vmplayer session
> is at http://as.chem.binghamton.edu/~bobk/zdos.jpg
>
expected drive type for the emulated drive. It seems to return 55h for the
emulated drive (it should return a value of 0 - 5). I will find a work
around for this and update the ISO image.
B-O
Berth-Olof Bergman
> I think Berth-Olaf is using a modified version of the current (or maybe
> the 1.7) source. Perhaps it would be more accurate to say "1.7 modified
> for ZDOS" or something similar.
>
> Peter
distribution. So it's 1.8 developer version with ZDOS support added.
B-O
Berth-Olof Bergman
>
> What file systems does it support? (I assume FAT and/or something
> unique.)
>
> I assume it doesn't know how to dual boot (or certainly, not resize or
> make new partitions). I guess GParted liveCD (or SPfdisk + Partition
> Resizer) is also our friend here. :-)
>
> I've seen it before when browsing around. So, it's not a "new"
> product, but the demo .ISO itself is new, right?
>
>
> It sounds interesting. The main concerns are stability and
> compatibility.
>
B-O
Steve Fabian
| <rug...@gmail.com> wrote:
||
|| What file systems does it support? (I assume FAT and/or something
|| unique.)
||
| FAT12, FAT16 and ZDOS FAT32.
Two others are important - VFAT and NTFS. VFAT can handle long file names
and additional timestamps. NTFS can handle both symbolic and hard links. Do
you expect ever to support them?
--
Steve
Berth-Olof Bergman
> Two others are important - VFAT and NTFS. VFAT can handle long file names
> and additional timestamps. NTFS can handle both symbolic and hard links.
> Do
> you expect ever to support them?
> --
> Steve
>
interface.
B-O
Steve Fabian
Do you expect ZDOS (i.e., you yourself) to provide the drivers for NTFS and
for VFAT?
--
Steve
Mark D. Overholser
Virtual PC 5.2 displays the same thing, the Dump looks identical.
MarkO
Berth-Olof Bergman
They seem to have a flaw in the floppy emulation part of the EL Torito
standard in their BIOS emulator. Parallells workstation works and I have not
been able to check this out any closer as we are currently busy representing
ZDOS in a 3 day embedded exhibition here in Sweden.
It also runs perfectly on our own ZBIOS, Phoenix BIOS, Award BIOS and
Toshiba BIOS to name a few. I will check it out on thursday, when I'm back
in the lab.
Anyway, as the drive value > 5, I suspect the entire emulated disk image is
loaded to a ram disk by the boot loader. In this case the BIOS function for
moving data to extended memory needs to be perfectly emulated. If the drive
is within range, the boot loader will call the BIOS to check if it's an
emulated floppy on CD. One of this failes to execute properly in your case
and I have to find out which and why.
B-O
Bob Kematick
> "Mark D. Overholser" <wat...@markoverholser.com> wrote:
>> Berth-Olof Bergman wrote:
>>
>>> "Bob Kematick" <bo...@goaway.org> wrote:
>>>
[snip]
>
> Anyway, as the drive value > 5, I suspect the entire emulated disk image is
> loaded to a ram disk by the boot loader. In this case the BIOS function for
> moving data to extended memory needs to be perfectly emulated. If the drive
> is within range, the boot loader will call the BIOS to check if it's an
> emulated floppy on CD. One of this failes to execute properly in your case
> and I have to find out which and why.
>
> B-O
>
FWIW: I played with the vmware "vmx" file, and disabled all drives
except the live cd, and it now starts up. I seem to be getting a swedish
keyboard that I can't quite make work.
I have also found a couple of more "real" machines that I can not boot
with the live cd.
Berth-Olof Bergman
>
> FWIW: I played with the vmware "vmx" file, and disabled all drives except
> the live cd, and it now starts up. I seem to be getting a swedish keyboard
> that I can't quite make work.
>
> I have also found a couple of more "real" machines that I can not boot
> with the live cd.
>
>
B-O
Berth-Olof Bergman
>
> FWIW: I played with the vmware "vmx" file, and disabled all drives except
> the live cd, and it now starts up. I seem to be getting a swedish keyboard
> that I can't quite make work.
>
Press CTRL+ALT+F2 you toggle to US keyboard. Press CTRL+ALT+F1 for going
back to swedish.
Alternative 2:
Type config.sys on your emulated hard drive.
Execute copy con config.sys and retype all lines except the line with
HARDWARE=C:\DRIVERS\KEYBOARD\KEYBSW.HWD.
Press F6 to save the new config.sys.
You will then have the US keyboard layout permanently.
B-O
Bob Kematick
In a roundabout way, I got it installed to a virtual drive and running
with the vmware player. I went to easyvmx.com and set up a dos vmx with
a 1 Gb virtual hardrive and the Evaluation.iso as a live CD. First boot
of virtual machine, hit f2 to go into bios setup and set hard drive type
to none. Zdos will boot from the iso, and you can then (surprisingly)
use fdisk, format, and install to prepare the virtual hard drive. Reboot
the virtual machine, f2 to get to virtual bios setup, set hardrive type
to auto, and adjust boot sequence so hard drive is before cd rom, and
there you go.
vmware seems to use some sort of virtual phoenix bios, regardless of
what is on the host machine.
Berth-Olof Bergman
This has been fixed and it should work now for Wmware, Virtual PC and
Phoenix BIOS. I have removed the swedish keyboard layout in this release. I
also added a tool for starting ZDOS in a different graphics mode (text mode
or linear frame buffer mode). The tool is framebuf.exe and the supported
modes is in a word document on the CD. There are two different versions on
the iso image on the site, one with US keyboard layout and one with swedish
keyboard layout. The swedish version is located on www.zebor.se and the US
version on www.zebor.com.
B-O
Open Watcom
"Berth-Olof Bergman" <b-o.b...@zebor.com> wrote in message
news:fnimis$ttc$1...@www.openwatcom.org...
Your message has caused a bit of a buzz around here. After a failed attempt
to load ZDOS on a Geode GXLV (Phoenix BIOS) PC/104 platform, we were
successful with an ICOP Vortex86 PC/104 module (AMIBIOS) and now have ZDOS
up and running on Compact Flash.
The question that intrigues is Zebor's web site sentence "For your
convenience, the tool chain can be run in both ZDOS and Windows host
environments.". Would need to know how OW is set up for a ZDOS host.
It seems for a Windows based host, parserv/serserv/tcpserv etc. have no part
in the ZDOS environment.
Wish you every success with ZDOS, regards,
davidm
Bob Kematick
> "Mark D. Overholser" wrote:
>> Berth-Olof Bergman wrote:
>>
>>> "Bob Kematick" <bo...@goaway.org> wrote:
[snip]
> This has been fixed and it should work now for Wmware, Virtual PC and
> Phoenix BIOS. I have removed the swedish keyboard layout in this release. I
> also added a tool for starting ZDOS in a different graphics mode (text mode
> or linear frame buffer mode). The tool is framebuf.exe and the supported
> modes is in a word document on the CD. There are two different versions on
> the iso image on the site, one with US keyboard layout and one with swedish
> keyboard layout. The swedish version is located on www.zebor.se and the US
> version on www.zebor.com.
>
> B-O
>
>
One of my professors always said that "should is a funny word". ;-)
The file http://www.zebor.com/main/download/ZdosUSA.iso seems to have
problems, trying to boot it live in vmware gives "CDROM media bad -
installation aborted"
Berth-Olof Bergman
>
> The file http://www.zebor.com/main/download/ZdosUSA.iso seems to have
> problems, trying to boot it live in vmware gives "CDROM media bad -
> installation aborted"
>
be a matter of configuration?
B-O
Berth-Olof Bergman
In a positive way I hope?!
>
> After a failed attempt to load ZDOS on a Geode GXLV (Phoenix BIOS) PC/104
> platform, we were successful with an ICOP Vortex86 PC/104 module (AMIBIOS)
> and now have ZDOS up and running on Compact Flash.
>
There was a problem with Phoenix BIOS. It has been solved. A new release can
be downloaded at www.zebor.com/main/download/ZdosUSA.iso.
>
> The question that intrigues is Zebor's web site sentence "For your
> convenience, the tool chain can be run in both ZDOS and Windows host
> environments.". Would need to know how OW is set up for a ZDOS host.
>
> It seems for a Windows based host, parserv/serserv/tcpserv etc. have no
> part in the ZDOS environment.
>
I have ported most of the tools to ZDOS. I'm working on completing the
toolkit with remote debugging support from the IDE in Windows (TCP/IP and
serial port). The OW tools for ZDOS as host will be released when the tool
chain is complete. I have not ported the debugger and editor yet.
>
> Wish you every success with ZDOS, regards,
>
> davidm
>
>
>
Thanks!!!!
B-O
Bob Kematick
Nope, I think that your iso is indeed broken. Have you tried burning it
to disk and firing it up yourself ?
Berth-Olof Bergman
Yes, I have burnt it and run it from CD. It worked fine. The message is from
within ZDOS and caused by the carry flag being set upon return from a
procedure called ReadCDROM. It failes in one of the following steps,
probably already at the first.
1) Reading the boot sector of binary floppy image. On succes and a correct
signature in the boot sector we skip steps 2 and 3.
2) Read boot record volume descriptor (sector 17).
3) Read boot catalog and retrive boot image sector from it.
The above step calls ReadCDROM which reads the CD rom sector. It returns
with carry flag set if it failes to read the sector. The CDROM device needs
to be perfectly emulated as a parallell IDE device communicating with the
ATAPI packet command.
B-O
Bob Kematick
> "Bob Kematick" <bo...@goaway.org> wrote:
>> Berth-Olof Bergman wrote:
>>> "Bob Kematick" <bo...@goaway.org> wrote:
>
> Yes, I have burnt it and run it from CD. It worked fine. The message is from
> within ZDOS and caused by the carry flag being set upon return from a
> procedure called ReadCDROM. It failes in one of the following steps,
> probably already at the first.
>
[snip]
I got it to boot on 2 out of 3 "real" machines I tried, but one (the
first I tried) gave the CDROM read error, just like vmware. The real
machine that failed actually had two drives ( cd + dvd )
I guess that this is drifting too far away from an openwatcom related
discussion.
Mark D. Overholser
I got it to boot in VPC 5.2 just fine.. I could also Format the
Virtual HardDrive, but not make it a Bootable System drive, but I would
not expect that from a Bootable Demo...
MarkO
Bob Kematick
>>
>
> I got it to boot in VPC 5.2 just fine.. I could also Format the
> Virtual HardDrive, but not make it a Bootable System drive, but I would
> not expect that from a Bootable Demo...
>
> MarkO
I got it installed under vmware by burning the iso to disk, then
configuring the vmplayer to boot from the actual physical CD drive,
rather than the iso file itself. I was able to format the virtual hard
drive and made it bootable. I even copied an open watcom folder in from
somewhere else. I couldn't run the compiler at all. The binw\wcc.exe and
binw\wcc386 gave register dumps all over the screen. Perhaps I set it up
wrong.
I have a bunch of old Dell machines laying around. I find (GX1's) that
won't boot from the CD, they give the same "CDROM media bad -
installation aborted" message that I have seen before under vmware. I
think these machines are using a Phoenix BIOS circa 1990.
A newer Dell (GX280) booted fine from the CD, but the USB keyboard
proved useless.
It seems to me that ZDOS should perhaps be considered early alpha product.
Berth-Olof Bergman
> HardDrive, but not make it a Bootable System drive, but I would not expect
> that from a Bootable Demo...
>
> MarkO
label it ZDOS as well.
After that type install and ZDOS will be installed on the virtual disk.
B-O
Michal Necasek
> I have a bunch of old Dell machines laying around. I find (GX1's) that
> won't boot from the CD, they give the same "CDROM media bad -
> installation aborted" message that I have seen before under vmware. I
> think these machines are using a Phoenix BIOS circa 1990.
>
That doesn't sound likely - booting from CDs didn't really exist until
1995 or so, and CD-ROMs were extremely rare in 1990 to begin with.
> A newer Dell (GX280) booted fine from the CD, but the USB keyboard
> proved useless.
>
You may need to configure the BIOS for "legacy" USB keyboard support.
Michal
Berth-Olof Bergman
>
> I got it installed under vmware by burning the iso to disk, then
> configuring the vmplayer to boot from the actual physical CD drive, rather
> than the iso file itself. I was able to format the virtual hard drive and
> made it bootable. I even copied an open watcom folder in from somewhere
> else. I couldn't run the compiler at all. The binw\wcc.exe and binw\wcc386
> gave register dumps all over the screen. Perhaps I set it up wrong.
>
tools for ZDOS yet. Install the Watcom tools for Windows on the CD and use
these tools instead. They need to be run in Windows environment and you will
be able to select ZDOS as target platform.
B-O
Kevin G. Rhoads
I always tell students (and others) that "should" should be spelled
"shud", because it is clearly a four-letter word.
john smith
> Bob Kematick wrote:
>
>> I have a bunch of old Dell machines laying around. I find (GX1's) that
>> won't boot from the CD, they give the same "CDROM media bad -
>> installation aborted" message that I have seen before under vmware. I
>> think these machines are using a Phoenix BIOS circa 1990.
>>
> That doesn't sound likely - booting from CDs didn't really exist until
> 1995 or so, and CD-ROMs were extremely rare in 1990 to begin with.
>
I was just looking at a splash screen, and probably did not pick up an
accurate date on the BIOS. The GX110's have a made for Windows 98
sticker on them, snd will in fact boot from CD.
>> A newer Dell (GX280) booted fine from the CD, but the USB keyboard
>> proved useless.
>>
> You may need to configure the BIOS for "legacy" USB keyboard support.
>
>
> Michal
I will try that.
Bob Kematick
> Bob Kematick wrote:
>
>> I have a bunch of old Dell machines laying around. I find (GX1's) that
>> won't boot from the CD, they give the same "CDROM media bad -
>> installation aborted" message that I have seen before under vmware. I
>> think these machines are using a Phoenix BIOS circa 1990.
>>
> That doesn't sound likely - booting from CDs didn't really exist until
> 1995 or so, and CD-ROMs were extremely rare in 1990 to begin with.
>
The GX1's have made for Windows 98 stickers on them, and will boot from
CD. The date I saw was on a splash screen, and probably was not
accurate. I have still older Dell's (GXa, GXpro) that will not boot from
CD. (This lab is sort of like a Dell graveyard.)
>> A newer Dell (GX280) booted fine from the CD, but the USB keyboard
>> proved useless.
>>
> You may need to configure the BIOS for "legacy" USB keyboard support.
>
I will try that, thanks.
Mark D. Overholser
Hmm... That Worked....
I have a 1GB Virtual Disk. I formated like you indicated. Ran the
Install Script (in the Install Directory on the CDROM) and rebooted with
no CDROM ISO mounted. Booted fine...
MarkO
Arkady V.Belousov
Steve Fabian 29.01.08 16:44 wrote:
> || What file systems does it support? (I assume FAT and/or something
> || unique.)
> | FAT12, FAT16 and ZDOS FAT32.
> Two others are important - VFAT and NTFS. VFAT can handle long file names
> and additional timestamps.
VFAT isn't filesystem, but just virtual Windows driver, which handles
FAT12/FAT16/FAT32 file systems extension (which is only extra fields in
directories) and provides access to LFNs through INT21 additional functions.
> NTFS can handle both symbolic and hard links. Do
Links are inherent to *ix files systems; why not count these systems
important too? (BTW, which difference between "symbolic" and "hard" links?)
Steve Fabian
| Steve Fabian wrote:
|| NTFS can handle both symbolic and hard links. Do
|
| Links are inherent to *ix files systems; why not count these
| systems important too? (BTW, which difference between "symbolic" and
| "hard" links?)
FATnn and VFAT do not support any kind of links.
A hard link means that there is only one copy of the file content, but there
is more than one directory entry, through which it can be accessed. In *nix
and VMS file systems the directory entries contain the local name and the
index into the disk area which contains the file desciptors (timestamps,
size, attributes, link count, and location of the file body). In NTFS most
(or all) of the file descriptor is replicated for each directory entry made
for the file. As a consequence, when you change a timestamp or attribute of
a file using one of its directory entries, in *nix file systems all
directory entries are effectively updated instanyly, but in NTFS the other
entries are not updated automatically. In all file systems that support hard
links all directory entries hard linked to the same file body must be on the
same disk volume. In NTFS hard links are always for files, not directories
(though I think in Vista you can have directory hard links, too, but I am
not sure). I also seem to remember reading that in Vista you can have hard
links between directories.
In contrast a symbolic link is a directory entry, which points to another
directory entry. The file or directory can be accessed either directly, or
through the symbolic link. In *nix and Windows Vista you can have symbolic
links both to files and to directories, and the symbolic link can reference
entities on a different volume than the one where it is a directory entry.
.In Windows XP symbolic links are for directories only, and are restricted
to in-volume links. I think Windows 2000 supports the same types of links as
WinXP.
In WinXP you can create a symbolic link to a target directory only if the
target exists. Hoever, once the link exists, the target directory can be
deleted or renamed, and another directory created or renamed to the target
directory's name. You don't run into problems unless you try to access
something useing the symbolic link at a time when its target does not exist.
--
HTH, Steve
Bartosz Polednia
Shortly, IMHO:
- softlink is as shortcut in Windows
if you delete it the target remains untouched
- if you delete hardlink then you delete the target also
You should not forget that files in *ix are not physically deleted
until they are opened by other users so it means that file is accessible
by them till they close the file - rm operation is "queued".
If you try open file which has pending deletion then you can not do it.
Bartosz.
Peter C. Chapin
> - if you delete hardlink then you delete the target also
That's only true if there are no other hard links to the file. The file
system tracks the number of links to the file and removes the file from
disk when that count reaches zero.
Peter
Philip Nienhuis
> Arkady V.Belousov wrote:
> | Steve Fabian wrote:
> || NTFS can handle both symbolic and hard links. Do
> |
> | Links are inherent to *ix files systems; why not count these
> | systems important too? (BTW, which difference between "symbolic" and
> | "hard" links?)
>
> FATnn and VFAT do not support any kind of links.
PMFJI -
Yes and no. See below...
> A hard link means that there is only one copy of the file content, but there
> is more than one directory entry, through which it can be accessed. In *nix
:
<snip>
>
> In contrast a symbolic link is a directory entry, which points to another
> directory entry. The file or directory can be accessed either directly, or
> through the symbolic link. In *nix and Windows Vista you can have symbolic
> links both to files and to directories, and the symbolic link can reference
> entities on a different volume than the one where it is a directory entry.
> .In Windows XP symbolic links are for directories only, and are restricted
> to in-volume links. I think Windows 2000 supports the same types of links as
> WinXP.
>
> In WinXP you can create a symbolic link to a target directory only if the
> target exists. Hoever, once the link exists, the target directory can be
> deleted or renamed, and another directory created or renamed to the target
> directory's name. You don't run into problems unless you try to access
> something useing the symbolic link at a time when its target does not exist.
I think the explanation above induces a bit of confusion.
Symbolic links in NTFS under WinXP, in the form of dedicated file system
structures that you seem to indicate, are easily confused with e.g.,
Windows shortcuts ("Shortcut to") that can point to about anything.
The easiest example is a Windows desktop or Start Menu shortcut, which
can point to a file (e.g., "explorer.exe") as well as a directory (e.g.,
the Control Panel) - either of which can be on any volume, even across
network connections, on any Windows version from '95 to Vista.
Oh and such shortcuts work from and to (V)FAT file systems, too.
Now, when I access ext2/3 drives from Windows (using www.fs-driver.org
or explore2fs), symbolic links don't work; nor do VFAT/NTFS shortcuts
work when accessed from Linux.
So I tend to conclude that:
1. Physically, symbolic links can simply be a file with special contents;
2. Functionally, symbolic links in a file system are not a feature of a
file system alone but rather a feature of the combination of file system
AND implementation of the file system driver. That is quite unlike hard
links.
To go on, I can't see any reason why a (V)FAT file system wouldn't
support hard links (in the sense of multiple directory entries with
(optionally!) the same meta-info pointing to the same chain of blocks).
In fact using a little (but careful) debugging with a disk editor, you
can make them yourself.
A plain vanilla VFAT driver will blindly accept them for just reading.
But I know of no FAT driver that has provisions for properly dealing any
further with them; that's probably the reason that scandisk or chkdsk
will destroy them. Nevertheless on a read-only FAT volume such hard
links wouldn't hurt much and can have similar use to that on e.g., *nix
file systems.
So in conclusion, even on (V)FAT systems you can have any kind of links.
Yet a proper file system driver / operating system is needed for
meaningful use of symbolic and hard links on any file system.
[BTW, a little OT]
IIRC there's an unofficial CD-ROM image builder by Microsoft (CDIMAGE?)
that is able to make hard links in the iso9600 file system, in order to
save disk space on multi-Windows version installation CD-ROMs.
Philip
Steve Fabian
|| directory can be deleted or renamed, and another directory created
|| or renamed to the target directory's name. You don't run into
|| at a time when its target does not exist.
|
| I think the explanation above induces a bit of confusion.
|
| Symbolic links in NTFS under WinXP, in the form of dedicated file
| system structures that you seem to indicate, are easily confused with
| e.g., Windows shortcuts ("Shortcut to") that can point to about
| anything.
| The easiest example is a Windows desktop or Start Menu shortcut, which
| can point to a file (e.g., "explorer.exe") as well as a directory
| (e.g., the Control Panel) - either of which can be on any volume,
| even across network connections, on any Windows version from '95 to
| Vista.
| Oh and such shortcuts work from and to (V)FAT file systems, too.
I never considered shortcuts to files or directories to be the equivalent of
symbolic links, because they cannot be used from the command line of any
command processor ("shell" for *nix) I know of for the purpose of accessing
the file or directory content. AFAIK they only work from Windows Explorer
(and Internet Explorer), invoked explicitly or implicitly (by selecting the
shortcut from the desktop, etc.).
| Now, when I access ext2/3 drives from Windows (using www.fs-driver.org
| or explore2fs), symbolic links don't work; nor do VFAT/NTFS shortcuts
| work when accessed from Linux.
| So I tend to conclude that:
| 1. Physically, symbolic links can simply be a file with special
| contents;
It is an irrelevant implementation detail whether the target information is
stored in the body of a special file, not accessible through normal file
read or file write methods, as in *nix, or the whole information is stored
in the directory entry itself. I do not know which method is used in NTFS.
| 2. Functionally, symbolic links in a file system are not a feature of
| a file system alone but rather a feature of the combination of file
| system AND implementation of the file system driver. That is quite
| unlike hard links.
Correct. For example, both Windows XP and Windows Vista use the identical
NTFS, and the differences I mentioned are in the file system drivers of
these OSs.
| To go on, I can't see any reason why a (V)FAT file system wouldn't
| support hard links (in the sense of multiple directory entries with
| (optionally!) the same meta-info pointing to the same chain of
| blocks). In fact using a little (but careful) debugging with a disk
| editor, you can make them yourself.
| A plain vanilla VFAT driver will blindly accept them for just reading.
| But I know of no FAT driver that has provisions for properly dealing
| any further with them; that's probably the reason that scandisk or
| chkdsk will destroy them. Nevertheless on a read-only FAT volume such
| hard links wouldn't hurt much and can have similar use to that on
| e.g., *nix file systems.
Hard link in VMS (1999 version) is an example of bad implementation. The
link count is not stored anywhere. Consequently, just as in your (V)FAT
example, deleting the file by any of its directory entries deletes its body,
and the remaining entries are available to create chaos on the disk.
| So in conclusion, even on (V)FAT systems you can have any kind of
| links. Yet a proper file system driver / operating system is needed
| for meaningful use of symbolic and hard links on any file system.
I agree. However, as an answer to Arkady's question I did not consider the
additional detail necessary.
--
Steve
Steve Fabian
||| (BTW, which difference between "symbolic" and "hard" links?)
|
| Shortly, IMHO:
|
| - softlink is as shortcut in Windows
| if you delete it the target remains untouched
but not as limited - wherever you can use a file or directory name, you can
use the softlink (another name for symbolic link) not true for Windows
shortcuts. The only exception to the general equivalence of using the
softlink vs. explicit use of its target is deletion (taget remains
untouched).
| - if you delete hardlink then you delete the target also
| You should not forget that files in *ix are not physically deleted
| until they are opened by other users so it means that file is
| accessible by them till they close the file - rm operation is
| "queued".
| If you try open file which has pending deletion then you can not do
| it.
I think you should say (and AFAIK this applies to most FSs and OSs) the file
content (body) is not deleted until all processes that opened it by any of
its directory entries close it. This is why updating a .dll used by a
running program results in either failure, or in a mark to delete and
replace it on the next system start.
In WinXP you cannot "delete" a hard link to a file which has more than one
when it is open, but - IIRC - generally the WinAPI call to delete a LINK
which is not open succeeds.
--
Steve
Arkady V.Belousov
Steve Fabian 08.02.08 9:37 wrote:
> || NTFS can handle both symbolic and hard links. Do
> | Links are inherent to *ix files systems; why not count these
> | systems important too? (BTW, which difference between "symbolic" and
> | "hard" links?)
> FATnn and VFAT do not support any kind of links.
Of course. Except, that there is possible to imitate links by external
utilities - even original DOS includes APPEND, JOIN and SUBST.
> A hard link means that there is only one copy of the file content, but there
> is more than one directory entry, through which it can be accessed. In *nix
> and VMS file systems the directory entries contain the local name and the
> index into the disk area which contains the file desciptors (timestamps,
> size, attributes, link count, and location of the file body). In NTFS most
> (or all) of the file descriptor is replicated for each directory entry made
> for the file. As a consequence, when you change a timestamp or attribute of
> a file using one of its directory entries, in *nix file systems all
> directory entries are effectively updated instanyly, but in NTFS the other
> entries are not updated automatically.
Hm, this should lead to inconsistency (or much of work to synchronize
between all entries) - for example, file can't have more than one size.
> In all file systems that support hard
> links all directory entries hard linked to the same file body must be on the
> same disk volume.
[...]
> In contrast a symbolic link is a directory entry, which points to another
> directory entry. The file or directory can be accessed either directly, or
> through the symbolic link. In *nix and Windows Vista you can have symbolic
> links both to files and to directories, and the symbolic link can reference
> entities on a different volume than the one where it is a directory entry.
Thanks for explanation.
Arkady V.Belousov
Bartosz Polednia 08.02.08 11:02 wrote:
> >> (BTW, which difference between "symbolic" and "hard" links?)
> Shortly, IMHO:
> - softlink is as shortcut in Windows
> if you delete it the target remains untouched
> - if you delete hardlink then you delete the target also
...unless there exist another hardlink(s). In *ix there is count of
links to file in file index block, and file deleted only when counter
decreased to zero.
> You should not forget that files in *ix are not physically deleted
> until they are opened by other users so it means that file is accessible
> by them till they close the file - rm operation is "queued".
In DOS/Windows with (V)SHARE loaded deletion for opened file will fail
(and I think, this is more wise, than pending delete operation). But I hear
(although not investigate myself) old versions of PKZIP create temporary
files and delete them immediately, which then wiped by OS when file closed.
Steve Fabian
| Hi!
|
| Steve Fabian 08.02.08 9:37 wrote:
|
|||| NTFS can handle both symbolic and hard links. Do
||| Links are inherent to *ix files systems; why not count these
||| systems important too? (BTW, which difference between "symbolic" and
||| "hard" links?)
|| FATnn and VFAT do not support any kind of links.
|
| Of course. Except, that there is possible to imitate links by
| external utilities - even original DOS includes APPEND, JOIN and
| SUBST.
True, but all 3 are for directories only, and are not stored in the file
system (FS). Links are stored in the FS, and are processed by the OS.
|| A hard link means that there is only one copy of the file content,
|| but there is more than one directory entry, through which it can be
|| accessed. In *nix and VMS file systems the directory entries contain
|| the local name and the index into the disk area which contains the
|| file desciptors (timestamps, size, attributes, link count, and
|| location of the file body). In NTFS most (or all) of the file
|| descriptor is replicated for each directory entry made for the file.
|| As a consequence, when you change a timestamp or attribute of a file
|| using one of its directory entries, in *nix file systems all
|| directory entries are effectively updated instanyly, but in NTFS the
|| other entries are not updated automatically.
|
| Hm, this should lead to inconsistency (or much of work to
| synchronize between all entries) - for example, file can't have more
| than one size.
It does. For example, I tried (using JP Software's 4nt) to copy files to a
backup drive only if A is set, and clear A, hoping that this would not make
multiple copies of hard linked files. It did not work. In the WinXP
implementation of NTFS (the only one I have access to) the hard linked
directory entries are updated only AFTER they are specifically accessed. As
a consequence when you update a file using one of its links, searching for
newly updated files will not report its other links. *nix FS is organized
differently, so making any change to a file with multiple links updates the
directory information for all. OTOH by default *nix file systems consider a
file to be modified when you change only one of its attributes, so a new
copy of a 1980 telephone directory would show today as its modification
date.
| [...]
| Thanks for explanation.
You are welcome.
--
Steve
Steve Fabian
| Hi!
|
| Bartosz Polednia 08.02.08 11:02 wrote:
|
|| >> (BTW, which difference between "symbolic" and "hard" links?)
|| Shortly, IMHO:
|| - softlink is as shortcut in Windows
|| if you delete it the target remains untouched
|| - if you delete hardlink then you delete the target also
|
| ...unless there exist another hardlink(s). In *ix there is count
| of links to file in file index block, and file deleted only when
| counter decreased to zero.
NTFS also keeps a count (though I do not know whether or not it is stored in
the NTFS equivalent of the file index block) and retains file content until
link count is 0. Not true of VMS (1999 vintage) - see my other post.
|
|| You should not forget that files in *ix are not physically deleted
|| until they are opened by other users so it means that file is
|| accessible by them till they close the file - rm operation is
|| "queued".
Actually you do not need to try to open the file. File content deletion is
prevented or postponed if any process has the file open (including the one
requesting the deletion in an OS call that does not also include request to
close it). Once no process has the file open its deletion can proceed
immediately. Postponing until another user tries to open it could retain the
file forever.
|
| In DOS/Windows with (V)SHARE loaded deletion for opened file will
| fail (and I think, this is more wise, than pending delete operation).
| But I hear (although not investigate myself) old versions of PKZIP
| create temporary files and delete them immediately, which then wiped
| by OS when file closed.
AFAIK in any OS a request to delete a file (or its last remaining link) when
it is not open is performed immediately (though the physical change to the
disk might be slightly delayed due to buffering = caching). If the OS
supports automatic "wiping" (i.e., overwriting the original file body at
least once with a pattern intended to prevent recovering "deleted" but not
erased data) that is done as part of the file deletion.
--
Steve
Arkady V.Belousov
Philip Nienhuis 08.02.08 15:50 wrote:
> Symbolic links in NTFS under WinXP, in the form of dedicated file system
> structures that you seem to indicate, are easily confused with e.g.,
> Windows shortcuts ("Shortcut to") that can point to about anything.
> The easiest example is a Windows desktop or Start Menu shortcut, which
> can point to a file (e.g., "explorer.exe") as well as a directory (e.g.,
> the Control Panel) -
CP isn't directory, but specific object, recorded in registry. Explorer
allows to make link to registry entry through specific file suffix - e.g.,
"Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}". To say more
precisely, Explorer handles file system names with such suffix in special
manner - it hides suffix and redirects name to consequent special object
(Control Panel, Recycle Bin, etc.). This interpretation specific to Explorer
and independent from file system.
> either of which can be on any volume, even across
> network connections, on any Windows version from '95 to Vista.
> Oh and such shortcuts work from and to (V)FAT file systems, too.
Because they are plain files, which interpreted and redirected by
Explorer only, without any help from file system. :)
> So I tend to conclude that:
> 1. Physically, symbolic links can simply be a file with special contents;
> 2. Functionally, symbolic links in a file system are not a feature of a
> file system alone but rather a feature of the combination of file system
> AND implementation of the file system driver. That is quite unlike hard
> links.
Thanks for explanation.
> To go on, I can't see any reason why a (V)FAT file system wouldn't
> support hard links (in the sense of multiple directory entries with
> (optionally!) the same meta-info pointing to the same chain of blocks).
It can't. By definition of file system structure - all file/directory
attributes (including starting position and size) are reside in directory
entry. With help of external resident utilities (like APPEND, JOIN, LN) you
may implement/imitate symbolic links, but (as me already agreed) hard links
are inherent to file system and exist/supported without additional utilities.
Arkady V.Belousov
Steve Fabian 08.02.08 18:22 wrote:
> || FATnn and VFAT do not support any kind of links.
> | Of course. Except, that there is possible to imitate links by
> | external utilities - even original DOS includes APPEND, JOIN and
> | SUBST.
> True, but all 3 are for directories only,
APPEND is at file level. JOIN/SUBST - yes, for directories, but they in
DOS/Windows package (at least, subst available up to Vista), this is why I
mention them. But I know about LN utility 3rd party implementation.
> and are not stored in the file
> system (FS). Links are stored in the FS, and are processed by the OS.
Symbolic links may be (partially) provided in FS driver (like shortcuts
interpreted by Explorer). Though, I don't know how reliable will be working
of above mentioned 3rd party LN utility with disk checking utilities
(chkdsk, scandisk).
> directory information for all. OTOH by default *nix file systems consider a
> file to be modified when you change only one of its attributes, so a new
> copy of a 1980 telephone directory would show today as its modification
> date.
Copy is copy, this is not original file and file system doesn't know
that newly created file is precise copy. For this reason, it is copy utility
responsibility to copy attributes (including time stamps) together with file
content. Of course, FS driver should provide functions to set/modify
attributes, including time stamps - oh, how I hate that I can't preserve
time stamps of files, which I copy to FTP :(.
On the other side, I don't think that updating modification date after
modifying file attributes (like file name or RW/RO mark) is wise. And anyway
this is not FS, but FS driver behavior. I even doubt, that adding "when
attributes changed/file renamed" timestamp will be useful for anyone (except
of users A/B security class OSes).
Arkady V.Belousov
Steve Fabian 08.02.08 18:40 wrote:
> || You should not forget that files in *ix are not physically deleted
> || until they are opened by other users so it means that file is
> || accessible by them till they close the file - rm operation is
> || "queued".
> Actually you do not need to try to open the file. File content deletion is
> prevented or postponed if any process has the file open (including the one
> requesting the deletion in an OS call that does not also include request to
> close it). Once no process has the file open its deletion can proceed
> immediately. Postponing until another user tries to open it could retain the
> file forever.
I suggest, Bartosz words "not physically deleted until they are opened
by other users" probably are unexpected wrong wording. :)
> | create temporary files and delete them immediately, which then wiped
> | by OS when file closed.
> If the OS
> supports automatic "wiping" (i.e., overwriting the original file body at
> least once with a pattern intended to prevent recovering "deleted" but not
> erased data) that is done as part of the file deletion.
And above is mine wrong wording. :) :( Under "wipe" above I was meant
"actually deleted".
Steve Fabian
Neither one caused a problem, just gave a chance to discuss the topic in
greater depth.
--
Steve
Steve Fabian
| Hi!
|
| Steve Fabian 08.02.08 18:22 wrote:
|
|||| FATnn and VFAT do not support any kind of links.
||| Of course. Except, that there is possible to imitate links by
||| external utilities - even original DOS includes APPEND, JOIN and
||| SUBST.
|| True, but all 3 are for directories only,
|
| APPEND is at file level. JOIN/SUBST - yes, for directories, but
| they in DOS/Windows package (at least, subst available up to Vista),
| this is why I mention them. But I know about LN utility 3rd party
| implementation.
I have to contradict you about APPEND - it deals with drives and
directories, not files.
|
|| and are not stored in the file
|| system (FS). Links are stored in the FS, and are processed by the OS.
|
| Symbolic links may be (partially) provided in FS driver (like
| shortcuts interpreted by Explorer). Though, I don't know how reliable
| will be working of above mentioned 3rd party LN utility with disk
| checking utilities (chkdsk, scandisk).
Unless it is stored in the FS, it is not dependable.
|| directory information for all. OTOH by default *nix file systems
|| consider a file to be modified when you change only one of its
|| attributes, so a new copy of a 1980 telephone directory would show
|| today as its modification date.
|
| Copy is copy, this is not original file and file system doesn't
| know that newly created file is precise copy. For this reason, it is
| copy utility responsibility to copy attributes (including time
| stamps) together with file content. Of course, FS driver should
| provide functions to set/modify attributes, including time stamps -
| oh, how I hate that I can't preserve time stamps of files, which I
| copy to FTP :(.
If you use *nix-to-*nix transfer, you can use instead rcp, which provides
the option (but not thedefault behavior) for "modification time" to refer
exclusively to file content. If your local and remote systems are both
Windows, you can use JP Software's 4NT or TCMD command processors, which
perform ftp transfers with modification timestamp preservation.
| On the other side, I don't think that updating modification date
| after modifying file attributes (like file name or RW/RO mark) is
| wise. And anyway this is not FS, but FS driver behavior. I even
| doubt, that adding "when attributes changed/file renamed" timestamp
| will be useful for anyone (except of users A/B security class OSes).
I agree.IMHO there should be several timestamps associated with a file, to
wit: creation of current copy, modification of file content, modification of
file attributes, last access to file content (read or write), last access to
file attributes (read or write).
--
Steve
Arkady V.Belousov
Steve Fabian 08.02.08 21:47 wrote:
> | APPEND is at file level. JOIN/SUBST - yes, for directories, but
> I have to contradict you about APPEND - it deals with drives and
> directories, not files.
It adds directories to search list, but in these directories it
searches files.
> || and are not stored in the file
> || system (FS). Links are stored in the FS, and are processed by the OS.
> | Symbolic links may be (partially) provided in FS driver (like
> | shortcuts interpreted by Explorer). Though, I don't know how reliable
> | will be working of above mentioned 3rd party LN utility with disk
> | checking utilities (chkdsk, scandisk).
> Unless it is stored in the FS, it is not dependable.
It _is_ dependable - disk checking utility in general can't use INT13
or even INT25/INT26 (consider compressed drives like Stacker or D*Space,
which are connected through "network interface") and may be fooled by links
imitation utility (with which checking utility will then find multiple
references to common clusters chain). With APPEND situation is easier -
there is known API to turn it off and APPEND, AFAIK, doesn't affect
findfirst/findnext.
> | oh, how I hate that I can't preserve time stamps of files, which I
> | copy to FTP :(.
> If you use *nix-to-*nix transfer, you can use instead rcp, which provides
> the option (but not thedefault behavior) for "modification time" to refer
> exclusively to file content. If your local and remote systems are both
> Windows, you can use JP Software's 4NT or TCMD command processors, which
> perform ftp transfers with modification timestamp preservation.
In my case remote ftp server doesn't even support UMOD command (me was
explained, that this nonstandard ftp protocol extension is only way to
modify timestamp).
> | On the other side, I don't think that updating modification date
> | after modifying file attributes (like file name or RW/RO mark) is
> | wise. And anyway this is not FS, but FS driver behavior. I even
> | doubt, that adding "when attributes changed/file renamed" timestamp
> | will be useful for anyone (except of users A/B security class OSes).
> I agree.IMHO there should be several timestamps associated with a file, to
> wit: creation of current copy, modification of file content, modification of
> file attributes, last access to file content (read or write), last access to
> file attributes (read or write).
Let me repeat: for plain OS/users is enough "content modified" and,
very probable, "file created" timestamps.
File access timestamps ("file read" and "file listed"/"attribute(s)
read") may/should be useful for OSes with C and even higher security classes
- on lower classes, where viewing directories (and reading files parts) by
DIR command or shells like Norton Commander, XTree or Explorer is regular
operation, these timestamps practically useless and only give unnecessary
massive write load on file storage.
Attributes access timestamps (for all at once or for each individually)
- "attribute created" (for individual user defined attributes),
"attribute(s) modified" and above mentioned "attribute(s) read" for lower
securty classes (plain desktops) are also useless. May you explain me, why
YOU (as individual, not as manager of high security systems in Department of
Defense) may NEED information, when file was renamed?
Steve Fabian
| Hi!
|
| Steve Fabian 08.02.08 21:47 wrote:
|
||| APPEND is at file level. JOIN/SUBST - yes, for directories, but
|| I have to contradict you about APPEND - it deals with drives and
|| directories, not files.
|
| It adds directories to search list, but in these directories it
| searches files.
Or subdirectories. Any symbolic link of directories serves the same
purpose - make a directory's content available through a symbolic link. But
the append, join, subst informaiton is dynamic - you restart the system,
it's gone! It needs to be rebuilt for each system start. Hard and symbolic
links of *nix and NTFS are permanent - it is stored in the FS. You can
physically move the drive to a different computer, and it will still be
there (though some symbolic link types depend on absolute paths, so
reassigning a Windows drive letter would destroy their usability).
|||| and are not stored in the file
|||| system (FS). Links are stored in the FS, and are processed by the
|||| OS.
||| Symbolic links may be (partially) provided in FS driver (like
||| shortcuts interpreted by Explorer). Though, I don't know how
||| reliable will be working of above mentioned 3rd party LN utility
||| with disk checking utilities (chkdsk, scandisk).
|| Unless it is stored in the FS, it is not dependable.
|
| It _is_ dependable - disk checking utility in general can't use
| INT13 or even INT25/INT26 (consider compressed drives like Stacker or
| D*Space, which are connected through "network interface") and may be
| fooled by links imitation utility (with which checking utility will
| then find multiple references to common clusters chain). With APPEND
| situation is easier - there is known API to turn it off and APPEND,
| AFAIK, doesn't affect findfirst/findnext.
The question of dependability, as I used it, refers to whether or not you
need to execute certain operations each time the system start up in order to
regain the connectivity they represent. Links stored by the FS do not depend
on that.
...
| In my case remote ftp server doesn't even support UMOD command
| (me was explained, that this nonstandard ftp protocol extension is
| only way to modify timestamp).
Yes, the file transfer protocol developed by the Unix folks decades ago is
very porr quality. It is based on the concept that timestamps are of no
great importance. The concept is wrong, esp. for distributed systems. If 3
ftp servers have copies of the same file, each with the timestamp not of the
version they have available, but of the local time on the server of when the
specific copy was received by the server, how can I determine which is the
latest? Only through information external to the file and file system. The
schem was workable when Unix was a project with just a few Bell Telephone
Laboratories employees using it, but not on the world-wide web.
| ...
| Attributes access timestamps (for all at once or for each
| individually) - "attribute created" (for individual user defined
| attributes), "attribute(s) modified" and above mentioned
| "attribute(s) read" for lower securty classes (plain desktops) are
| also useless. May you explain me, why YOU (as individual, not as
| manager of high security systems in Department of Defense) may NEED
| information, when file was renamed?
Only for security purposes - but not just for military, but also for medical
information, financial information, etc.. It's when the FS or the OS
confuses content change and attribute change and considers both to be
modification the issue comes up. From what I read in your posts, you andI
agree - for normal use content modification is the only issue of
significance. Access time is useful to know whether or not to delete
something as no longer used.
--
Steve
Arkady V.Belousov
Steve Fabian 09.02.08 0:02 wrote:
> | It adds directories to search list, but in these directories it
> | searches files.
> Or subdirectories.
Only files - APPEND implicitly searches files, which requested to open,
in given directories list (after current directory). In theory, this was
developed to simplify porting of old DOS programs, which was written for
MS-DOS 1.x, where were no directories.
> Any symbolic link of directories serves the same
> purpose - make a directory's content available through a symbolic link. But
But explicitly, through (new) name of directory. In case of APPEND,
_content_ of listed directories "appended" to directory, which is current.
> the append, join, subst informaiton is dynamic - you restart the system,
> it's gone!
Of course. But, as Philip pointed out, symbolic links on ext2/3 under
Windows don't work too. :)
> It needs to be rebuilt for each system start.
Of course. But in given case this is irrelevant - we discuss
environment, which created by these utilities (when they already run -
manually or automatically through autoexec.bat/autostart). Same, as with
shortcuts, which works only in Explorer.
> |||| and are not stored in the file
> |||| system (FS). Links are stored in the FS, and are processed by the
> |||| OS.
> ||| Symbolic links may be (partially) provided in FS driver (like
> ||| shortcuts interpreted by Explorer). Though, I don't know how
> || Unless it is stored in the FS, it is not dependable.
> The question of dependability, as I used it, refers to whether or not you
> need to execute certain operations each time the system start up in order to
> regain the connectivity they represent. Links stored by the FS do not depend
> on that.
They *do* depend - at least from FS driver, because it is driver does
support for FS structure and consistency. Let me again remind Philip's
example, that under Windows symbolic links on ext2/3 don't work. Simpler
example: some (exotic) FATxx driver implementation may change "file
modified" timestamp each time, when you rename file; and vice versa - other
exotic implementation may not touch file timestamps at all. Resume: even if
symbolic links (partially) stored in FS, this doesn't mean that specific
driver will support them.
Let me remind context of this issue:
you: FATnn and VFAT do not support any kind of links.
me: Of course. Except, that there is possible to imitate links by
external utilities - even original DOS includes APPEND, JOIN and SUBST.
you: True, but all 3 are for directories only, and are not stored in the
file system (FS). Links are stored in the FS, and are processed by
the OS.
me: Symbolic links may be (partially) provided in FS driver (like shortcuts
interpreted by Explorer).
you: Unless it is stored in the FS, it is not dependable.
(I suggest, in last sentence you mean "Until", not "Unless"). As I already
say above, in given case presence of information about symlinks in FS is
irrelevant, especially I note, that mentioned utilities *imitate* links.
On the other side, as seen from your explanations, hard links are
inherent, unavoidable part of FS, whereas symlinks are additional service
over FS, which may or may not (especially because links may follow to
different volumes) tracked in FS structures. Thus, hard links should be
supported by any FS driver implementation, whereas symlinks support is
optional and may (or even should, as in case of symlinks between different
volumes) moved to higher layers (e.g., SUBST). This makes word "dependable"
regarding symlinks senseless.
> | In my case remote ftp server doesn't even support UMOD command
> Yes, the file transfer protocol developed by the Unix folks decades ago is
> very porr quality.
I think, some other *ix properties (like case sensitive file systems
and C as base language) are too bad choice... :( :)
> | "attribute(s) read" for lower securty classes (plain desktops) are
> | also useless. May you explain me, why YOU (as individual, not as
> | manager of high security systems in Department of Defense) may NEED
> | information, when file was renamed?
> Only for security purposes - but not just for military, but also for medical
> information, financial information, etc..
Of course. I mention DoD only as example, whereas security (protection
and detection against casual or malevolent intrusion) important in any area,
related to humans life (medical), finances, defences (government or
corporative), etc. Pay for security (some loss of speed, restricted access
even for own data, extra authentication) is usually unacceptable or
unnecessary for individual end users. (On the other side, total miss of
security and working discipline/"hygiene" leads to virus epidemics, identity
thefts and wide distribution of C language).
> It's when the FS or the OS
> confuses content change and attribute change and considers both to be
> modification the issue comes up. From what I read in your posts, you andI
> agree - for normal use content modification is the only issue of
> significance.
Yes.
> Access time is useful to know whether or not to delete
> something as no longer used.
Access (content read?) timestamp as indicator of what not used and may
be deleted? Bad indicator.
Let me again remind, that in low security systems listing and reading
files (by Explorer, antivirus scanners, etc.) is regular operation, and
updating "accessed" timestamp at them makes heavy write load (especially
many packages, like games and Windows itself, contain many thousands files
per some directories).
No, user may decide which his file is obsolete only grounding on
modification timestamp and viewing file content. Unfortunately, even
modification timestamp often useless: common wide users practice with, say,
copying Word files is to open file in Word and re-save (without
modifications) it to new place, whereas Word (and all known to me editor)
don't preserve modification timestamp (and even binary content equality!) in
such copying procedure.
Bartosz Polednia
I would like to bring out the word: *Shortly*
Bartosz