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

Timestamp mismatch #29

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

Timestamp mismatch #29

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

Comments

@hasse69
Copy link
Owner

hasse69 commented Mar 13, 2015

What steps will reproduce the problem?

  1. Make some archive.
  2. Mount that archive.
  3. Compare timestamp using "ls --full-time".

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

That should be identical. But, rar2fs returns wrong timestamp. Its differences are several seconds. On Linux, Linux version of rar treats timestamps only second-precision, but that's value are correct. Using Windows version of WinRAR with WINE, It handles 100-nanosecond precision and extracts correctly.

Original file :

-rw-r--r--  1 root   root  23501538393 2013-08-30 15:26:06.012630700 +0900 Vol.1.rar
-rw-r--r--  1 root   root  22110405466 2013-09-19 19:52:26.124659000 +0900 Vol.2.rar
-rw-r--r--  1 root   root  22274030773 2013-10-27 14:54:30.477460700 +0900 Vol.3.rar
-rw-r--r--  1 root   root  20987668628 2013-11-09 09:17:06.154892900 +0900 Vol.4.rar
-rw-r--r--  1 root   root  22540994209 2014-01-27 13:10:39.901638700 +0900 Vol.5.rar
-rw-r--r--  1 root   root  23608165738 2014-01-27 09:21:30.425213700 +0900 Vol.6.rar

rar2fs' output :

-rw-r--r--  1 root   root  23501538393 2013-08-30 15:26:03.000000000 +0900 Vol.1.rar
-rw-r--r--  1 root   root  22110405466 2013-09-19 19:52:13.000000000 +0900 Vol.2.rar
-rw-r--r--  1 root   root  22274030773 2013-10-27 14:54:15.000000000 +0900 Vol.3.rar
-rw-r--r--  1 root   root  20987668628 2013-11-09 09:17:03.000000000 +0900 Vol.4.rar
-rw-r--r--  1 root   root  22540994209 2014-01-27 13:10:19.000000000 +0900 Vol.5.rar
-rw-r--r--  1 root   root  23608165738 2014-01-27 09:21:15.000000000 +0900 Vol.6.rar

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

openSUSE 13.1 x86-64, unrar 5.0.14

# rar2fs -V
rar2fs v1.19.8 (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

Please provide any additional information below.

Yes, it's not major bug which is related real data. But I think that should be fixed...

Original issue reported on code.google.com by jyhpsycho on 2014-02-21
@hasse69 hasse69 closed this as completed Mar 13, 2015
@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Interesting observation. I have no clue to why these outputs differ? Also, you say RAR
on Linux only provide second resolution? But from what I can tell from your printout
below, it seems to support a higher resolution? Or is that printout not from Linux!?

Original file :
-rw-r--r--  1 root   root  23501538393 2013-08-30 15:26:06.012630700 +0900 Vol.1.rar
-rw-r--r--  1 root   root  22110405466 2013-09-19 19:52:26.124659000 +0900 Vol.2.rar
-rw-r--r--  1 root   root  22274030773 2013-10-27 14:54:30.477460700 +0900 Vol.3.rar
-rw-r--r--  1 root   root  20987668628 2013-11-09 09:17:06.154892900 +0900 Vol.4.rar
-rw-r--r--  1 root   root  22540994209 2014-01-27 13:10:39.901638700 +0900 Vol.5.rar
-rw-r--r--  1 root   root  23608165738 2014-01-27 09:21:30.425213700 +0900 Vol.6.rar

Also note that the difference (in seconds) is always 1/2 of the original ;)

Original issue reported on code.google.com by hans.beckerus on 2014-02-21 15:18:13

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

RAR for Linux supports up to 1-second precision timestamp. That is traditional ext2
file system's limitation without advanced features such as extended attributes. Now
almost all file systems supported by linux supports nanosecond timestamps, but RAR
for Linux doesn't deal with that.

Original file list is output after extraction using Windows version of RAR(WinRAR).
It works when using WINE. According to technote of RARv5 format, RARv5's time structures
can hold (Traditional) Unix time (1-second precision mentioned above) or Windows' FILETIME
structure(100-nanosecond precision after 1601/01/01 00:00:00).

Original issue reported on code.google.com by jyhpsycho on 2014-02-21 16:01:59

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Here's an output when extracting that archive using RAR for Linux :

-rw-r--r--  1 root   root  23501538393 2013-08-30 15:26:06.000000000 +0900 Vol.1.rar
-rw-r--r--  1 root   root  22110405466 2013-09-19 19:52:26.000000000 +0900 Vol.2.rar
-rw-r--r--  1 root   root  22274030773 2013-10-27 14:54:30.000000000 +0900 Vol.3.rar
-rw-r--r--  1 root   root  20987668628 2013-11-09 09:17:06.000000000 +0900 Vol.4.rar
-rw-r--r--  1 root   root  22540994209 2014-01-27 13:10:39.000000000 +0900 Vol.5.rar
-rw-r--r--  1 root   root  23608165738 2014-01-27 09:21:30.000000000 +0900 Vol.6.rar

