Re: How to get started
- To: email@example.com
- Subject: Re: How to get started
- From: Arend Lammertink <firstname.lastname@example.org>
- Date: Mon, 1 Dec 2003 15:24:55 +0100
- Message-id: <E1AQoyt-0004OQ-PD@smtp5.home.nl>
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <3FCA13B5.email@example.com> <firstname.lastname@example.org>
On Sunday 30 November 2003 22:04, Junichi Uekawa wrote:
> > > Windows applications use the chance of rebooting to copy files
> > > that are previously used; thus dpkg and apt will probably
> > > need to use Windows reboots to get applications upgraded.
> > Yes, but only if the file is open in the first place. Perhaps a special
> > dpkg binary that executes on reboot that moves files from a temporary
> > folder to the installation location. It could either be registered to
> > always run or registered to run and remove itself from the registry.
> Note that most of the time, surprisingly many files are actually open.
> All the currently executing executables are 'open files'.
I guess renaming an open file is also not possible?
Perhaps dpkg could run with it's own separate set of executables. I guess it
won't need much more then dpkg itself, a shell, tar, gzip.
So, you could make a dkpg-sys directory that is only used by dpkg, so that
dpkg can update at least the rest of the system.
Of course, that would require closing all your applications while upgrading.
The next idea that comes to mind is using symlinks. So, instead of having a
sh.exe, you would have a sh.version.exe and a symlink to the latest version.
Since the symlink would not be open (would it???), it could be replaced.
However, this would be ugly, too.
But, how about using another filesystem, like ext2/3?
There are ext2 drivers available for win32, like
http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm and http://sys.xiloo.com/
/ http://sourceforge.net/projects/ext2fsd .
Could that filesystem be the answer?
Let's assume for a moment we would be using a samba mount as a file system.
We would be sure the remote system would have no problem replacing a file
that is in-use. Would win32 complain about replacing locally open files on
such a remote filesystem?
In other words: are we facing a limitation of the OS itself, or is it 'just'
a matter of chosing the right filesystem?
In case a different filesystem would be the answer, which fs should we choose?
I guess a fs that could be shared between win32/Linux would be ideal.
-- Arend --