From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Date: Sun, 22 Feb 2015 14:53:11 -0600 Message-ID: From: Steven Stallion To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1139872e4236f1050fb3790e Subject: [9fans] Odd dirwstat behavior Topicbox-Message-UUID: 45809266-ead9-11e9-9d60-3106f5b1d025 --001a1139872e4236f1050fb3790e Content-Type: text/plain; charset=UTF-8 9fans, Somewhat recently I've been doing some work to preserve older fs hierarchies. When running replica/pull I'm seeing something quite strange. Both the log and database are reporting the original (and correct) mtime for directories, however for some reason replica/applylog (or the filesystem) is setting the mtime to time(0). After digging through the applylog source, I found a couple of conditions that could cause this, however my modifications have been for naught. This is annoying as hell given the fact I'm going through this rigamarole to preserve permissions and dates. FWIW, replica/applylog is running against a fossil filesystem served out of devmnt with the following configuration: fsys main config fsys main open -APVW Any ideas? Steve --001a1139872e4236f1050fb3790e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
9fans,

Somewhat recently I've been = doing some work to preserve older fs hierarchies. When running replica/pull= I'm seeing something quite strange. Both the log and database are repo= rting the original (and correct) mtime for directories, however for some re= ason replica/applylog (or the filesystem) is setting the mtime to time(0). = After digging through the applylog source, I found a couple of conditions t= hat could cause this, however my modifications have been for naught. This i= s annoying as hell given the fact I'm going through this rigamarole to = preserve permissions and dates.

FWIW, replica/appl= ylog is running against a fossil filesystem served out of devmnt with the f= ollowing configuration:

fsys main config
fsys main open -APVW

Any ideas?

Steve
--001a1139872e4236f1050fb3790e--