Hi,Bill Davidsen wrote: Since I never get an error I would suspect that the change is not detected, the only question is if the data saved is only that which was originally expected, or all available.To my theory the effect should occur whenever filesize div 32768 yields a lower result at reading time than at the time when the extends were scheduled. It is not very unlikely to happen, but up to now it resulted in a silent abort of mkisofs. It's just that a reasonable person does not backup agile parts of the disk via mkisofs directly. (I was doing an experiment for evaluating a user's error message. So i did things which i never had done on my own before.)
Unless you have the luxury of taking the system to single user mode, it is always possible that you should have a file change. But in the case of a moving target you are always taking a snapshot in time of the data, and therefore robust behaviour is desirable, since you always backup then rather than now. I would be perfectly happy to have the file truncated or ignored, but having the backup fail, particularly without an error status, is just the mark of clumsy programming.
I seriously doubt thaere's a totally satisfactory way to do this, however a stat and compare of the mtime would catch files which are likely to be an issue, although obviously not every possible case.I suggest that if the size changes during backup it should be noted but should not be a fatal error, since mkisofs is used on live data and should be robust in practice.I considered to propose Joerg a stat() before fopen(). But shrinking is not the only menace for a file in this situation. There may occur any kind of content inconsistency if a file changes while it is copied. My next idea was to propose MD5 sums generated at scheduling time. But that would imply to read the files twice and still would not close all time windows for inconsistencies and race conditions.
But it is virtually the only suitable tool for general portability between hardware and O/S environments. And for general backup, it offers far faster access to files it the most common case, that in which a small number of files must be restored. Since no list of files to ignore can be complete for more than a point in time, and there's currently no option in mkisofs (or any other widely used backup) to just mark any file which has changed as zero length but preserve ownership and permissions, it is useful in most general backup situations as well.So i think it's best if mkisofs only cares for its own survival in respect to readability of files. I appreciate if it aborts on obviously dangerous changes but do not rely on that fact. And i tell my users not to do so either. >From the point of view of mkisofs it might even be a better behavior not to abort at all but to pad up the missing bytes. (This is done currently inadvertedly if the shrinking does not change the filesize div 32768.) It would be an elegant way to avoid the need to invent an appropriate pseudo error.Joerg Schilling wrote : mkisofs is not a backup tool.It is not an appropriate tool for general backup situations.
DAT tapes (still use them for compatibility) were fine for saving and restoring a load of data as an indivisible unit. As you imply and I agreed above, any sequential data format is undesirable for applications requiring access to individual files.But it produces very versatile backups of user data files, especially of home directory trees and multi-media collections. With such data it solves two very old and very annoying problems of classical backups : ease of retrieval and subjective trust. Ease of Retrieval : Good backup media got big capacity and therefore long runtimes. Good general backup formats usually got a sequential structure and therefore require scanning of a substantial part of a backup volume in order to retrieve a file. With a DVD, such a scan run can last 5 to 10 minutes. Reminds me of the bad old times of DAT tapes.
I would have loved to have star 15 years ago. I wouldn't use any solution today which required reading the whole data set to extract things, was not portable, and which is not cost effective in terms of timeto recovery. Star represents the best implementation ever written of an obsolete method of backup, and I can't think of any reason other than "someone paid me to do it" why I would use star or any similar thing for backup.Subjective Trust: Speaking of the bad old DAT times : how could one make sure for oneself (not for the checkread mode of the backup software) that this backup will be usable in case of emergency ? >From time to time i have to explain users that it is *not* an appropriate test for a backup to restore it over the healthy production files. Most of them wish a less dramatic way to get a good feeling about their backup, though. And here mkisofs is great. You can open the files with the application software which knows how to handle them and which (hopefully) can tell you wether they are undamaged. Different from other filesystems (like ext2) there is a convenient way to generate ISO images on the fly. Yes. mkisofs is a bit pre-alpha in certain situations which occur often in certain system directories. But in other situations which occur often with real life user directories, it was a revolutionary opportunity for backups when i encountered it in the late 1990s. A mountable random access backup that *works*. Gosh.If you like to do backups, use apropriate tools (e.g. star).I will have to RTxy about star in order to find out which of the challenges of backuping it promises to handle.
Have a nice day :)
I fear that neither your opinion nor mine will improve Jǒrg's day. I'm sorry about that, but people use software which does what they need, not something neat but unsuitable.
-- bill davidsen <firstname.lastname@example.org> CTO TMR Associates, Inc Doing interesting things with small computers since 1979