>>> DONT BACKUP VFAT INCREMENTALLY
>>> There is only one date on a file on a VFAT partition and as
>>> every command down to the DOS copy command preserves that date
>>> you cannot see what's been changed.
>>> Hopefully the ctime is being set to now (or now-1); this is the
>>> _right_ thing to do.
>>> There is a good feature of VFAT (I _DONT_ believe it !!! a GOOD
>>> feature in VFAT!!!!!!!) in the archive bit. This would provide
>>> reliable incrememtal backups ... but it can't be mapped onto
>>> Unix semantics.
>> Depends what you mean by 'mapped' actually. My suggestion would be
>> to use it to determine the mtime to be presented, according to the
>> following rules:
>> 1. If the archive bit is set, anything asking for the mtime
>> gets one of the following:
>>
>> a. The current time.
>>
>> b. The latest of the system boot time and the ctime time.
>>
>> Which is chosen would depend on the exact semantics required.
>>
>> 2. If the archive bit is clear, anything asking for the mtime
>> always gets the ctime time.
>> Perhaps somebody can advise what is wrong with that?
>> The only possible problem I can see is in the fact that there would
>> have to be some means to turn the archive flag off that worked with
>> the various backup programs and was consistant with the semantics
>> used.
> Have you got confused about ctime vs mtime ?
Mind if I repeat your comment as quoted above:
>>> There is only one date on a file on a VFAT partition...
Can I also point out that as far as backup programs are concerned,
they will consider a file as being a candidate for inclusion in an
incremental backup if the MODIFICATION time is more recent than the
timestamp the previous backup that it's incremental to. From their
perspective, the ctime is irrelevant.
Remember that under MSDOS, the purpose of the archive bit is to state
that the file has not been backed up since it was last modified, and
thus that the modification time is more recent than the last backup.
> But yes you could do:
> mtime = dos_mtime
> ctime = arch?now:dos_mtime
> atime = dos_mtime
If you think about the semantics, you'll realise that's wrong. First,
let's remind ourselves what the various timestamps are:
1. ctime is the time when the file was first created.
2. mtime is the time when the file was last modified.
3. atime is the time when the file was last accessed.
Therefore, the following relationship MUST hold...
ctime <= mtime <= atime
...since a file can be neither modified nor accessed before it is
created, and modifying a file also constitutes accessing it.
I would therefore see something like...
ctime = dos_time
mtime = archivable ? now : ctime
atime = mtime
...as being the correct semantics.
> But how do you reset the Arch bit ?
I can see the following options:
1. Have the code check whether a file is accessed sequentially
from start to finish without missing anything out or reading
anything twice, and without being modified, and if so, assume
the program doing so just created a backup of the file, so
reset the archivable bit when the file is closed.
2. Have a special flag to be applied by the backup program when
opening a file it wishes to back up, which indicates that it
is backing up the file.
3. Ignore the problem completely.
None of them particularly appeals to me, as I can see serious problems
with both, but I can't see anything better either...
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/Linux/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/