Timestamps of files copied to USB drive
Clash Royale CLAN TAG#URR8PPP
up vote
3
down vote
favorite
I have a problem with the timestamps of files copied from my PC or laptop to USB drives: the last modification time of the original file and that of the copied file are different. Therefore, synchronizing files between my PC and my USB drive is quite cumbersome.
A step by step description:
I copy an arbitrary file from my PC/laptop to a USB drive using the GUI or with the command
cp -a file.txt /media/gabor/CORSAIR/
I check the last modification time of the original file:
ls -l --time-style=full-iso file.txt
-rw-rw-r-- 1 gabor gabor 0 2018-09-22 15:09:23.317098281 +0200 file.txt
- I check the last modification time of the copied file:
ls -l --time-style=full-iso /media/gabor/CORSAIR/file.txt
-rw-r--r-- 1 gabor gabor 0 2018-09-22 15:09:23.000000000 +0200 /media/gabor/CORSAIR/file.txt
- As you can see, the seconds in the last modification time of the copied file are truncated to zero decimal digits. However, if I enter the command
if ! [ file.txt -nt /media/gabor/CORSAIR/file.txt ] && ! [ file.txt -ot /media/gabor/CORSAIR/file.txt ]; then echo "The last modification times are equal."; fi
I get the output The last modification times are equal.
- The situation changes if I unmount and remount the USB drive and I execute the last two commands again:
ls -l --time-style=full-iso /media/gabor/CORSAIR/file.txt
-rw-r--r-- 1 gabor gabor 0 2018-09-22 15:09:22.000000000 +0200 /media/gabor/CORSAIR/file.txt
if [ file.txt -nt /media/gabor/CORSAIR/file.txt ]; then echo "The file is newer on the PC."; fi
The file is newer on the PC.
- So after remount, the last modification time of the copied file is further reduced by one second. Further unmounting and remounting, however, doesn't affect the last modification time any more. Besides, the test on the files now shows that the file on the PC is newer (although it isn't).
The situation is further complicated by the fact that the last modification time of files is shown differently on my PC and on my laptop, the difference being exactly 2 hours, although the date and time setting is the same on my PC and on my laptop!
Further information:
Both my PC and laptop show the behaviour, described above. I have Ubuntu 14.04.5 (trusty) on my PC and Ubuntu 16.04.2 (xenial) on my laptop.
My USB drives have vfat file system. The output of mount | grep CORSAIR
is
/dev/sdb1 on /media/gabor/CORSAIR type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2)
My other USB drives show the same behaviour.
Question:
Can the difference in the last modification times be eliminated somehow? For example, using other parameters at mounting/unmounting? Or is it a bug in Ubuntu?
I would like to achieve that the timestamps of the original and copied files are exactly the same, so that synchronization can be done more efficiently. Also, I would like to keep the vfat file system on my USB drives, so that I can use them under Windows, too.
usb-drive file-copy timestamps
New contributor
add a comment |Â
up vote
3
down vote
favorite
I have a problem with the timestamps of files copied from my PC or laptop to USB drives: the last modification time of the original file and that of the copied file are different. Therefore, synchronizing files between my PC and my USB drive is quite cumbersome.
A step by step description:
I copy an arbitrary file from my PC/laptop to a USB drive using the GUI or with the command
cp -a file.txt /media/gabor/CORSAIR/
I check the last modification time of the original file:
ls -l --time-style=full-iso file.txt
-rw-rw-r-- 1 gabor gabor 0 2018-09-22 15:09:23.317098281 +0200 file.txt
- I check the last modification time of the copied file:
ls -l --time-style=full-iso /media/gabor/CORSAIR/file.txt
-rw-r--r-- 1 gabor gabor 0 2018-09-22 15:09:23.000000000 +0200 /media/gabor/CORSAIR/file.txt
- As you can see, the seconds in the last modification time of the copied file are truncated to zero decimal digits. However, if I enter the command
if ! [ file.txt -nt /media/gabor/CORSAIR/file.txt ] && ! [ file.txt -ot /media/gabor/CORSAIR/file.txt ]; then echo "The last modification times are equal."; fi
I get the output The last modification times are equal.
- The situation changes if I unmount and remount the USB drive and I execute the last two commands again:
ls -l --time-style=full-iso /media/gabor/CORSAIR/file.txt
-rw-r--r-- 1 gabor gabor 0 2018-09-22 15:09:22.000000000 +0200 /media/gabor/CORSAIR/file.txt
if [ file.txt -nt /media/gabor/CORSAIR/file.txt ]; then echo "The file is newer on the PC."; fi
The file is newer on the PC.
- So after remount, the last modification time of the copied file is further reduced by one second. Further unmounting and remounting, however, doesn't affect the last modification time any more. Besides, the test on the files now shows that the file on the PC is newer (although it isn't).
The situation is further complicated by the fact that the last modification time of files is shown differently on my PC and on my laptop, the difference being exactly 2 hours, although the date and time setting is the same on my PC and on my laptop!
Further information:
Both my PC and laptop show the behaviour, described above. I have Ubuntu 14.04.5 (trusty) on my PC and Ubuntu 16.04.2 (xenial) on my laptop.
My USB drives have vfat file system. The output of mount | grep CORSAIR
is
/dev/sdb1 on /media/gabor/CORSAIR type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2)
My other USB drives show the same behaviour.
Question:
Can the difference in the last modification times be eliminated somehow? For example, using other parameters at mounting/unmounting? Or is it a bug in Ubuntu?
I would like to achieve that the timestamps of the original and copied files are exactly the same, so that synchronization can be done more efficiently. Also, I would like to keep the vfat file system on my USB drives, so that I can use them under Windows, too.
usb-drive file-copy timestamps
New contributor
Are you willing to create another file system in the USB drive, for example a linuxext4
file system? (The support in linux for Microsoft proprietary file systems, FAT32, exFAT, NTFS, has some limits.) See this link which suggests not onlyext4
but alsoudf
as alternatives to Microsoft proprietary file systems.
â sudodus
2 hours ago
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
I have a problem with the timestamps of files copied from my PC or laptop to USB drives: the last modification time of the original file and that of the copied file are different. Therefore, synchronizing files between my PC and my USB drive is quite cumbersome.
A step by step description:
I copy an arbitrary file from my PC/laptop to a USB drive using the GUI or with the command
cp -a file.txt /media/gabor/CORSAIR/
I check the last modification time of the original file:
ls -l --time-style=full-iso file.txt
-rw-rw-r-- 1 gabor gabor 0 2018-09-22 15:09:23.317098281 +0200 file.txt
- I check the last modification time of the copied file:
ls -l --time-style=full-iso /media/gabor/CORSAIR/file.txt
-rw-r--r-- 1 gabor gabor 0 2018-09-22 15:09:23.000000000 +0200 /media/gabor/CORSAIR/file.txt
- As you can see, the seconds in the last modification time of the copied file are truncated to zero decimal digits. However, if I enter the command
if ! [ file.txt -nt /media/gabor/CORSAIR/file.txt ] && ! [ file.txt -ot /media/gabor/CORSAIR/file.txt ]; then echo "The last modification times are equal."; fi
I get the output The last modification times are equal.
- The situation changes if I unmount and remount the USB drive and I execute the last two commands again:
ls -l --time-style=full-iso /media/gabor/CORSAIR/file.txt
-rw-r--r-- 1 gabor gabor 0 2018-09-22 15:09:22.000000000 +0200 /media/gabor/CORSAIR/file.txt
if [ file.txt -nt /media/gabor/CORSAIR/file.txt ]; then echo "The file is newer on the PC."; fi
The file is newer on the PC.
- So after remount, the last modification time of the copied file is further reduced by one second. Further unmounting and remounting, however, doesn't affect the last modification time any more. Besides, the test on the files now shows that the file on the PC is newer (although it isn't).
The situation is further complicated by the fact that the last modification time of files is shown differently on my PC and on my laptop, the difference being exactly 2 hours, although the date and time setting is the same on my PC and on my laptop!
Further information:
Both my PC and laptop show the behaviour, described above. I have Ubuntu 14.04.5 (trusty) on my PC and Ubuntu 16.04.2 (xenial) on my laptop.
My USB drives have vfat file system. The output of mount | grep CORSAIR
is
/dev/sdb1 on /media/gabor/CORSAIR type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2)
My other USB drives show the same behaviour.
Question:
Can the difference in the last modification times be eliminated somehow? For example, using other parameters at mounting/unmounting? Or is it a bug in Ubuntu?
I would like to achieve that the timestamps of the original and copied files are exactly the same, so that synchronization can be done more efficiently. Also, I would like to keep the vfat file system on my USB drives, so that I can use them under Windows, too.
usb-drive file-copy timestamps
New contributor
I have a problem with the timestamps of files copied from my PC or laptop to USB drives: the last modification time of the original file and that of the copied file are different. Therefore, synchronizing files between my PC and my USB drive is quite cumbersome.
A step by step description:
I copy an arbitrary file from my PC/laptop to a USB drive using the GUI or with the command
cp -a file.txt /media/gabor/CORSAIR/
I check the last modification time of the original file:
ls -l --time-style=full-iso file.txt
-rw-rw-r-- 1 gabor gabor 0 2018-09-22 15:09:23.317098281 +0200 file.txt
- I check the last modification time of the copied file:
ls -l --time-style=full-iso /media/gabor/CORSAIR/file.txt
-rw-r--r-- 1 gabor gabor 0 2018-09-22 15:09:23.000000000 +0200 /media/gabor/CORSAIR/file.txt
- As you can see, the seconds in the last modification time of the copied file are truncated to zero decimal digits. However, if I enter the command
if ! [ file.txt -nt /media/gabor/CORSAIR/file.txt ] && ! [ file.txt -ot /media/gabor/CORSAIR/file.txt ]; then echo "The last modification times are equal."; fi
I get the output The last modification times are equal.
- The situation changes if I unmount and remount the USB drive and I execute the last two commands again:
ls -l --time-style=full-iso /media/gabor/CORSAIR/file.txt
-rw-r--r-- 1 gabor gabor 0 2018-09-22 15:09:22.000000000 +0200 /media/gabor/CORSAIR/file.txt
if [ file.txt -nt /media/gabor/CORSAIR/file.txt ]; then echo "The file is newer on the PC."; fi
The file is newer on the PC.
- So after remount, the last modification time of the copied file is further reduced by one second. Further unmounting and remounting, however, doesn't affect the last modification time any more. Besides, the test on the files now shows that the file on the PC is newer (although it isn't).
The situation is further complicated by the fact that the last modification time of files is shown differently on my PC and on my laptop, the difference being exactly 2 hours, although the date and time setting is the same on my PC and on my laptop!
Further information:
Both my PC and laptop show the behaviour, described above. I have Ubuntu 14.04.5 (trusty) on my PC and Ubuntu 16.04.2 (xenial) on my laptop.
My USB drives have vfat file system. The output of mount | grep CORSAIR
is
/dev/sdb1 on /media/gabor/CORSAIR type vfat (rw,nosuid,nodev,uid=1000,gid=1000,shortname=mixed,dmask=0077,utf8=1,showexec,flush,uhelper=udisks2)
My other USB drives show the same behaviour.
Question:
Can the difference in the last modification times be eliminated somehow? For example, using other parameters at mounting/unmounting? Or is it a bug in Ubuntu?
I would like to achieve that the timestamps of the original and copied files are exactly the same, so that synchronization can be done more efficiently. Also, I would like to keep the vfat file system on my USB drives, so that I can use them under Windows, too.
usb-drive file-copy timestamps
usb-drive file-copy timestamps
New contributor
New contributor
edited 2 hours ago
New contributor
asked 3 hours ago
K. Gabor
163
163
New contributor
New contributor
Are you willing to create another file system in the USB drive, for example a linuxext4
file system? (The support in linux for Microsoft proprietary file systems, FAT32, exFAT, NTFS, has some limits.) See this link which suggests not onlyext4
but alsoudf
as alternatives to Microsoft proprietary file systems.
â sudodus
2 hours ago
add a comment |Â
Are you willing to create another file system in the USB drive, for example a linuxext4
file system? (The support in linux for Microsoft proprietary file systems, FAT32, exFAT, NTFS, has some limits.) See this link which suggests not onlyext4
but alsoudf
as alternatives to Microsoft proprietary file systems.
â sudodus
2 hours ago
Are you willing to create another file system in the USB drive, for example a linux
ext4
file system? (The support in linux for Microsoft proprietary file systems, FAT32, exFAT, NTFS, has some limits.) See this link which suggests not only ext4
but also udf
as alternatives to Microsoft proprietary file systems.â sudodus
2 hours ago
Are you willing to create another file system in the USB drive, for example a linux
ext4
file system? (The support in linux for Microsoft proprietary file systems, FAT32, exFAT, NTFS, has some limits.) See this link which suggests not only ext4
but also udf
as alternatives to Microsoft proprietary file systems.â sudodus
2 hours ago
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
3
down vote
The problem with the timestamp seconds changing comes from the fact that a VFAT (yes, even FAT32) filesystem stores the modification time with only 2-second resolution.
Apparently, as long as the filesystem is mounted, the filesystem driver caches timestamps accurate to 1-second resolution (probably to satisfy POSIX requirements), but once the filesystem is unmounted, the caches are cleared and you'll see what is actually recorded on the filesystem directory.
The two-hour difference between the PC and the laptop are probably caused by different timezone settings and/or different default mount options for VFAT filesystem. (I'm guessing that you're located in a timezone whose UTC offset is currently 2 hours, either positive or negative.)
Internally, Linux uses UTC timestamps on Unix-style filesystems; but on VFAT filesystems, the (current) default is to use local time on VFAT filesystem timestamps, because that is what MS-DOS did and Windows still does. But there are two mount options that can affect this: you can specify the mount option tz=UTC
to use UTC-based timestamps on VFAT filesystems, or you can use time_offset=<minutes>
to explicitly specify the timezone offset to be used with this particular filesystem.
It might be that the default mount options for VFAT have changed between Ubuntu 14.04 and 16.04, either within the kernel or the udisks
removable-media helper service, resulting in the two-hour difference you see.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
The problem with the timestamp seconds changing comes from the fact that a VFAT (yes, even FAT32) filesystem stores the modification time with only 2-second resolution.
Apparently, as long as the filesystem is mounted, the filesystem driver caches timestamps accurate to 1-second resolution (probably to satisfy POSIX requirements), but once the filesystem is unmounted, the caches are cleared and you'll see what is actually recorded on the filesystem directory.
The two-hour difference between the PC and the laptop are probably caused by different timezone settings and/or different default mount options for VFAT filesystem. (I'm guessing that you're located in a timezone whose UTC offset is currently 2 hours, either positive or negative.)
Internally, Linux uses UTC timestamps on Unix-style filesystems; but on VFAT filesystems, the (current) default is to use local time on VFAT filesystem timestamps, because that is what MS-DOS did and Windows still does. But there are two mount options that can affect this: you can specify the mount option tz=UTC
to use UTC-based timestamps on VFAT filesystems, or you can use time_offset=<minutes>
to explicitly specify the timezone offset to be used with this particular filesystem.
It might be that the default mount options for VFAT have changed between Ubuntu 14.04 and 16.04, either within the kernel or the udisks
removable-media helper service, resulting in the two-hour difference you see.
add a comment |Â
up vote
3
down vote
The problem with the timestamp seconds changing comes from the fact that a VFAT (yes, even FAT32) filesystem stores the modification time with only 2-second resolution.
Apparently, as long as the filesystem is mounted, the filesystem driver caches timestamps accurate to 1-second resolution (probably to satisfy POSIX requirements), but once the filesystem is unmounted, the caches are cleared and you'll see what is actually recorded on the filesystem directory.
The two-hour difference between the PC and the laptop are probably caused by different timezone settings and/or different default mount options for VFAT filesystem. (I'm guessing that you're located in a timezone whose UTC offset is currently 2 hours, either positive or negative.)
Internally, Linux uses UTC timestamps on Unix-style filesystems; but on VFAT filesystems, the (current) default is to use local time on VFAT filesystem timestamps, because that is what MS-DOS did and Windows still does. But there are two mount options that can affect this: you can specify the mount option tz=UTC
to use UTC-based timestamps on VFAT filesystems, or you can use time_offset=<minutes>
to explicitly specify the timezone offset to be used with this particular filesystem.
It might be that the default mount options for VFAT have changed between Ubuntu 14.04 and 16.04, either within the kernel or the udisks
removable-media helper service, resulting in the two-hour difference you see.
add a comment |Â
up vote
3
down vote
up vote
3
down vote
The problem with the timestamp seconds changing comes from the fact that a VFAT (yes, even FAT32) filesystem stores the modification time with only 2-second resolution.
Apparently, as long as the filesystem is mounted, the filesystem driver caches timestamps accurate to 1-second resolution (probably to satisfy POSIX requirements), but once the filesystem is unmounted, the caches are cleared and you'll see what is actually recorded on the filesystem directory.
The two-hour difference between the PC and the laptop are probably caused by different timezone settings and/or different default mount options for VFAT filesystem. (I'm guessing that you're located in a timezone whose UTC offset is currently 2 hours, either positive or negative.)
Internally, Linux uses UTC timestamps on Unix-style filesystems; but on VFAT filesystems, the (current) default is to use local time on VFAT filesystem timestamps, because that is what MS-DOS did and Windows still does. But there are two mount options that can affect this: you can specify the mount option tz=UTC
to use UTC-based timestamps on VFAT filesystems, or you can use time_offset=<minutes>
to explicitly specify the timezone offset to be used with this particular filesystem.
It might be that the default mount options for VFAT have changed between Ubuntu 14.04 and 16.04, either within the kernel or the udisks
removable-media helper service, resulting in the two-hour difference you see.
The problem with the timestamp seconds changing comes from the fact that a VFAT (yes, even FAT32) filesystem stores the modification time with only 2-second resolution.
Apparently, as long as the filesystem is mounted, the filesystem driver caches timestamps accurate to 1-second resolution (probably to satisfy POSIX requirements), but once the filesystem is unmounted, the caches are cleared and you'll see what is actually recorded on the filesystem directory.
The two-hour difference between the PC and the laptop are probably caused by different timezone settings and/or different default mount options for VFAT filesystem. (I'm guessing that you're located in a timezone whose UTC offset is currently 2 hours, either positive or negative.)
Internally, Linux uses UTC timestamps on Unix-style filesystems; but on VFAT filesystems, the (current) default is to use local time on VFAT filesystem timestamps, because that is what MS-DOS did and Windows still does. But there are two mount options that can affect this: you can specify the mount option tz=UTC
to use UTC-based timestamps on VFAT filesystems, or you can use time_offset=<minutes>
to explicitly specify the timezone offset to be used with this particular filesystem.
It might be that the default mount options for VFAT have changed between Ubuntu 14.04 and 16.04, either within the kernel or the udisks
removable-media helper service, resulting in the two-hour difference you see.
answered 1 hour ago
telcoM
11.7k11334
11.7k11334
add a comment |Â
add a comment |Â
K. Gabor is a new contributor. Be nice, and check out our Code of Conduct.
K. Gabor is a new contributor. Be nice, and check out our Code of Conduct.
K. Gabor is a new contributor. Be nice, and check out our Code of Conduct.
K. Gabor is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f470856%2ftimestamps-of-files-copied-to-usb-drive%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Are you willing to create another file system in the USB drive, for example a linux
ext4
file system? (The support in linux for Microsoft proprietary file systems, FAT32, exFAT, NTFS, has some limits.) See this link which suggests not onlyext4
but alsoudf
as alternatives to Microsoft proprietary file systems.â sudodus
2 hours ago