Issues using exiftool against files on WD MyCloud NAS - RESOLVED

[phankins11]

Hi all

I just spent quite a bit of time trying to figure this out, so I thought I'd post this to shared my experience and also to get feedback on my assumptions.

Here is what I was attempting to do:

I have a Western Digital My Cloud NAS. Most of what I use this for is a local network NAS that houses our family photos and videos. The family can browse the pics and vids from their phones using the app for the WD MyCloud Drive. When I work with files like this I'm usually manipulating them by way of DOS command line over a mapped drive to the NAS on Windows 10.

One of the important things to me is that its easy to sort these photos and videos based on the create date of the file, i.e. the date and time that the event being viewed actually occurred. Most OSs and other file browsing apps key of of the filesystem file creation date when default sorting by dates.

My first issue was that I just could not get the filesystem:FileCreateDate to update with anything when I would issue an exiftool command to set the FileCreateDate. I found a previous thread here while troubleshooting here: https://exiftool.org/forum/index.php?topic=9252.msg47832#msg47832. If you read through that thread you find that a solution was never really reached and that Phil Harvey concluded that "There is some other software messing with these files.  I suspect an overactive virus scanner." Well, that didn't apply to me here, because I'm not running antivirus ( don't judge! ) and no matter what I did, I could not get the Filesystem:FileCreateDate attribute to change.

However, the above conclusion got me to thinking that maybe it was My NAS (where the files live) that was interfering. So I moved the files off of my NAS and to a local hard drive on my PC. Lo and behold, the exiftool update for the FileCreateDate worked!

So, issue\resolution number one was that attempting to update a file's FileCreateDate attribute while said file resides on a WDMyCloud NAS (and I'd assume any NAS based on a Linux operating system) will fail and most likely the local OS of the NAS is preventing that change. Move the file to a local PC hard drive and try it there.

Second issue I ran into, while not a direct exiftool issue, I think folks using this tool may run into this behavior and so the exiftool is the solution.

After successfully setting the FileCreateDate attribute on a file, locally on my PC hard drive, and then moving that file to my NAS, the FileCreateDate attribute gets reset to a current date and time. No matter if I copied or moved the file, FileCreateDate was always being reset to the current date and time. After attempting many things, and observing an anomaly on one file where the FileCreateDate did not get set to a current date and time but to a date and time in the past, just not the correct past date and time. I realized that the update of the FileCreateDate attribute matched that of the FileModifyDate of the file I was working with. In my particular case 99% of the files I was working with had a current date and time for FileModifyDate, because I was creating the files locally on my PC. The goal was to update the FileCreateDate before moving the files to my NAS.

The solution here is to use the exiftool to update the FileModifyDate to the desired create date and time (usually based of the DV:DateTimeOriginal or the QuickTime:CreateDate). After doing this for a hand full of files the files I move to the NAS now end up moving over with my desired FileCreateDate.

I hope this helps folks and isn't seen as repetitive.

[Phil Harvey]

This makes sense because Unix filesystems do not store a file creation date/time.  So if the NAS is Unix-based, it may be that it is using the file modification time instead.

- Phil