I am not sure if it's possible, but is there anyway we can add current UTC time inside the mkv metatag using ffmpeg? i read https://wiki.multimedia.cx/index.php?title=FFmpeg_Metadata but i could not find anything.
-metadata "Creation Time"="Need to add time tag/code"
output will show
Creation Time: UTC 2020-06-04 02:40:29
In Windows 10 environment, I would like to change the name of both “file with extension mp4” and “file with extension xml” to the shooting date of mp4 file.
C0001.MP4
C0001M01.XML
C0002.MP4
C0002M01.XML
Specifically, I want to change the file name as follows.
2019-10-23_13-10-32.MP4
2019-10-23_13-10-32.XML
2019-10-23_13-10-49.MP4
2019-10-23_13-10-49.XML
I tried to think that using the ext option would give me the expected result, but I didn't get the expected result.
First time
C:\Users\user>exiftool "-FileName<CreateDate" -d "%Y-%m-%d_%H-%M-%S%%-c.%%e" -ext "xml" C:\hoge
Warning: [minor] Error 3 placing ::NonRealTimeMetaLtcChangeTableLtcChangeStatus in structure or list - C:/hoge/C0001M01.XML
Warning: No writable tags set from C:/hoge/C0001M01.XML
Warning: [minor] Error 3 placing ::NonRealTimeMetaAudioFormatAudioRecPortTrackDst in structure or list - C:/hoge/C0002M01.XML
Warning: No writable tags set from C:/hoge/C0002M01.XML
1 directories scanned
0 image files updated
2 image files unchanged
Second time
C:\Users\user>exiftool "-FileName<CreateDate" -d "%Y-%m-%d_%H-%M-%S%%-c.%%e" -ext "*" C:\hoge
Warning: [minor] The ExtractEmbedded option may find more tags in the movie data - C:/hoge/C0001.MP4
Warning: [minor] Error 3 placing ::NonRealTimeMetaLtcChangeTableLtcChangeStatus in structure or list - C:/hoge/C0001M01.XML
Warning: No writable tags set from C:/hoge/C0001M01.XML
Warning: [minor] The ExtractEmbedded option may find more tags in the movie data - C:/hoge/C0002.MP4
Warning: [minor] Error 3 placing ::NonRealTimeMetaAudioFormatAudioRecPortPort in structure or list - C:/hoge/C0002M01.XML
Warning: No writable tags set from C:/hoge/C0002M01.XML
1 directories scanned
2 image files updated
2 image files unchanged
Added November 22, 2019
I tried the code posted in this link .
C:\Users\user>exiftool -TagsFromFile %d%f.mp4 "-FileName<CreateDate" -ext xml C:\hoge
Warning: Error opening file - C:/mp4data/C0001M01.mp4
Warning: Error opening file - C:/mp4data/C0002M01.mp4
1 directories scanned
0 image files updated
2 image files unchanged
I think the cause of the error is that “.mp4 file name” and “.xml file name” do not match.
Since “M01” is always a fixed value, is there any way to batch process it?
C0001.MP4
C0001M01.XML
C0002.MP4
C0002M01.XML
I am trying to retrieve the creation timestamp for a specific folder stored in hdfs, but I did not find a command that can get this information.
Apparently, as the -help command states out, the -stat command can only retrieve the modification date using the %y option:
bash$ hdfs dfs -help stat
-stat [format] <path> ... :
Print statistics about the file/directory at <path> in the specified format.
Format accepts filesize in blocks (%b), group name of owner(%g), filename (%n),
block size (%o), replication (%r), user name of owner(%u), modification date
(%y, %Y)
Is there some way to get the creation date?
HDFS stores only the modified time and access time of the files as per the HDFS inode code in GitHub - HERE.
The modified time for files is the time when the file was last closed (such as when originally written and closed, or when reopened for append and closed).
During most of the time the modified time does not change for most files we place on HDFS unless they undergo any modifications as stated above. Hence, the modified can be referred as an acceptable creation time most of the time (NOT ALWAYS).
The task is to write a bash scenario to delete in a directory those files whose last access time exceeds N days.
If there are no such files, the message should be displayed.
I'm trying to delete 1 file and find the last access time for it:
stat -c%x test.txt
The command returns a date: 2018-12-01 16:45:30.390000000 +0000
Then I'm writing a current date command:
date '+%Y-%m-%d %H:%M:%S.%N'
The command returns a date: 2018-12-01 18:39:16.873718766
Now I have no idea how to subtract this dates and apply to all files of the directory.
Use the command find with a parameter -atime.
find /path/to/dir -atime +100 -delete
deletes files accessed 101 or more days ago.
So, here's the problem: I have files which are regular files, and they are put into a ZIP file (see below for details on ZIP). Then I unzip them (see below for details on the tool used), and the files are restored. The date of the file is restored, as in standard in the ZIP/UNZIP tools used. When querying using DIR, or in Windows Explorer, the files involved have the same date as they had, before being handled by the ZIP/UNZIP process.
So, all OK.
But then, I'm using the XCOPY /D command, to further manipulate different copies of those files on the disk ... and, XCOPY says : one file is newer than the other one. Given the fact the date, hour, up until minutes is the same .. the difference would be regarding a smaller entity, like seconds ?
All involved disks have NTFS file system.
Example:
C:\my>dir C:\windows\Background_mycomputer.cmd C:\my\directory\Background_mycomputer.cmd
Volume in drive C is mycomputerC
Volume Serial Number is 1234-5678
Directory of C:\windows
31/12/2014 19:50 51 Background_mycomputer.cmd
1 File(s) 51 bytes
Directory of C:\my\directory
31/12/2014 19:50 51 Background_mycomputer.cmd
1 File(s) 51 bytes
0 Dir(s) 33.655.316.480 bytes free
C:\my>xcopy C:\windows\Background_mycomputer.cmd C:\my\directory\Background_mycomputer.cmd /D
Overwrite C:\my\directory\Background_mycomputer.cmd (Yes/No/All)? y
C:\windows\Background_mycomputer.cmd
1 File(s) copied
C:\my>xcopy C:\my\directory\Background_mycomputer.cmd C:\windows\Background_mycomputer.cmd /D
0 File(s) copied
C:\my>xcopy C:\windows\Background_mycomputer.cmd C:\my\directory\Background_mycomputer.cmd /D
0 File(s) copied
C:\my>unzip -v
UnZip 6.00 of 20 April 2009, by Info-ZIP. Maintained by C. Spieler. Send
bug reports using http://www.info-zip.org/zip-bug.html; see README for details.
Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;
see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.
Compiled with Microsoft C 13.10 (Visual C++ 7.1) for
Windows 9x / Windows NT/2K/XP/2K3 (32-bit) on Apr 20 2009.
UnZip special compilation options:
ASM_CRC
COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)
NTSD_EAS
SET_DIR_ATTRIB
TIMESTAMP
UNIXBACKUP
USE_EF_UT_TIME
USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)
USE_DEFLATE64 (PKZIP 4.x Deflate64(tm) supported)
UNICODE_SUPPORT [wide-chars] (handle UTF-8 paths)
MBCS-support (multibyte character support, MB_CUR_MAX = 1)
LARGE_FILE_SUPPORT (large files over 2 GiB supported)
ZIP64_SUPPORT (archives using Zip64 for large files supported)
USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.5, 10-Dec-2007)
VMS_TEXT_CONV
[decryption, version 2.11 of 05 Jan 2007]
UnZip and ZipInfo environment options:
UNZIP: [none]
UNZIPOPT: [none]
ZIPINFO: [none]
ZIPINFOOPT: [none]
C:\my>ver
Microsoft Windows [Version 6.1.7601]
C:\my>zip -?
Copyright (c) 1990-2006 Info-ZIP - Type 'zip "-L"' for software license.
Zip 2.32 (June 19th 2006). Usage:
zip [-options] [-b path] [-t mmddyyyy] [-n suffixes] [zipfile list] [-xi list]
The default action is to add or replace zipfile entries from list, which
can include the special name - to compress standard input.
If zipfile and list are omitted, zip compresses stdin to stdout.
-f freshen: only changed files -u update: only changed or new files
-d delete entries in zipfile -m move into zipfile (delete files)
-r recurse into directories -j junk (don't record) directory names
-0 store only -l convert LF to CR LF (-ll CR LF to LF)
-1 compress faster -9 compress better
-q quiet operation -v verbose operation/print version info
-c add one-line comments -z add zipfile comment
-# read names from stdin -o make zipfile as old as latest entry
-x exclude the following names -i include only the following names
-F fix zipfile (-FF try harder) -D do not add directory entries
-A adjust self-extracting exe -J junk zipfile prefix (unzipsfx)
-T test zipfile integrity -X eXclude eXtra file attributes
-! use privileges (if granted) to obtain all aspects of WinNT security
-R PKZIP recursion (see manual)
-$ include volume label -S include system and hidden files
-e encrypt -n don't compress these suffixes
C:\my>
Question: I do not want XCOPY to make updates where I know they are invalid cause the time format is doing something wrong. How do I prevent that ?
From how I see, there's different things involved, being XCOPY, very specific ZIP and UNZIP, and NTFS file system. Which one is doing something wrong ?
I must stress that apart from ZIP and UNZIP, there are no other changes done to the file, like changing 1 file, then making a change to another one, in less than 60 seconds time.
At moment of test, the time shown was NOT the current time, and not close to it either. No file is adjusting to the current time, the times refer to last changes of the file in question, which may be any time in the past. In this case, it's one day later, but it can be anything.
I noticed the peculiar behavior Raymond Chen describes when writing a Powershell script (GitHub link) to freshen a zip archive using the System.IO.Compression and System.IO.Compression.FileSystem libraries.
Interestingly, Zip archives can store multiple copies of the same file with identical metadata (name, relative path, modification dates). Extracting the second copy of the file will fail in Windows Explorer because the file already exists.
When trying to prevent re-zipping a file was already archived, I checked the relative path and date, and noticed that there was a discrepancy of up to two seconds in the LastWriteTime. This workaround compensates for the loss of precision:
$AlreadyArchivedFile = ($WriteArchive.Entries | Where-Object {#zip will store multiple copies of the exact same file - prevent this by checking if already archived.
(($_.FullName -eq $RelativePath) -and ($_.Length -eq $File.Length) ) -and
([math]::Abs(($_.LastWriteTime.UtcDateTime - $File.LastWriteTimeUtc).Seconds) -le 2) #ZipFileExtensions timestamps are only precise within 2 seconds.
})
Also, the IsDaylightSavingTime flag is not stored in the Zip archive. As a result I was surprised when extracted files became an hour newer than the original archived file. I tried this several times and saw the extracted file's timestamp incremented by an hour every time it was compressed and extracted.
Here's a very ugly workaround that decreases the archived file time by one hour to make the original source file and extracted file timestamps consistent:
If($File.LastWriteTime.IsDaylightSavingTime() -and $ArchivedFile){#HACK: fix for buggy date - adds an hour inside archive when the zipped file was created during PDT (files created during PST are not affected).
$entry = $WriteArchive.GetEntry($RelativePath)
$entry.LastWriteTime = ($File.LastWriteTime.ToLocalTime() - (New-TimeSpan -Hours 1))
}
There's probably a better way to handle this. Unfortunately I'm not aware of any way to store a Daylight Savings indicator for a file in a .Zip archive, and that information is lost.