I wrote a Windows NetBeans program to rename files to "file creation date/time", i.e. 150912_140023.JPG, to merge photos chronologically from a camera, Droid and iPad. I encountered a problem with the iPad .jpg files.
I am seeing an inconsistency in the file dates. If I do a DOS dir command on an iPad photo, I see a file date of 09/12/15. This is the date my program is retrieving. However, in a windows directory window, I see a date of 09/07/15 for the same file.
The correct date of the file is 09/07/15.
Why is there a difference? Can I replicate the date determination performed by a directory window to get the correct date?
The iOS filesystem stores four timestamps for a file: last access time, last data modification time, last status change time (time that the inode was changed), and creation time.
NTFS stores three timestamps for a file: last access time, last write time, and creation time.
Copying a file from an iPad to Windows might update any of these times on the copy, depending on how the copy program was written.
The DIR command displays the last write timestamp by default (I believe). You can specify which timestamp you want it to display using a command-line flag. The /t:c flag requests creation time. The /t:a flag requests last access time. The /t:w flag requests last write time.
It sounds like you want to run DIR /t:c.
Related
I have an app that lets the user pick local files and send them to the backend to add to their vault. To pick the file, I use FilePicker.platform.pickFiles. It seems to work fine, the file is picked and when it's an image we show a preview to the user (and it always works).
Once the user has picked all their files, we create a list of Future to try and send the files to the backend, then we await the list to resolve. If we deem a picture is too big, we reduce the size using FlutterImageCompress.compressAndGetFile.
This usually works, but on iPhone, there is a seemingly random behavior where the file isn't found and an error is thrown : Cannot retrieve length of file, path = '/private/var/mobile/Containers/Data/Application/3600F812-FD42-4441-A654-766991E45E04/tmp/com.feykro.myApp.int-Inbox/myFile.pdf' (OS Error: No such file or directory, errno = 2)
The file in the example works just fine in other instances, the problem seems random and not directly tied to the file I chose. The problem is not exclusive to pdf files either, as it also occurs on images even though they're picked correctly and displayed in the app.
Any idea what could be causing this ?
Thanks in advance !
We have a dataflow application which reads from Pub/Sub, windows into fixed-size 1-minute duration windows and writes the raw messages to GCS with 10 shards. Our application has been running for 10 days now and it has created a .temp-beam-2017**** folder. There are about 6200 files under it and the count is growing every day.
My understanding is data flow will move the temp files to the specified output folder after the write is complete.
Could you please suggest what can be done in this case ? Each of these files are about 100MB.
inputCollection.apply("Windowing",
Window.<String>into(FixedWindows.of(ONE_MINUTE))
.triggering(AfterProcessingTime.pastFirstElementInPane()
.plusDelayOf(ONE_MINUTE))
.withAllowedLateness(ONE_HOUR)
.discardingFiredPanes()
)
//Writing to GCS
.apply(TextIO.write()
.withWindowedWrites()
.withNumShards(10)
.to(options.getOutputPath())
.withFilenamePolicy(
new
WindowedFileNames(options.getOutputPath())));
The discrepancy between 14400 and 13900 is most likely because your pipeline didn't get any data whose event time falls into a particular window and shard. When writing a windowed collection, we don't create empty files for "missing" windows, because in general, it is not possible to know which windows are "missing": it is, in theory, pretty clear for fixed or sliding windows, but not so for custom windowing functions or sessions etc. Moreover, assignment of shards is random, so it is possible that for a particular window very few data arrived, and then there's a pretty good chance that some of the 10 shards didn't get any of it.
As for why the temporary files are being left over: it seems that the pipeline is occasionally seeing exceptions when writing the files to GCS. The leftover files are "zombies" from those failed attempts to write data. We currently don't do a good job of cleaning up such files automatically in streaming mode (in batch, it is safe to delete the entire temporary directory when the pipeline is done, but in streaming we can't do that, and we delete only the individual files being renamed to their final location), but it should be safe for you to delete old temp files in that directory.
I've filed https://issues.apache.org/jira/browse/BEAM-3145 to improve the latter.
I am using Cordova fileSystem to download some mp3 Audio files thru my App. I am using cordova.file.cacheDirectory and creating a subfolder within that to store the downloaded files. However, the problem is that each time I make some changes and run the App on iPad I get a different path.
The usual pattern is
file:///var/mobile/Containers/Data/Application/13E9EA83-94A2-4950-811E-E491AC176A78/Library/Caches/MyFolder/MyFiles.mp3
However the long number (App UUID) is not consistent. It changes each time I run the App on iPad through Xcode. Because of this I am unable to access, play, delete any files downloaded during the previous session because I am saving the file names with absolute path in a separate file for quick access in the future.
After some R&D I have realized that even though UUID changes each time, it actually refers to the same location. Hence the solution is not to save absolute path and instead, save only the Path beyond "/MyFolder/" in the above example. Each time when the App is run, the Base Path, which is actually file.cordova.cacheDirectory, should be appended to each entry to obtain the absolute Path to the file.
I am trying to use the latest official version of the DropBox iOS Core SDK, in particular the DBRestClient, to efficiently keep a document tree up to date on my local computer. However, several features of the SDK don't seem to be implemented as you'd expect, and I was wondering whether I am doing something wrong, failing to understand something, or on the other hand just looking for features that aren't there.
Dropbox has (at least?) two kinds of entities it stores: files and folders. If I make a change to a file in Dropbox, I can detect it by a change in the file's "rev" string.
However, for folders, the rev string doesn't change when the contents changes. For example, it doesn't change in response to any of the following:
Adding a file
Deleting a file
Editing a file
Question 1:
Is this the expected behavior ? If so, does that mean that when I want to know if any of my Dropbox files have changed I must walk through the entire folder tree every time ?
Deltas:
There is a command to get a "delta" of the current contents (of something, the command takes no path parameters) related a "cursor" string. The command looks like it is supposed to return a record of edited files/folders along with a new "cursor" string specifying the current state. However, when I get the delta, the contents are always empty. If I make a change in dropbox, and then send back the previous returned "cursor", I still get an empty delta.
Question 2:
Are deltas currently working in the SDK, and if so can anyone tell me what I am doing wrong ?
Question 1: Yes, that's the expected behavior. Typically you would use delta to watch for changes.
Question 2: Yes, I would assume that delta is working. You haven't shown any code, so it's impossible to guess what's going wrong.
I'm developing a download manager using Indy and Delphi XE (The application uses Multithreading to attempt several connections to the server). Everything works fine but sometimes the final downloaded file is broken and when I check downloaded temp files I see that 2 or 3 of them is filled with zero at their end. (Each temp file is download result of each connection).
The larger the file is, the more broken temp files I get as the result.
For example in one of the temp files which was 65,536,000 bytes, only the range of 0-34,359,426 was valid and from 34,359,427 to 64,535,999 it was full of zeros. If I delete those zeros, application will automatically download the missing segments and what I get as the result, well if the problem wouldn't happen again, is the healthy downloaded file.
I want to get rid of those zeros at the end of the temp files without having a lost in download speed.
P.S. I'm using TFileStream and I'm sending it directly to TIdHTTP and downloading the files using GET method.
Additional Info: I handle OnWork event which assigns AWorkCount to a public int64 variable. Each time the file is downloaded, the downloaded file size (That Int64 variable) is logged to a text file and from what the log says is that the file has been downloaded completely (even those zero bytes).
Make sure the server actually supports downloading byte ranges before you request a range to download. If the server does not support ranges, a requested range will be ignored by the server and the entire file will be sent instead. If you are not already doing so, you should be using TIdHTTP.Head() to text for range support before then calling TIdHTTP.Get(). You also need to do this anyway to detect if the remote file has been altered since the last time you downloaded it. Any decent download manager needs to be able to handle things like that.
Also keep in mind that if TIdHTTP knows up front how many bytes are being transferred, it will pre-allocate the size of the destination TStream before then downloading data into it. This is to speed up the transfer and optimize disc I/O when using a TFileStream. So you should NOT use TFileStream to access the same file as the destination for multiple simultaneous downloads, even if they are writing to different areas of the file. Pre-allocating multiple TFileStream objects will likely trample over each other trying to set the file size to different positions. If you need to download a file in multiple pieces simultaneously then either:
1) download each piece to a separate file and copy them into the final file as needed once you have all of the pieces that you need.
2) use a custom TStream class, or Indy's TIdEventStream class, to manage the file I/O yourself so you can ignore TIdHTTP's pre-allocation attempts and ensure that multiple file I/O operatons do not overlap each other incorrectly.