Another Win under Qubes issue - Original date on copying/moving TO Win HVMs

User Support
1

This is a huge letdown, at least for me, if it’s by design.

Is it possible data copied between VMs to retain original date? I can’t find anything after the operation. The only methods are to search by names, or by examining content?

Yes, it took me 10 years to ask the question, but let’s say it was a matter of priority, and I’m on fire right now to find specific file copied to my vault by date, so why not to ask…

2 Likes
2

What do you mean by original date? Filecopy does preserve last modification time (mtime) and last access time (atime).

3

Not in my case. All the files get the date of copying for all the dates (accessed, created, modified, etc…)

So when I list them in the target VM, or view them in file browser, A single date and time (well, time not exactly, but you know what I mean) in a whole column. So frustrating…

4

Hmm, what’s the template on the receiving side? Maybe some in-VM thing is clobbering atime and mtime.

btime (“birth”/creation time) and ctime (inode status change time) are not expected to preserved, BTW.

5

If you’d guide me where to find that info, I’d be more than happy to feedback you!

6

qvm-prefs vault template would show the TemplateVM used by the vault AppVM.

Also, can you currently reproduce this clobbering of the modification time in particular? E.g. by running touch --time mtime -d 20010203 newfile in another VM, copying newfile into the vault VM, and then running the stat command (with this file given as a parameter) in both the vault VM and the other VM.

7

You were right. My workflow led me to only partially true OP conclusion.

Here’s what happened. I’m backing up huge number of files from time to time from my win HVM, manually… First, I’m doing it from win HVM1 to HVM2 (backup HVM) and when I’m sure they work in HVM2 by checking few of them immediately in HVM2, I’m backing them up to vault.

Now, after transitioning to 4.2 I lost both HVMs from obvious qwt reasons, not knowing in advance that HVMs with Xen PV disk drivers won’t work under 4.2 although asking it specifically here prior to transitioning. Accordingly I lost all my data there, but was rest assured because I had backup in vault.

So creating new HVM under 4.2, I was to put the data back from vault to new HVM3 under 4.2, which I did. Now let’s say for the sake of describing, I needed a specific file from October, knowing it was created at it’s first week, only to find out that all my files in vault were dated to November (the date and time of last backup) which was frustrating.

Now, when I checked what you suggested me, I tried to copy files from HVM2 to vault, and they all retained their original dates… Then I copied files using my routine to HVM4, only to find out that that all their original date/time properties were 'taken over" by HVM4 which assigned the date/time of copying to it.

So it turned out that both of us were right and here’s the proper diagnosis:

  1. Copying/moving BETWEEN NON-WINDOWS VMs preserves original attributes of the file
  2. Copying/moving files FROM WINDOWS TO NON-WINDOWS VMSs preserves original file attributes.
  3. Copying/moving TO WINDOWS VMs losses original file attributes.

I) So, I don’t know if this is issue with qwt or not, but if it is, is additional frustration, which has nothing to do with much huger issues with qwt/xen ov disk drivers, but I’m sure at least one is easily solvable, not further increasing potential compromising with Xen drivers.

What is even more frustrating is that it is clear that 10 years qwt issues in a whole to be resolved were more than enough, so it leads me to conclusion there is an agenda why this isn’t already and once for all resolved. Maybe intention QWT bo be paid for? Whatever. This remark has nothing to do with you, I am as always more than grateful to your response, I am sure you know how much appreciate you.

II) If it’s about Qubes, than I’m addressing it here, hopefully someone will issue this on a GitHub since I don’t have account there. And I accordingly changed the Topic’s Subject. (And from this point again not addressing you at all:), and I don’t have account on GitHUb, beside other reasons, because I don’t have time in my life to synchronize info update from both sources, and because this forum is declared as:

### Report issues and submit changes in the right places

The forum (and mailing lists) a good place to ask questions and discuss bugs and feature requests. However, if you’re submitting a more formal report, we’d prefer that you submit it to our issue tracker so that it doesn’t get overlooked. Likewise, if you see that something in the documentation should be changed, don’t simply point it out in an email to one of the mailing lists. Instead, submit the change.

so I choose to do it here since I’m already offered.Not rarely, on the contrary, many users, including stuff use this forum as a “waiting room”/“train switching point” to the Github which is contradictory with what I just quoted from official " Welcome to the Qubes OS forum!" guidelines.

1 Like
8

Ah, that explains it.

QWT are close to finally getting an update, but it doesn’t look like restoring mtime/atime is a part of it yet:

1 Like