Original issue reported on code.google.com by jyhpsycho on 2014-02-21 16:04:45

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Ok, but what is the format of the archive you used, RAR4 or RAR5?
Does the TechNote really state what will happen with a RAR5 archive created on eg.
Windows when extracted on Linux? Will the time stamp be truncated?
But yes. Definitely an error in rar2fs somewhere that fails to properly interpret the
time stamp.

Original issue reported on code.google.com by hans.beckerus on 2014-02-21 16:19:34

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

I used RARv5 format in this case. Currently technote describes RARv5, too.

I found that rar2fs mis-interpret timestamps on legacy format, too.

Original issue reported on code.google.com by jyhpsycho on 2014-02-21 16:59:31

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Ok. This one was easy. I have simply miss-interpreted the MS-DOS file format (as libunrar
currently provides) when it comes to the second part. MS-DOS time format has only 5
bits to hold the number of seconds so it needs to be multiplied by 2 before presented.

Original issue reported on code.google.com by hans.beckerus on 2014-02-21 19:28:32

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

New version committed to trunk. Please verify.

Original issue reported on code.google.com by hans.beckerus on 2014-02-21 19:40:45

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

It seems to work. but, I hope that you accept some patches to support sub-second timestamps
if available.

Original issue reported on code.google.com by jyhpsycho on 2014-02-22 06:53:50

- _Attachment: [rar2fs-timestamp.patch](https://storage.googleapis.com/google-code-attachments/rar2fs/issue-29/comment-8/rar2fs-timestamp.patch)_

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

That includes some dirty debug message in rar2fs.c. Use this one.

Original issue reported on code.google.com by jyhpsycho on 2014-02-22 06:57:25

- _Attachment: [rar2fs-timestamp.patch](https://storage.googleapis.com/google-code-attachments/rar2fs/issue-29/comment-9/rar2fs-timestamp.patch)_

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Thanks for the patch. Will have a look at it.

Original issue reported on code.google.com by hans.beckerus on 2014-02-22 08:43:00

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Here's some issue on that patch. When I mounted legacy format archive, That returns
1-second precision timestamp - neither 2-second precision as DOS format nor Windows'
100-nanosecond precision. That's not Unix timestamp, too - becuase that's timestamp
is preserved when extracting via Windows version of RAR. There's need to more investigate...

Original issue reported on code.google.com by jyhpsycho on 2014-02-22 22:09:47

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

I really appreciate the the time and effort you spend on improving rar2fs. This is what
make things happen! I see the potential in your patch, but right now I need to focus
on the real bugs :( Please continue your work, it is more than welcome :)

Original issue reported on code.google.com by hans.beckerus on 2014-02-22 22:55:38

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Oh and yes, the detection of kernel support for 100ns precision in strcut timespec can
be done by adding a check in configure.ac. So that problem should be easy to fix :)

Original issue reported on code.google.com by hans.beckerus on 2014-02-22 22:59:04

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

There's some issue on arcread.cpp and timefn.cpp as part of libunrar.

In arcread.cpp, Archive::ReaderHeader15() (Header parser for legacy format) uses RarTime::SetLocal()
to treats Extended time format has more precision than DOS format (2 seconds). The
problem is, RarTime::SetLocal() under other than Windows, uses struct tm which is used
traditional Unix time format(1 second precision), then timestamp under 1 second is
lost.

For supporting that extended timestamp on legacy format, that seems to be needed some
workarounds - implementing own header parser independently; I wonder that there's really
need to implement for "perfect" timestamp support...

I think that's sufficient becuase it's not my patch's issue but libunrar's. That should
be work when Unix version of RAR officially supports nanosecond timestamp.

Original issue reported on code.google.com by jyhpsycho on 2014-02-23 02:11:29

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

What is the problem here really? If RAR5 archives support 100ns resolution your patch
should work. For RAR4 (and older) legacy archives your patch should simply be ignored.
I do not see the point in trying to support 100ns resolution for RAR achives that were
not designed for it?

Original issue reported on code.google.com by hans.beckerus on 2014-02-23 02:52:27

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Actually 100ns timestamp resolution is supported by legacy format, too. That is implemented
via extended header for storing high precision time. It means there's two time field
on each file header; one is traditional DOS format, the other is that. But, due to
limitation on libunrar what is I mentioned #14, rar2fs can receive only 1-second precision
timestamp from libunrar when mounting legacy-format RAR file.

With RARv5 foramt, libunrar doesn't use RarTime::SetLocal() which limits timestamp
resolution, thus it returns correct timestamp to rar2fs, then it works normally. I
think there's two possible solution: one is implement own legacy header parser on rar2fs
for reading timestamps directly, the other is send update libunrar request to WinRAR
support team to support high-precision timestamp under unix environment.

Original issue reported on code.google.com by jyhpsycho on 2014-02-23 03:27:02

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Just for this issue, there's one more way to fix this: patch arcread.cpp in libunrar.
Add few lines for processing that should works. but I guess you don't want to this
way.

Original issue reported on code.google.com by jyhpsycho on 2014-02-23 03:53:26

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

(No text was entered with this change)

Original issue reported on code.google.com by jyhpsycho on 2014-02-23 04:02:39

- _Attachment: [libunrar-timestamp-legacy.patch](https://storage.googleapis.com/google-code-attachments/rar2fs/issue-29/comment-18/libunrar-timestamp-legacy.patch)_

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

rar2fs can supports maximum timestamp precision which supported on RAR format - both
new and legacy format - when applies my two patches. But, latter one is not related
to rar2fs but libunrar...

Original issue reported on code.google.com by jyhpsycho on 2014-02-23 04:13:05

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Thanks for the patch. I will report this issue upstream and get here back when I know
more.

Original issue reported on code.google.com by hans.beckerus on 2014-02-23 09:18:28

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Upstream has responded! After applying some pressure :) (thanks Eugene) it is agreed
that a proper solution for this will be added to next version of libunrar. I will update
rar2fs to handle 100ns resolution when available. But until a new version of libunrar
is released legacy archives will still only provide 1s resolution, or use your patch
to workaround it temporarily.

Case closed.

Original issue reported on code.google.com by hans.beckerus on 2014-02-23 16:54:40

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

(No text was entered with this change)

Original issue reported on code.google.com by hans.beckerus on 2014-02-23 16:54:56

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

Thanks for your effort to fix this issue can say "annoyed"... :-)

