Opened 6 years ago

Closed 22 months ago

#14093 closed bug (fixed)

File time stamps - Haiku mis-handles NTFS time stamps

Reported by: Stacked_Lambda Owned by: waddlesplash
Priority: normal Milestone: Unscheduled
Component: File Systems/NTFS Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Haiku mis-handles the file created and file last modified time stamps on NTFS volumes which are exchanged between Haiku and Windows.

I have exchanged files between Haiku and Windows via NTFS formatted external hard drives and noted the following:

Haiku reports the time stamps for file/folder creation being a century ago - usually 1901, 1902, or 1903.

Haiku does not respects a file last modification time stamp when copying from/to NTFS. It resets the file last modification time stamp to that of the file creation time stamp which is that of the copying operation. This is contrary to how Windows handles the NTFS file time stamps on copy operations.

Change History (10)

comment:1 by korli, 6 years ago

Please post your haiku revision and architecture.

comment:2 by korli, 6 years ago

Component: - GeneralFile Systems/NTFS
Owner: changed from nobody to 3dEyes

comment:3 by Stacked_Lambda, 6 years ago

Providing some clarifications and test results.

The following tests were performed with HRev51877 (on a X86 notebook).

Mounting a NTFS volume:

For files and folders, the last modified time stamp is correct - that at which the file was last modified (in the Windows world).

However, the created time stamp is the same for all files and folders and way in the past. For example, April 1901, August 1903, and October 1945.

Copying from a BFS volume to a NTFS volume:

The file last modified time stamp is updated to be the same as the file created time stamp and corresponds to the date-time at which the file was copied to the volume.

Copying from a NTFS volume to a NTFS volume:

The time stamps appear to be respected when re-mounting the volume in Windows; not extensively tested though.

Coming from the Windows world, there are two expected behaviors with respect to time stamps:

  • file last modified time stamp is that at which the actual contents of the file were modified.
  • file created time stamp is that at which the file was added to a volume/folder when created or copied (cloned?); it is not updated when the file is moved across volumes or folders.

The last accessed time stamp is what it is, and is only shown when explicitly inquiring about the properties of a file or folder.

To be frank, I am uncertain of what conventions exist for file time stamps in BeOS/Haiku.

comment:4 by pulkomandy, 6 years ago

How do you copy the files? Are the result the same when you use cp (needs some specific options to preserve the dates IIRC), Tracker, or rsync?

comment:5 by Stacked_Lambda, 6 years ago

I used Tracker for the copy operation. I have not compared with cp or rsync as I tend to avoid the command line unless it is the only way possible to perform a task.

As I understand it, NTFS provides a total of four time stamps to accommodate the needs of Win32 as well as those of POSIX: : Creation (Win32 only), Last Write/Modified, Last Access, and Last Changed (I-node including attributes). There are two copies of these time stamps - one with the file it-self and one within the Master File Table (MFT).

With the exception of the Creation time stamp, I would expect the behavior of the other time stamps for file operations under NTFS and POSIX to be the same irrespective of which operating system is performing the operation. Maybe this is an overly naive understanding of file operations.

Translation of attributes when going across file systems is known to be messy and using a compressed archive is often recommended for such operation. However, doing this for many files is quite tedious.

comment:6 by waddlesplash, 2 years ago

Owner: changed from 3dEyes to waddlesplash
Status: newassigned

comment:7 by waddlesplash, 2 years ago

Please see if the behavior is to your expectations after hrev55628.

comment:8 by waddlesplash, 22 months ago

Resolution: invalid
Status: assignedclosed

No reply, and nobody else seems to have observed this behavior since the NTFS driver was rewritten.

comment:9 by waddlesplash, 22 months ago

Resolution: invalid
Status: closedreopened

comment:10 by waddlesplash, 22 months ago

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.