Re: How to get started
Arend Lammertink <[email protected]> Mon, 1 Dec 2003 15:24:55 +0100
| Newsgroups | gmane.linux.debian.ports.windows |
|---|---|
| Message-ID | <[email protected]> |
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 spec= ial > > dpkg binary that executes on reboot that moves files from a temporary > > folder to the installation location. It could either be registered t= o > > 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=20 won't need much more then dpkg itself, a shell, tar, gzip.=20 So, you could make a dkpg-sys directory that is only used by dpkg, so tha= t=20 dpkg can update at least the rest of the system. Of course, that would require closing all your applications while upgradi= ng. The next idea that comes to mind is using symlinks. So, instead of having= a=20 sh.exe, you would have a sh.version.exe and a symlink to the latest versi= on. 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=20 http://winext2fsd.sourceforge.net/ ,=20 http://uranus.it.swin.edu.au/~jn/linux/ext2ifs.htm and http://sys.xiloo.c= om/=20 / 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 syste= m.=20 We would be sure the remote system would have no problem replacing a file= =20 that is in-use. Would win32 complain about replacing locally open files o= n=20 such a remote filesystem? In other words: are we facing a limitation of the OS itself, or is it 'ju= st'=20 a matter of chosing the right filesystem? In case a different filesystem would be the answer, which fs should we ch= oose? I guess a fs that could be shared between win32/Linux would be ideal. Regards, -- Arend -- --=20 To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]= .org