ru.unix.bsd

 
 - RU.UNIX.BSD ------------------------------------------------------------------
 From : Vadim Goncharov                      2:5020/400     12 Feb 2006  14:58:58
 To : Eugene Grosbein
 Subject : Re: время на FFS
 -------------------------------------------------------------------------------- 
 

 Hi Eugene Grosbein! 
 
 On Sun, 12 Feb 2006 15:29:35 +0300; Eugene Grosbein wrote about 'Re: время на
 FFS':
 
  EG>>> -rw-r--r--  1 root  wheel  0  1 янв 06:59:00 1970 l
  EG>>> # env TZ=UTC ls -lT l
  EG>>> -rw-r--r--  1 root  wheel  0 31 дек 23:59:00 1969 l
  EG>>> # tar cf l.tar l
  EG>>> archive_write_pax_header: 'x' header failed?!  This can't happen.
  EG>>> Это на шестерке с ее bsdtar.
  EG>>> Hа четверке GNU tar отрабатывает.
  EG>>> Вопрос: в каком формате хранит FFS дату?
  VG>> UFS1 или UFS2 ?
  EG> Если есть разница, расскажи про обе.
 
 В UFS2 поменяли формат хранения времени на диске, расширив до 64 бит.
 Из Design and Impmentation of FreeBSD Operating System (правда, слегка
 устарело и по твоему конкретному вопросу туманно):
 
 Several other improvements were made when the enlarged inode format was
 created. We decided to get an early jump on the year 2038 problem when
 the 32-bit time fields overflow (specifically, Tue Jan 19 03:14:08 2038
 GMT, which could be a really ugly way to usher in the first author's
 84th birthday). We expanded the time fields (which hold
 seconds-since-1970) for access, modification, and inode-modification
 times from 32 bits to 64 bits. At plus or minus 136 billion years that
 should carry us from well before the universe was created until long
 after our sun has burned itself out. We left the nanoseconds fields for
 these times at 32 bits because we did not feel that added resolution was
 going to be useful in the foreseeable future. We considered expanding
 the time to only 48 bits. We chose to go to 64 bits, since 64 bits is a
 native size that can be easily manipulated with existing and likely
 future architectures. Using 48 bits would have required an extra
 unpacking or packing step each time the field was read or written. Also,
 going to 64 bits ensures enough bits for all likely measured time so it
 will not have to be enlarged.
 
 We also added a new time field (also 64 bits) to hold the birth time
 (also commonly called the creation time) of the file. The birth time is
 set when the inode is first allocated and is not changed thereafter. It
 has been added to the structure returned by the stat system call so that
 applications can determine its value and so that archiving programs such
 as dump, tar, and pax can save this value along with the other file
 times. The birth time was added to a previously spare field in the stat
 system call structure so that the size of the structure did not change.
 Thus, old versions of programs that use the stat call continue to work.
 
 To date, only the dump program has been changed to save the birth time
 value. This new version of dump, which can dump both UFS1 and UFS2
 filesystems, creates a new dump format that is not readable by older
 versions of restore. The updated version of restore can identify and
 restore from both old and new dump formats. The birth times are only
 available and setable from the new dump format.
 
 -- 
 WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
 [Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
 --- slrn/0.9.8.1 on FreeBSD 4.11/i386
  * Origin: Nuclear Lightning @ Tomsk, TPU AVTF Hostel (2:5020/400@fidonet)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор