Message-Id: <200003052145.QAA16031@qnx.com> Subject: Re: DJGPP innovations ????? To: neldredge AT hmc DOT edu (Nate Eldredge) Date: Sun, 5 Mar 2000 16:45:15 -0500 (EST) From: "Alain Magloire" Cc: djgpp-workers AT delorie DOT com In-Reply-To: from "Nate Eldredge" at Mar 05, 2000 03:38:35 AM X-Mailer: ELM [version 2.5 PL0b1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: dj-admin AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > On Sun, 5 Mar 2000, Eli Zaretskii wrote: > > In all fairness, M$ is doing more than just symlinks: it also has some > > daemon program running in the background and actively looking for files > > that can be replaced by links to other files, thus freeing the disk > > space. The Daemon thing is another step nothing special about it, you start a cron job or any shell scripts. But to be able to this step the filesystem must have some sort of symlink or a way to redirect the lookup. > > > > IMHO, this is going to be one of those ``features'' people would love to > > turn off (e.g., what happens if you delete the sole copy of the file > > after the daemon linked half a dozen other files to it: does Windows then > > go back and automagically restore the original file it replaced with a > > link?). Having a third daemon going around nuking files, would open to many race conditions, presumably that is something you yould do at startup or shutdown. In a case of UNIX machine, in a late night batch job with exclusive file locking and disable pruning of NFS or removable media filesystem. You certainly do not want to make a link to your floppy drives files ;-). > Presumably it would be more like Unix hard links, where there is just a > link count. So the file disappears only when the last link is deleted. Agreed, this is the POSIX behaviour, where a file is deleted only after the reference count reach 0. Things like these will work fine : fd = open ("file", ...); unlink ("file"); /*remove the file from the filesystem name space */ write (fd, ....); read (fd, ...); close (fd) ; /* file is gone */ > But you'd also need something like copy-on-write to deal with one of the > files being modified, if you wanted it to be transparent. Why do you want COW (Copy On Write)? I would expect any modifications to be reflected on all the files. In the example below '-i' in 'ls' represents the i-node number. # # uname -sr SunOS 5.6 # echo "Hello World" > m # ls -li m 11979 -rw-rw-r-- 1 alain techies 12 Mar 5 16:54 m # ln m mm # ln m mmm # ls -li m mm mmm 11979 -rw-rw-r-- 3 alain techies 12 Mar 5 16:54 m 11979 -rw-rw-r-- 3 alain techies 12 Mar 5 16:54 mm 11979 -rw-rw-r-- 3 alain techies 12 Mar 5 16:54 mmm # echo "Hello World" >> m # ls -li m mm mmm 11979 -rw-rw-r-- 3 alain techies 24 Mar 5 16:55 m 11979 -rw-rw-r-- 3 alain techies 24 Mar 5 16:55 mm 11979 -rw-rw-r-- 3 alain techies 24 Mar 5 16:55 mmm # rm m rm: remove m (yes/no)? y # ls -li m mm mmm m: No such file or directory 11979 -rw-rw-r-- 2 alain techies 24 Mar 5 16:55 mm 11979 -rw-rw-r-- 2 alain techies 24 Mar 5 16:55 mmm # cat mmm Hello World Hello World If you do talk about COW, then you probably mean some Union File System where for example you could mount on the same mount point two filesystems. For example one is a CDROM and the other is the disk, both are mounted on /usr/local. So some files are readonly(the one on the CD), if edit the file on the CD the modified version will be save on the disk. Some OSs offer this type of Union filesystem(QNX/Neutrino and probably it is possible to have on the HURD, ..) -- au revoir, alain ---- Aussi haut que l'on soit assis, on n'est toujours assis que sur son cul !!!