> From: [EMAIL PROTECTED]
> Message-Id: <[EMAIL PROTECTED]>
> >> The file is already open, so this is a bug in the OS.
>
> > Or he was backing up a live system and mail came in (or was read or
> >whatever). Having a file locked or truncated while backing it up makes
> >it unreadable. Doing backups on a live system is a bug in the user.
>
> A OS that works as expected does not remove files that are open.
> For this reason, it is impossible that the error code
> "No such file or directory." is retrurned when a read request has been issued.
It is obviously a Windows filesystem, "works as expected" and "does it
wrong" are the same thing in that case... That's why I was hoping he
would tell me this is SMB mounted and live, explaining the problem.
Actually, most version of UNIX *do* delete the file, preventing
reopen, and only preserve the file allocation until the last close. You
might test to see if Solaris works that way, it might surprise you to
see that an open file is deleted from the directory, even though the
contents are intact for existing opens. The open by name may not have
taken place when you think.
Test:
date >f.tmp; (ls -l f.tmp; rm f.tmp; ls -l f.tmp; cat) < f.tmp
Should display the directory entry, then not display the entry, then
display the contents (date) just fine.
In any case, he *can't* use an OS without the bug, this is a Windows
filesystem, and no one would use Windows if they had an option (would
they?).
--
-bill davidsen ([EMAIL PROTECTED])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
