Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
hasse69 opened this issue Mar 13, 2015 · 8 comments
Closed

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

hasse69 opened this issue Mar 13, 2015 · 8 comments
Labels
Defect Priority-Medium

Comments

@hasse69
Copy link
Owner

hasse69 commented Mar 13, 2015

What steps will reproduce the problem?

  • I explain whole steps to reproduce this issue.
  • 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
  • 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
  • mount that archive using rar2fs.
localhost rar2fs # mkdir TEST
localhost rar2fs # rar2fs -o allow_other,ro RAR.rar TEST/
  • 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 jyhpsycho on 2014-07-01 11:16:23
@hasse69 hasse69 closed this as completed Mar 13, 2015
@hasse69
Copy link
Owner Author

hasse69 commented May 24, 2015 

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 issue reported on code.google.com by jyhpsycho on 2014-07-01 11:18:44

@hasse69
Copy link
Owner Author

hasse69 commented May 24, 2015 

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 issue reported on code.google.com by jyhpsycho on 2014-07-10 10:22:02

- _Attachment: [rar2fs-preserve-link-stat.patch](https://storage.googleapis.com/google-code-attachments/rar2fs/issue-35/comment-2/rar2fs-preserve-link-stat.patch)_

@hasse69
Copy link
Owner Author

hasse69 commented May 24, 2015 

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 issue reported on code.google.com by hans.beckerus on 2014-07-14 09:40:04

@hasse69
Copy link
Owner Author

hasse69 commented May 24, 2015 

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 issue reported on code.google.com by hans.beckerus on 2014-07-15 16:31:55

@hasse69
Copy link
Owner Author

hasse69 commented May 24, 2015 

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 issue reported on code.google.com by hans.beckerus on 2014-07-15 20:52:10

@hasse69
Copy link
Owner Author

hasse69 commented May 24, 2015 

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

Original issue reported on code.google.com by hans.beckerus on 2014-07-16 21:25:44

@hasse69
Copy link
Owner Author

hasse69 commented May 24, 2015 

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

Original issue reported on code.google.com by jyhpsycho on 2014-08-14 18:28:29

@hasse69
Copy link
Owner Author

hasse69 commented May 24, 2015 

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 issue reported on code.google.com by hans.beckerus on 2014-08-14 18:59:43

@Nischi85 Nischi85 mentioned this issue Oct 9, 2022
Closed
fdegros pushed a commit to fdegros/rar2fs that referenced this issue Nov 29, 2023
@hasse69
Bug fixes and updates.
062eb73 
* [rar2fs hasse69#37]

  Fixed a potential memory leak when compiling against
  libunrar versions prior to 4.2.0.

* Fixed a potential memory leak in the collect_files()
  function. This function is only used when mounting
  single RAR archives which means it is rather harmless.

* Simplified code in function dir_entry_add_hash().

* Changed implementation of utimens

* [rar2fs hasse69#35]

  Fixed a problem with RAR5 stats that were incorrectly
  inherited for file reference links.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
Defect Priority-Medium
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@hasse69