Original issue reported on code.google.com by jyhpsycho on 2014-02-25 02:52:05

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

UnRAR source 5.10 beta 1 (5.1.1) should support high resolution time stamp also for
legacy archives. Please verify r471 towards this new version. According to my simple
tests it is fully supported.

Original issue reported on code.google.com by hans.beckerus on 2014-03-18 20:58:56

@hasse69
Copy link
Owner Author

hasse69 commented May 23, 2015 

OK, I checked and it seems to work. :)

Original issue reported on code.google.com by jyhpsycho on 2014-03-25 14:26:51

@Nischi85 Nischi85 mentioned this issue Oct 9, 2022
Closed
fdegros pushed a commit to fdegros/rar2fs that referenced this issue Nov 29, 2023
@hasse69
* Released 1.20.0
39d51f1 
* Turned off support for block special device mounts other
  than for Linux platforms. It does not make much sense trying
  to support it any where else due to possible read alignment
  restrictions.

* Built and tested against UnRAR source 5.10 beta 1 (5.1.1)

* [rar2fs hasse69#34]

  Fixed a problem with old style archives split into more
  than 101 files.

* Now returning "No such file or directory" instead of
  "Input/output error" when trying to read information
  for a file outside an archive or which does not exist
  at all (libunrar5 only).

* Fixed an issue when retrieving file information (#info)
  that could have resulted in an infinite loop.

* Fixed an issue with resolving symbolic links for
  legacy archives in combination with libunrar5.

* Corrected some issues that caused compilation failures
  for UnRAR source 4.1.x.

* Corrected a problem seen on e.g. FreeBSD for which closedir()
  was called with a NULL pointer resulting in a crash.

* [rar2fs hasse69#31]

  Corrected some compilation errors on FreeBSD (and also other
  platforms that sets HAVE_SETXATTR).

* Mounting block special files on Linux can now benefit from
  fmemopen() when supported.

* Enabled syslog support

* [rar2fs hasse69#22]

  Now may fall back to the old workaround from 1.19.2 that
  should be working also for (some!?) uClibc versions of
  fmemopen().

* Corrected some additional problems with the solution
  for issue hasse69#22.

* Added support for presenting high-resolution time stamp in
  RAR5 archives (thanks to jyhpsycho for the initial patch).
  Legacy archives still require a new version of UnRAR source
  before it can be enabled.

* [rar2fs hasse69#28]

  Fixed problem with mounting a block special file that
  resulted in a crash due to incorrect use of mmap() and
  fmemopen().

* Added a missing check for errors from fmemopen()

* [rar2fs hasse69#29]

  Fixed a minor calculation error in the file time stamp
  'seconds' part as provided by libunrar (MS-DOS time format).

* Removed 'INSTALL' from SVN trunk
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