FreeRDP icon indicating copy to clipboard operation
FreeRDP copied to clipboard

Drive share files copy, dates are changed

Open maxchendt opened this issue 6 years ago • 7 comments

freerdp-nightly_2.0.0+0_20190405014828.644_1.gbp37358e_amd64.deb still have the problem: date is changed for a file copied from RDP to local through drive share

https://github.com/FreeRDP/FreeRDP/issues/5317#issuecomment-478006211

maxchendt avatar Apr 05 '19 17:04 maxchendt

Please wait at least a day after a merge! The pr was merged AFTER the last nightly.

akallabeth avatar Apr 05 '19 18:04 akallabeth

freerdp-nightly_2.0.0+0_20190409014830.646_1.gbpdf280a_amd64.deb I have also test 0405 and 0406 nightly build, this bug is not be fixed.

Copy files from Liunx to Win, "modified dates" are the same. However, copy a file from Win (RDP server) to Liunx (RDP client), the "modified dates" are changed randomly.

Screenshot at 2019-04-10 20-30-43

maxchendt avatar Apr 10 '19 12:04 maxchendt

@maxchendt please add the output of xfreerdp /buildconfig Just checked with the package you mentioned and it works as expected. Are you sure you're using the correct binary and not some system installed one?

akallabeth avatar Apr 10 '19 13:04 akallabeth

/opt/freerdp-nightly/bin/xfreerdp /buildconfig This is FreeRDP version 2.0.0-dev5 (df280a7ff) Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_H=1 HAVE_FCNTL_H=1 HAVE_INTTYPES_H=1 HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIB=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL= HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_DSP_FFMPEG=ON WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=TRUE WITH_FFMPEG=TRUE WITH_GFX_H264=ON WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_GSTREAMER_0_10=ON WITH_GSTREAMER_1_0=ON WITH_ICU=OFF WITH_IPP=OFF WITH_JPEG=OFF WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PAM=ON WITH_PCSC=ON WITH_PROFILER=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=ON WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=0 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=0 WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=ON WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=0 WITH_WAYLAND=OFF WITH_X11=ON WITH_X264=OFF WITH_XCURSOR=ON WITH_XDAMAGE=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XTEST=ON WITH_XV=ON WITH_ZLIB=ON Build type: RelWithDebInfo CFLAGS: -g -O2 -fdebug-prefix-map=/build/freerdp-nightly-2.0.0+0~20190409014830.646~1.gbpdf280a=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -Wall -Wno-unused-result -Wno-unused-but-set-variable -Wno-deprecated-declarations -fvisibility=hidden -Wimplicit-function-declaration -Wredundant-decls -g -fsanitize=address -fsanitize-address-use-after-scope -fno-omit-frame-pointer -DWINPR_DLL Compiler: GNU, 7.3.0 Target architecture: x64

maxchendt avatar Apr 10 '19 14:04 maxchendt

Ok, now I´m really buzzled, with windows 7, 8, 8.1 the timestamps are correct, but a windows 10 installation is off... According to documentation the timestamps should be in UTC so what is going on here?

akallabeth avatar Apr 10 '19 15:04 akallabeth

It is OK for windows 2019 data center, but not OK for windows LTSC 2019, maybe a bug in LTSC 2019?

maxchendt avatar Apr 19 '19 01:04 maxchendt

Also happens with Server 2012 R2 (freerdp 2.2.0). The wrong dates are not really random, If I delete a target file and copy it again, the new target file gets the same (wrong) date as before. I also tried copying a folder and some files' dates copied correctly, others were wrong. Also, the wrong dates were all looking plausible, meaning in the recent enough past, and with times where I might actually have been working. Otherwise I could not see any correlation to other timestamps the source files have. Sometimes the target's wrong, new changed-date is weirdly close to the source's creation or last access date, but never exactly.

jsane-h8ms avatar Aug 17 '22 15:08 jsane-h8ms