rar2fs returns wrong timestamp for file using "store identical file as references" feature.

[GoogleCodeExporter]

What steps will reproduce the problem?

 - I explain whole steps to reproduce this issue.

1. Create following hierarchy.

localhost rar2fs # l -R RAR
RAR:
total 0
drwxr-xr-x 2 root root 60 2014-07-01 19:52:16.644092426 +0900 BASE/
drwxr-xr-x 2 root root 60 2014-07-01 19:52:31.117426015 +0900 LINK/

RAR/BASE:
total 1932
-rw-r--r-- 1 root root 1977432 2013-12-01 17:09:04.000000000 +0900 
winrar-x64-501.exe

RAR/LINK:
total 1932
-rw-r--r-- 1 root root 1977432 2014-07-01 19:53:15.084093461 +0900 
winrar-x64-501.exe

2. Create archive using following command.
 * NOTE : I used Windows version of RAR as reference.
          -oi:0 option scans any size of identical file.
localhost rar2fs # WINEPREFIX=/mnt/WINRAR_ROOT wine 'C:\Program 
Files\WinRAR\Rar.exe' a -ma5 -m0 -oi:0 RAR.rar RAR

3. mount that archive using rar2fs.

localhost rar2fs # mkdir TEST
localhost rar2fs # rar2fs -o allow_other,ro RAR.rar TEST/

4. Print file list.

localhost rar2fs # l -R TEST/RAR
TEST/RAR:
total 16
drwxr-xr-x 2 root root 4096 2014-07-01 19:52:16.644092400 +0900 BASE/
drwxr-xr-x 2 root root 4096 2014-07-01 19:52:31.117426000 +0900 LINK/

TEST/RAR/BASE:
total 1932
-rw-r--r-- 1 root root 1977432 2013-12-01 17:09:04.000000000 +0900 
winrar-x64-501.exe

TEST/RAR/LINK:
total 1932
-rw-r--r-- 1 root root 1977432 2013-12-01 17:09:04.000000000 +0900 
winrar-x64-501.exe

What is the expected output? What do you see instead?

 - LINK/winrar-x64-501.exe must have timestamp as '2014-07-01 19:53:15.084093461 +0900', but it reports ' 2013-12-01 17:09:04.000000000 +0900' as referenced target(original file)'s timestamp.

What version of the product are you using? On what operating system?

 - OS: Gentoo x86-64

# rar2fs -V
rar2fs v1.20.0 (DLL version 6)    Copyright (C) 2009-2014 Hans Beckerus
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under
certain conditions; see <http://www.gnu.org/licenses/> for details.
FUSE library version: 2.9.3
fusermount version: 2.9.3
using FUSE kernel interface version 7.19

# emerge --search unrar
Searching...    
[ Results for search key : unrar ]
[ Applications found : 3 ]

*  app-arch/unrar
      Latest version available: 5.1.5
      Latest version installed: 5.1.5
      Size of files: 210 kB
      Homepage:      http://www.rarlab.com/rar_add.htm
      Description:   Uncompress rar files
      License:       unRAR

 - NOTE : Provided version by gentoo portage sysetm is not recent version(5.1.6), but I tested with 5.1.6 manually. It has same problem, too.

Please provide any additional information below.

 - unrar included in libunrar package extracts contents with correct timestamp(1 second precision, though).
 - I'll attach sample file explained above.

Original issue reported on code.google.com by jyhpsy...@gmail.com on 1 Jul 2014 at 11:16

Attachments:

• RAR.rar

[GoogleCodeExporter]

There's some typo...

 LINK/winrar-x64-501.exe must have timestamp as '2014-07-01 19:53:15.084093461 +0900'

->

 LINK/winrar-x64-501.exe must have timestamp as '2014-07-01 19:53:15.084093400 +0900'

as RARv5 format stores timestamps by 100 nanosecond precision.

Original comment by jyhpsy...@gmail.com on 1 Jul 2014 at 11:18

[GoogleCodeExporter]

Proposed patch. It just set stat data for link after copying file cache. I 
don't understand rar2fs' logic perfectly, but I hope this patch may applied if 
there's no side effect related on this.

Original comment by jyhpsy...@gmail.com on 10 Jul 2014 at 10:22

Attachments:

• rar2fs-preserve-link-stat.patch

[GoogleCodeExporter]

Thanks for the patch. Will review it during the week. Due to unstable and 
sporadic internet connection I am currently unable to look at it.

Original comment by hans.bec...@gmail.com on 14 Jul 2014 at 9:40

[GoogleCodeExporter]

I am a little confused about this patch. If I read your report correctly 
LINK/winrar-x64-501.exe has the *same* timestamp as BASE/winrar-x64-501.exe. I 
though the whole idea of the store identical file as reference would be that 
they are the same, but maybe that is actually not the case.

Original comment by hans.bec...@gmail.com on 15 Jul 2014 at 4:31

[GoogleCodeExporter]

Look like a valid patch! It seems that file stats such as modified time stamp 
is not supposed to be inherited and should be unique.

Original comment by hans.bec...@gmail.com on 15 Jul 2014 at 8:52

[GoogleCodeExporter]

Patch applied.
Please test latest version in trunk and report back.

Original comment by hans.bec...@gmail.com on 16 Jul 2014 at 9:25

• Changed state: Fixed

[GoogleCodeExporter]

OK, trunk is work with libunrar 5.1.7. I guess it may works with older version 
of libunrar.

Original comment by jyhpsy...@gmail.com on 14 Aug 2014 at 6:28

[GoogleCodeExporter]

Thanks for the verfication. I would also guess that older version of libunrar 
should work due to the nature of the bug.

Case closed.

Original comment by hans.bec...@gmail.com on 14 Aug 2014 at 6:59

• Changed state: Verified